// What we build
Twenty carriers, twenty layouts. One book.
Premium, claims, technical account and risk bordereaux, running 30 to 60 or more fields each. A coverholder managing twenty binding-authority relationships produces twenty materially different layouts for the same period, from the same record, by hand, against twenty deadlines.
All of them get generated from one canonical record, with per-carrier field mapping held as configuration rather than as one person's memory.
// The situation
You answer to a panel, so N formats, not one.
Underwriting authority is granted in more than 75% of managing general agent contracts reviewed, and non-exclusive contracts are now the majority of agent-produced premium.
AM Best · 2026.
Non-exclusive means multiple capacity providers on one book, each with its own template, cadence and validation rules, and each renewing on its own view of your reporting quality. So the mapping between your book of record and each carrier’s layout is the asset, and the first job is getting it out of spreadsheets and people’s heads into configuration you can read, diff and edit.
// The stack you actually run
One spec if you are coverholder-backed. None if you are not.
If your capacity is Lloyd’s-backed, the Coverholder Reporting Standards give you an actual specification and the Delegated Data Manager a submission path with validation attached. It is worth building to even where it is not required, because it is the only published field-level standard in the segment.
There is no United States domestic equivalent. Every fronting and program carrier sets its own requirements, contract by contract, and those change when the treaty changes. That absence is why this is engineering work rather than a template purchase: the target is not one schema with variants. It is N schemas with no governing body and no deprecation policy.
And the spreadsheet is usually the correct answer, which changes what gets built.
A program administrator writing a manuscript program has a rating model no policy administration vendor supports out of the box, a carrier that changes the rate structure at each treaty renewal, and a book the vendor configuration projects are not sized for. So the build reads from the spreadsheet rather than requiring its replacement first.
// The build
Four builds, and what each one is measured on.
N bordereaux from one canonical record
One canonical representation of the book, and per-carrier generation from it: premium, claims, technical account and risk bordereaux for each relationship, conforming to that carrier's field list, naming conventions, date format, currency treatment and layout. Add a carrier and you add a mapping, not a process.
Surface: the book of record, out to per-carrier templates and to the Delegated Data Manager where the relationship supports it.
Reported-versus-booked reconciliation
The gap between what you reported to the carrier and what the carrier booked. Nobody owns it, it surfaces at audit, and it damages the relationship that renews your capacity — the highest-value and least glamorous problem in the segment.
Surface: your ledger and bordereau submissions against carrier statements, reconciled per relationship and per period.
A mapping layer you own and can edit
Every per-carrier field mapping held as versioned configuration in your repository, with a plain-language description, an owner and a change history. When a carrier changes its template, one person edits one mapping and the diff is visible.
Surface: a versioned mapping repository, editable by your operations team without engineering involvement.
Deadline instrumentation that fails early
Validation runs at period open and at data receipt rather than at submission. Missing loss data, unmapped fields, unbalanced premium and late partner feeds surface days ahead of the deadline, with a named owner on each.
Surface: the reporting calendar with validation gates at each stage, alerting into whatever your operations team already watches.
What we measure
Days from period close to last bordereau delivered, per relationship, with Lloyd’s deadlines running 15 to 20 business days and United States program deadlines varying by contract. Reconciliation variance between reported and booked premium, as a dollar figure and as a trend. Rejected or re-requested bordereaux per quarter, by carrier, since a concentration in one relationship is a different problem from a spread. Hours of manual keying per cycle, baselined by observation. Mappings held as configuration versus held informally, the honest measure of whether the risk moved. Definitions and baselines, set in the first week.
“A statutory filing runs on per-state deadlines, per-state platforms, and an examination that asks for the file rather than the intention. A monthly bordereau against a contractual deadline carries the same shape.”
// Where this comes from// What's hard about this
Two limits, and what we do about each.
Column-name drift is a governance problem, not a parsing problem.
GWP against Gross Written Premium. DD/MM/YYYY colliding with MM/DD/YYYY inside one workbook. Currency stated in a header, in a footnote, or nowhere. A field that quietly changed meaning when the carrier’s data team reorganized. All of it is normalizable, and that is not the difficult part. What no system can do is stop a carrier changing its template next quarter without telling you.
So the durable fix is ownership rather than cleverness. The mapping layer is yours, versioned, editable by your operations team, and a template change is a one-line diff with a date and an author on it. A model that has memorized this quarter’s file is a liability by the third quarter, because when it breaks nobody can see why. Configuration you can read fails visibly.
The reporting deadline is contractual and immovable.
Lloyd’s deadlines run 15 to 20 business days from period close, program deadlines are written into the binding authority contract, and neither moves because an ingestion job failed. A system that produces a correct file late has failed in the way that matters, because the consequence lands on the capacity relationship rather than on the data.
So the build is specified to fail loudly and early rather than correctly and late. Validation runs at data receipt, not at generation. Every check has a named owner and a deadline of its own, set back from the contractual date. A partial file with its gaps listed goes out on time with a stated remediation date, in preference to a complete file that misses. Reconciliation runs through the period rather than as a submission step, so the variance is known well before the deadline.
// What ships with it
The delegated-authority audit file, assembled continuously.
Model 225 requires quarterly financial accounts in a format that lets the carrier complete its annual statement, annual certified public accountant reports, and at least semi-annual audits. That evidence gets assembled as the period runs rather than in a scramble afterward, and the file you build for the audit answers a reinsurer’s expanded data request at renewal. Where a step scores or classifies rather than maps, it also leaves a model inventory entry, lineage, testing results and a named human decision-maker specification.
Bring us one reporting cycle.
We will tell you what your inbound bordereaux cost per cycle, and where the variance is hiding. How the read works →