Bordereaux and carrier reporting
Every carrier on the panel wants the book reported differently: their template, their field names, their cut-off, their tolerance for a late correction. The month-end assembly is manual, the errors are found by the carrier rather than by you, and the capacity conversation next year is shaped by how the reporting went this year.
The symptoms
- Bordereaux are assembled by hand, and the carrier finds the errors.
- Every carrier wants a different template.
- A correction to last month reopens three spreadsheets.
What a good answer looks like
None of this needs us in the room. Run it this way with the people you already have and the problem gets smaller.
01 · Generate from the policy record, never from a copy
A bordereau assembled from an export of an export will disagree with the ledger eventually. Generate it from the same record the policy was bound into, and the reconciliation stops being an investigation.
02 · Hold the carrier's structure as data
The template, the field mapping, the cut-off and the tolerances are per carrier, and they change. Held as configuration they are a change of setting. Held in a spreadsheet macro they are a change of person.
03 · Reconcile before you send, not after
Premium written against premium billed against premium ceded, checked as part of producing the file. The errors a carrier finds are the ones that cost you credibility, and they are almost always the ones a totals check would have caught.
04 · Treat a correction as a version
Restatements happen. What matters is that the month you sent, the month you corrected and the reason are all recoverable a year later, when someone is deciding whether to renew your capacity.
What makes it hard once you are at scale
Bordereaux are where the data quality of everything upstream arrives all at once. A mid-term endorsement that was keyed but not rated, a cancellation with the wrong effective date, a claim reserved in one currency and paid in another: none of them look like a reporting problem until month end. Cut-offs differ per carrier and rarely match your own close, so the same month has several versions of the truth. And the tolerance for error is not symmetrical: a carrier who finds an error in your file starts checking the rest of it.
Where it sits in the blueprint
Reporting is the case that proves the data layer. One place the policy, premium, claim and commission numbers agree, with the carrier's structure held as configuration above it, generated and reconciled by an agent that works through the gateway so the file it produced and the record it came from can always be tied together.
What we bring already built
These are in production. Take them as they are, shape them around how you work, or leave them out and we will integrate what you already run.
- Reinsurance and Bordereaux
- Bordereau generation and ceded premium tracking, with the structure held per carrier.
- Bordereaux agent
- Generates the file, reconciles it against the ledger, and raises what does not tie before it is sent.
- Insurance Accounting
- Insurance-specific operational accounting, so written, billed and ceded are reconcilable.
- Reporting and BI
- Operational reports and the analytics layer, at program level and book level.
- Capacity and carrier reporting portal
- The outward-facing surface, so a carrier reads the position rather than asking for it.
The number this has to move
One business number, agreed before the work starts, with the baseline taken from your own reporting.
- __ %
- Bordereaux accuracy and timeliness
Is this the one costing you the most?