At a glance
- Bordereaux automation starts with one canonical schema, not a reformat of each submitter's spreadsheet.
- A validation-and-reconciliation check matrix below sets, for every check, the data source, rule, tolerance, owner, and action.
- Validate against the binding authority (limits, classes, territories, dates) before validating arithmetic — an authorized risk booked at the wrong rate is a smaller problem than one written outside authority at all.
- Reconciling premium bordereaux to cash is a named step with its own owner, not an assumption that a clean-looking bordereau means the money arrived.
- Exception ownership splits by check: some belong to the MGA's preparer, some need the carrier's underwriting or claims team — the matrix names which.
What is a bordereau?
A bordereau is a periodic report an MGA, program administrator, coverholder, or third-party claims administrator sends to the carrier, listing the premium or claims transactions written or handled under a delegated authority. A formal binding authority agreement grants that authority and sets its scope. Lloyd's puts it in writing: [2] “Part of the contractual agreement is that the coverholder regularly reports risk, premium and claims information to the Lloyd's syndicates and Lloyd's Brussels.”
Per Lloyd's reporting standard, a premium bordereau lists risks bound or renewed in the period, with premium, commission, taxes and fees, and the net amount due; a claims bordereau lists claim activity instead: new claims, reserve changes, payments, and closures, each tied to a claim reference[2]. We recommend keeping them as separate feeds.
- Delegated authority — the carrier's grant of underwriting, binding, or claims-handling authority to another party, documented in the binding authority agreement.
- Program administrator / coverholder — the MGA or agency that holds the delegated authority and submits the bordereaux.
- Premium trust account — an account that holds collected premium before it's remitted to the carrier; what it must or must not do is a question for compliance or counsel.
The bordereaux validation-and-reconciliation check matrix
Each row is one check: its data source, the rule it enforces, the tolerance that decides whether it clears automatically or waits for a person, who owns it, and what happens when it fails. Set your own tolerance values; none are given here as a target to copy.
| Check | Data source | Rule | Tolerance | Owner | Action on failure |
|---|---|---|---|---|---|
| Binder / UMR reference match | Header vs. filed agreement | Matches an agreement on file | None — exact match | MGA preparer | Return line before loading to any system of record |
| Reporting period continuity | Prior vs. current period dates | No gap or overlap between periods | Zero, unless the reporting schedule allows a lag | MGA preparer | Hold load; request a supplement for the gap |
| Policy dates within binder term | Effective date vs. binder term | Must fall within binder term | None | MGA preparer; carrier on exception | Escalate; hold until confirmed |
| Class of business in authority | Class code vs. authorized classes | Class is within binder authority | None | MGA preparer; carrier on exception | Refer; hold until confirmed |
| Territory in authority | Location vs. authorized territories | Must be in authorized territory | None | MGA preparer; carrier on exception | Refer; hold until confirmed |
| Limit within binder authority | Bound limit vs. binder limit | Can't exceed limit without facultative referral | None, unless binder sets referral band | MGA preparer; carrier approves | Refer for facultative approval; flag pending |
| Premium arithmetic | Premium, commission, taxes / fees, net due | Net due = gross less commission, ± taxes / fees per program terms | Zero — arithmetic, not judgment | MGA finance | Return line for correction before remittance |
| Duplicate transaction | This vs. prior periods and submissions | No two lines share the same policy and transaction reference | Zero duplicates | MGA preparer | Remove duplicate; confirm line with source |
| Claims arithmetic consistency | Paid, reserve, total incurred per claim | Incurred = paid to date + reserve | Zero — arithmetic | MGA / TPA claims handler | Correct and resubmit before use elsewhere |
| Claims authority threshold | Reserve / payment vs. authority limit | Above authority: refer, don't settle | Per binder's authority limit | TPA / MGA handler; carrier on referral | Refer to carrier claims before paying |
| Premium to cash tie-out | Net due vs. trust deposit / remittance | Net due ties to cash received, within terms | Reader-set $ / day band, agreed with carrier | MGA finance | Hold and investigate before closing period |
How do you automate bordereaux ingestion across inconsistent formats?
Every submitter's bordereau looks a little different: different column names, merged header cells, embedded subtotals, dates in three formats, claim status as free text instead of a code. Reformatting each by hand doesn't scale past a handful of binders, and a custom parser per submitter doesn't scale either, since the next agent brings another layout.
- Define one canonical schema
Pick the field set your checks and ledger actually need — binder reference, policy and claim identifiers, dates, amounts, class, territory — and map every incoming bordereau onto it rather than reformatting ad hoc.
- Map each submitter's layout once
Build a column-to-field mapping per submitter template the first time it arrives, and reuse it. A changed template is a mapping update, not a manual reformat.
- Extract line items with a location pointer
Read each row into the canonical schema, keeping a pointer back to the exact cell or page it came from, so a reviewer can check a flagged value against the original.
- Normalize codes and formats
Convert dates, currencies, and class or territory codes to one internal standard before any validation rule runs.
- Abstain on low confidence
When a field can't be read reliably, route that row to a person instead of guessing and letting it pass validation on a wrong number.
Prefer structured data over free-form spreadsheets where a submitter can produce it: Lloyd's says it has worked with ACORD, the insurance industry's global standards-setting body, so that ACORD XML can be used to meet Lloyd's coverholder reporting requirements [2]. That's a reason to move larger submitters off spreadsheets over time, not a reason to wait before automating the rest.
What validation checks should run against the binding authority?
The binding authority agreement is what makes a bound risk authorized in the first place. Lloyd's describes it as the document that “defines the scope of underwriting and administrative functions” a coverholder may perform [1]. Check that scope before anything else: an unauthorized risk is a bigger problem than a correctly authorized one with a pricing error.
- Dates: every bound policy's effective date sits inside the binder's inception and expiry dates.
- Classes: the class of business on the bordereau is one the binder names as authorized.
- Territories: the risk's location is inside the binder's authorized territory or territories.
- Limits: the bound limit, per-risk and aggregate, doesn't exceed what the binder authorizes without a facultative referral.
How do MGAs reconcile premium bordereaux to cash received?
A validated bordereau still isn't reconciled: validation confirms it's internally consistent and within authority, but reconciliation confirms the money actually moved. Treat the two as separate steps with separate owners.
- Confirm the net due figure
Before reconciling to cash, confirm the bordereau's own arithmetic: net due equals gross premium less commission and whatever taxes or fees the program adds or deducts.
- Tie net due to the trust account movement
Match net premium due for the period to the corresponding deposit or remittance, by amount and by the settlement date the program agreement sets.
- Apply your tolerance band
Clear the match automatically only within a dollar and day tolerance finance and the carrier have agreed, not whatever a spreadsheet happens to accept.
- Investigate what's outside tolerance
A figure that doesn't tie within tolerance needs a named owner and a reason before the period closes: a timing gap, a missing line, and a calculation error are three different fixes.
- Keep the tie-out in the audit trail
Record the match, the tolerance applied, and who signed off, in the same place a carrier audit would look.
Where to start: a first scoped workflow
Start with one binder, prove the checks hold, then extend.
- Pick one binder with a known submitter
Choose a program whose format and binder terms you already understand, so the first pass tests the checks, not your knowledge of the program.
- Build the hard checks first
Start with binder-authority checks (dates, classes, territories, limits) and arithmetic checks, the ones with no tolerance, before tolerance-based checks that need a policy decision.
- Replay two or three closed periods
Run the checks against bordereaux already reconciled by hand, and confirm they reproduce what your team found, missing nothing already caught.
- Agree tolerances before go-live
A tolerance band is a policy decision; set it with finance and underwriting, and log every item that clears under it.
- Extend one binder at a time
Add the next program only once the first one's exception volume and ownership model are stable.
When this doesn't apply
- A single low-volume binder with one familiar submitter may be faster to review manually.
- The submitter can't yet produce consistent, dated bordereaux — fix the submission process first.
- The binder's own terms are ambiguous about limits, classes, or territories. Resolve that with underwriting and counsel before encoding a guess.
- Trust account data isn't available in a form finance can match against — get that feed first.
Frequently asked questions
What is a bordereau?
A bordereau is a periodic report an MGA, program administrator, coverholder, or claims administrator sends to the carrier, listing the premium or claims transactions handled under a delegated authority. A premium bordereau covers bound and renewed risks with premium, commission, taxes, and fees; a claims bordereau covers claim activity, reserves, payments, and closures.
How do you automate bordereaux ingestion across inconsistent formats?
Define one canonical schema for the fields your checks and ledger need, map each submitter's layout onto it once and reuse the mapping, extract line items with a pointer back to the source document, normalize dates and codes before validating, and route low-confidence rows to a person instead of guessing a value.
What validation checks should run against the binding authority?
Run authority checks before arithmetic checks: policy dates inside the binder's inception and expiry, class of business inside the binder's authorized classes, risk location inside the authorized territory, and bound limits inside the binder's per-risk and aggregate limits. An out-of-authority risk is a larger problem than a pricing error on an authorized one.
How do MGAs reconcile premium bordereaux to cash received?
Confirm the bordereau's own arithmetic first, then tie its net premium due to the matching trust account deposit or remittance by amount and agreed settlement date, clearing automatically only within a tolerance finance and the carrier have set. Investigate anything outside that tolerance before the period closes, and keep the tie-out as part of the audit trail.
Who owns bordereau exceptions, the MGA or the carrier?
It depends on the check, not a blanket rule: formatting and arithmetic errors are the MGA preparer's to fix, while out-of-authority risks — wrong class, territory, limit, or date — need the carrier's underwriting team to review, and claims above the delegated authority threshold go to the carrier's claims team. Name the owner per check, not per bordereau.
What bordereau errors cause carrier audit findings?
We recommend having these checks in place before a carrier audit: risks bound outside the binder's classes, territories or limits; claims handled beyond delegated claims authority without referral; premium arithmetic that doesn't tie to amounts remitted; and missing or duplicate transactions. Each maps to a specific validation check, not a vague data-quality complaint.
Related reading
- Financial reconciliation automation covers the match-rule and exception-routing approach this walkthrough builds on.
- Document review with human approval covers the same abstain-and-route pattern used here for low-confidence bordereau rows.
- Insurance invoice analysis covers a sibling claims-side workflow: line-item review of invoices against policy terms and fee schedules.
- Reconciliation match rules and exceptions goes deeper on match types and tolerance design in general, beyond bordereaux.
- False positives in insurance invoice review covers how precision and recall set reviewer workload, relevant to tuning validation rules.
More in Insurance operations
What AI Claims Automation Costs: A Cost and ROI Model for Carriers, TPAs and MGAs
AI claims automation cost depends on scope, not a price list. Get the cost drivers, an LAE baseline worksheet, and a payback method for carriers, TPAs and MGAs.
Insurance CompaniesInsurance Commission Reconciliation Automation: AMS Module, Point Tool or Custom AI Agent?
Choosing insurance commission reconciliation automation: a decision matrix for AMS module vs. point tool vs. custom agent, and a discrepancy routing table.
Insurance CompaniesLoss Run Extraction Automation: A Field Schema and Accuracy Test for Agencies and Underwriters
Loss run extraction automation needs a shared field schema and a tie-out test across carrier formats: the minimum fields to pull and five checks to trust it.
Insurance Companies