Bordereaux Analyst

Bordereaux validation checks, named and explained.

Brisc validates every bordereau at ingestion with named checks: premium, claims, and cross-version against the last file you accepted. Every flag carries what it caught and why; nothing is silently corrected.

Premium and risk

What does Brisc check on a premium bordereau?

Run against every row, default-on. Each flag names the check that raised it.

Silent premium change

Premium moved against the prior accepted version with no justifying transaction.

High severity. The quiet edits are the ones that surface at audit.

Disappearing rows

A policy present last period, absent this period, with no explanation.

A vanished row is unbooked premium until someone notices.

Cross-version diff

Every row compared against the prior accepted version of the file.

Nothing changes between periods without a record of the change.

Commission rate vs contract

A commission percentage that deviates from the contracted rate.

Margin leaks a fraction of a point at a time.

Tax and levy correctness

IPT and levies tested against rate and base, per jurisdiction.

Tax errors compound into regulatory exposure, not just bad rows.

Sign vs transaction type

An amount whose sign contradicts its transaction type.

A reversed sign books a refund as premium.

Duplicate transaction

The same transaction appearing twice in one file.

Duplicates inflate the book and break the cash match downstream.

Premium outlier

Premium outside the expected band for the program.

Catches mis-keyed amounts and mis-scaled currencies before they book.

Policy validity

Dates or identifiers that are invalid or fall outside the period.

Invalid rows fail every downstream process that touches them.

Currency and FX

A currency mismatch or an implausible exchange rate on the row.

FX errors hide in plain sight until settlement.

Bank-reconciliation readiness

A row missing the fields the downstream cash match will need.

Catches a reconciliation failure a month before it happens.

Structural checks (opt-in)

Required keys present, types valid, duplicates, status and date consistency.

A structurally broken file fails everything built on top of it.

Claims

What does Brisc check on a claims bordereau?

The claims library, plus the shared cross-version and disappearing-rows checks above. For claims-side processing end to end, see claims bordereaux.

Status regression

A claim that moved backwards, closed to open, without explanation.

A silent reopen changes reserves invisibly.

Indemnity drop

Incurred or paid falling without an offsetting recovery.

An unexplained loss of value is an error or a story you need to hear.

Recovery netting

Recoveries netted against indemnity instead of coded to subrogation.

Netting hides recoveries and misstates loss experience.

Closed vs silent drop

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

A vanished claim is an unresolved liability.

The footing checks (nine)

Per row: do incurred, paid, reserve movements and expense splits add up to their parts? Enabled per program.

A row that doesn’t add up can’t be trusted anywhere else.

Reported after loss

A claim reported before the loss occurred.

Impossible dates mean a keying error, or a data problem worth chasing.

Big loss

A claim whose share of incurred reaches the level set for the program.

Large movements deserve eyes the day they arrive, not at quarter end.

Master-drift (available)

The claim cross-checked against the master record: loss within term, policy and loss date consistent.

Drift between bordereau and master is where disputes start.

The engine

How do the checks run?

One catalog, tuned per program

A single catalog of 39 checks; your configuration toggles, orders and tunes them.

Safety-net designed

A check whose required fields aren’t mapped returns “not applicable” with a reason code, never a false pass.

Flags queue for review

Enforcement is off by default. Every flag carries the row, the check, and the reason. Your team decides.

At ingestion, every version

Checks run the moment a file arrives, and again on every version of it.

Looking for how these checks fit into reconciliation end to end? See bordereaux reconciliation.

FAQ

Validation checks, answered

Do the checks block ingestion?

No. Enforcement is off by default: every check raises a flag that queues for review with the row, the check that fired, and the reason attached. Whether a flag blocks anything is your call, per program.

Can we tune the checks or add our own?

One catalog of 39 checks is the source of truth. Per-program configuration toggles, orders and tunes them for your book, and new checks join the catalog rather than forking it.

What if a check needs a field our bordereaux don’t carry?

It returns “not applicable” with a reason code. The library is safety-net designed: a check that cannot run says so, rather than reporting a false pass or a false fail.

Do you publish the thresholds and tolerances?

No. The behaviour of every check is public; the tuning is set with you per program during implementation. Some of that tuning encodes our customers’ own conventions, and publishing it would breach them, not just us.

Do the checks correct our data?

Never. The Analyst flags, your team decides. Originals are never overwritten, and every accepted change is versioned against the file it changed.

When do the checks run?

At ingestion, on every file and every version, premium and claims alike. There’s no separate validation step to remember to run.

Bring last month's bordereau. See what it flags.

30 minutes, no slide deck. We run your real bordereau through the check library and you watch the flags land, evidence attached.

Book the walkthrough