Bordereaux Analyst · Claims

Claims bordereaux, ingested and validated.

Brisc ingests claims bordereaux from program partners, cedants, and TPAs in any layout, maps each once to your schema, and validates every row before it reaches your claims system. Flags surface for review; nothing is silently corrected.

Brisc Bordereaux Analyst · Claims
The problem

The bottleneck sits before your claims system

Before your system sees a claim, someone makes the data usable, by hand at most carriers and MGAs. Errors at this layer don’t announce themselves: they compound downstream.

How it works

Map once. Validate every row. Export clean.

01 · INGEST

Ingest the raw claims bordereau

Excel, CSV, or PDF: known layouts auto-apply their saved mapping; new ones halt for a one-time mapping in the UI.

02 · VALIDATE

Normalise and run the rule library

Fields map to your schema, statuses and financials normalise, then the claims rule library runs on every row.

03 · DELIVER

Review, approve, export

Your team reviews the flags, approves the file, and exports a clean golden-schema CSV for the system of record.

The claims rule library

What does claims bordereaux validation check?

Named checks, run at ingestion, tuned per program. Flags surface for review; they never block or rewrite your data.

Status regression

A claim that moved backwards, closed to open, flagged with the prior version attached.

Indemnity drop

Paid or incurred falling without an offsetting recovery: an unexplained loss of value.

Recovery netting

Recoveries netted against indemnity instead of coded to subrogation.

Silent disappearance

An open or reopened claim that vanished from the file without ever being closed.

Footing checks

Nine per-row identities: do the totals add up to their parts across incurred, paid, reserves, and expense?

Reported after loss

A claim reported before the loss occurred.

Big loss

A claim’s share of total incurred at or above the band you configure for the program.

Cross-version diff

Every row compared against the last file you accepted, so nothing changes silently between periods.

Master drift Available

Loss within term, same policy, same loss date, already present on your master.

What this means

Grow the programs without growing the pre-processing.

No engineering bottleneck

New formats onboarded by your operations team in the UI: no tickets, no dev sprint.

Tribal knowledge becomes auditable logic

Mapping rules and validation criteria live in configuration: documented, repeatable, consistent.

Errors caught before they compound

Exceptions surface before ingestion, not months later when a reconciliation refuses to balance.

Scale programs without adding headcount

Every new partner needs only a mapping; the current process carries the next book.

For reinsurers

Claims bordereaux at treaty scale

Every cedant reports in its own layout, on its own conventions, so pre-processing scales with the treaty count. Working from cession statements instead? Start with cession statement processing.

Treaty-by-treaty configuration

Each cedant’s format becomes a saved mapping, once. New treaties never mean engineering tickets.

ITD and incremental handling

Paid, reserved, recovered, and salvage figures normalised to what your reinsurance platform expects.

Status remapping per cedant

Open, closed, and reopened conventions vary by ceding company. Configured once per treaty, applied automatically.

Audit trail per treaty

Every mapping decision and exception documented. Useful at year-end review, treaty renewal, and audit.

Pricing

Pricing that scales with your book

FAQ

Claims bordereaux processing, answered

What is a claims bordereaux, and why is processing it hard?

A claims bordereaux (or loss bordereaux) is a periodic report of claims activity: paid and reserved amounts, loss dates, claimant details, policy or treaty references, sent by MGAs and program partners to carriers, and by cedants to reinsurers. It’s hard because every partner sends a different layout: different headers, field orders, status codes, and financial conventions. A book of delegated programs means dozens of structural variations every month, each needing manual work before your system can ingest it.

Does Brisc replace our claims system?

No. Your claims system stays the system of record. Brisc takes the raw file in whatever layout the partner sent, validates it, and produces the claims bordereau in the format the receiving end needs, whether that is your claims system, a carrier template or a reinsurer’s layout. Your system receives clean, validated data; Brisc produces the file that carries it.

What happens when a partner changes their template?

The Analyst halts on the unrecognised layout and asks for a one-time mapping, configured by your operations team in the UI. No engineering ticket. The mapping layer is owned by operations, not IT.

Do you correct our data?

No. The Analyst flags, explains, and waits for review. Every exception carries the reason it fired and the row it fired on. Nothing is silently corrected.

How is our data handled?

SOC 2 Type II, GDPR and CCPA compliant. Every customer runs in a dedicated tenant on Microsoft Azure, your data never trains our models, and every file carries a complete audit trail of mappings, validations, and exceptions.

How is this different from the Claims Analyst?

Different jobs. The Claims Analyst handles live claims work: FNOL intake and laundry-list review as notices arrive. The Bordereaux Analyst’s claims side handles the periodic claims data files your partners send: cleaned, validated, and ingested. For premium bordereaux, see bordereaux reconciliation.

Stop pre-processing claims bordereaux by hand

30 minutes, no slide deck. We run your real files, your formats, and your validation rules.

Book the walkthrough