Every bordereau has a sender and a receiver, and each side has its own systems of record. Brisc sits between them: it reads what arrives in any layout, checks it against your contracts and your own history, and once your team signs off, updates your systems, by API or as a file they load: bordereau data, the paid bordereau and cash calls. Your systems stay the system of record.
Your extract checked before it leaves, and the file produced in the layout your carrier or reinsurer requires.
The sender side → You receive themEvery file read in whatever layout it arrives, validated row by row, and tracked version to version.
The receiver side →On top of the systems that produce bordereaux and the ones that act on them, on either side of the exchange. Brisc reads the files those systems produce and updates them after review, by API or as a file they load. The only things it keeps for itself are the record of what it has seen and the trail of who decided what. The wider picture, who sends, who receives and where Brisc sits, is on Where Brisc fits.
Six steps run in order on every file, premium or claims, before a single check fires.
Forwarded to a dedicated inbox, uploaded with the reporting month, or pulled on a schedule from your storage. Most arrive as Excel; CSV is read too, and password-protected workbooks open.
The header row is found even when it isn’t row one. Sheets that share the main layout are combined, summary and pivot tabs are left out, and every row is stamped with its source sheet.
Each sender’s set of columns gets a fingerprint. A known layout applies its saved mapping automatically. Column order doesn’t matter.
An unfamiliar file opens a guided mapping: its columns and sample rows on screen, with suggested mappings to confirm. Mappings are versioned, and every row records which version produced it.
Dates, amounts, Y/N flags, state codes and claim statuses are made consistent. Broker naming variants resolve to one name. Blank rows are dropped and counted.
A composite identity and a content hash tell new rows, changed rows and unchanged rows apart. A changed row becomes a new version; the old one is kept.
The detail on formats and standardisation is on bordereaux ingestion and processing.
Templates drift every renewal. Brisc compares the new layout with the mappings it already holds for the program, applies the changes that are safe, and pauses the file for the rest, with the reason in plain English, before anything is written. Brisc updates the mapping and the same file resumes with no re-upload. Every change it applies is written to the run summary.
Suggestions are confirmed by a person before they change a mapping. Key fields and money fields are remapped only by a person.
Against your contracts, and against Brisc’s own record of the program: every row it has received, in every version, with what changed and when.
The baseline for every version-to-version check. A premium that moved, a claim that reopened or a row that vanished shows up against it, with before and after side by side.
Each program is set as inception to date, month to date, or changes only. A missing row means something different on each, and the checks know which. Monthly movements roll up into inception-to-date figures.
A changed row becomes a new version and the old one is kept. Each row carries the file, sheet and mapping version it came from, so any figure can be traced back to its source.
Named checks run at ingestion on every file and every version. Each is switched on, ordered and tuned per program. A check whose fields aren’t in your file says so, rather than passing or failing by default. Every check is named in the validation check library.
Every row against the last version you accepted: silent premium changes, disappearing rows, claims moving backwards, indemnity dropping, open claims vanishing without being closed.
Does each row add up? Incurred, paid, reserves and expenses on claims; net to facility, commission and share applied on premium. Set up per program.
Commission against the contracted rate, tax and levies by jurisdiction, and others set up per program.
Reported before the loss happened, a sign that contradicts its transaction type, duplicates, invalid dates and identifiers, currency and FX, amounts outside the program’s usual band.
Rows missing what the downstream cash match will need, flagged a month before the reconciliation fails.
Structural checks, and checks against the first version Brisc saw of each record. Switched on per program when you want them.
Every flag carries the row, the check that fired, the reason and a severity. Nothing is blocked unless you choose to block it.
Acknowledge with a reason, one flag or many at once. The decision carries into later runs, so the same flag doesn’t return next month. A changed claim can be held for review: replace, ignore, or keep both.
Who decided, when and why, alongside a field-by-field record of what changed. That is what audit asks for.
Once flags are cleared, Brisc updates the systems you already run, by API integration or as a file they load, so nobody re-keys what has already been checked. Your own tools and agents can also pull from Brisc’s API or through MCP agent access. Every update carries the trail back to the source and the decision behind it.
Accepted premium and claims data, by API or as a load file in your schema, with the version and source of every row attached.
Once cash is matched in the Reconciliation Analyst and approved, the payment is posted to the policy it settles in your policy administration system by API, as it is for Helix today. Brisc records the payment; the money moves on your banking rails.
Cash calls backed by the claims bordereau, and the entries that follow, into your reinsurance system or general ledger, by API or as a ledger file they load.
Updates run after review. Your systems stay the system of record; Brisc is how checked data reaches them.
The same engine, pointed the other way. Your extract is read and checked like any inbound file, then produced in the layout the receiving party requires.
The file your policy admin system or warehouse already produces, in whatever layout it has. No reformatting first.
The same checks a careful receiver runs: footing, shares and participation against the authority in the contract, and every movement against last period.
Each program can hold named export layouts in the receiver’s own column order. A column Brisc can’t fill is reported as empty, with the reason.
Brisc reads the files your systems produce, and updates them after review by API or as a file they load. Bank statements are read; nothing is written to the bank.
Reconciling bordereaux to cash is the Reconciliation Analyst. Checking reinsurance statements and cash calls against the contract is the Reinsurance Accounting Analyst.
No. Send what you send today. Brisc maps each layout once, remembers it, and copes with the usual template changes on its own. Your partners don’t have to change anything either.
Both, as one chain: ingestion, mapping, validation against your contracts and your own history, and output in the format the next party needs. Reconciliation to cash is the Reconciliation Analyst, on the same data.
Brisc keeps every version of every row it has received, with the change history and the mapping that produced it, in a dedicated tenant on Microsoft Azure. Your policy admin, claims system and ledger stay the system of record. Brisc updates them once your team has signed off, by API or as a file they load, and posts approved payments to your policy administration system by API.
Reordered, added, removed and renamed columns are handled automatically when it’s safe, and noted in the run summary. When it isn’t, such as a missing identifying column, the file pauses with the reason in plain English before anything is written. Brisc updates the mapping and the same file resumes.
Both. Brisc integrates with your systems by API, as it does with a customer’s policy administration system today, or delivers a file in the layout they load. Your own tools and agents can also pull from Brisc’s API or through MCP agent access. Updates happen after review, and the money moves on your banking rails.
Yes. Brisc checks your extract against the same library and produces the file in the column layout your carrier or reinsurer requires. A column it can’t fill is reported as empty, with the reason.
No. Checks raise flags with the row, the check and the reason. Your team acknowledges or acts, and the acknowledgement carries forward so the same flag doesn’t come back next month.
30 minutes, no slide deck. We run both through Brisc and show you what changed between them, what the checks flag, and where every figure came from.
Book the walkthroughNot ready for a call? Get the MGA operations report →