← FleetLedger blog

The technical-account bordereau the finance team scrutinises most, and the discrepancy that triggers a DA review

The operations director at a coverholder I worked with treated bordereaux as a monthly chore: export, format the columns, hit send, move on. Premium and claims got the attention. The technical-account bordereau was an afterthought he assumed the finance team would just file away. That is backwards. The technical account is the one document the syndicate reads with a calculator open.

Risk and claims bordereaux describe the business. The technical account is the file the syndicate uses to post money to its own ledgers. When it does not tie out, that is not a formatting nuisance to the carrier. It is a number that is wrong in their books, and they notice every time.

What sits inside premium, claims, and technical-account bordereaux under Lloyd's Coverholder Reporting Standards

Lloyd's Coverholder Reporting Standards define a core set of regulatory, tax, premium and claims fields every coverholder reports against, so a syndicate can ingest a binder's data the same way regardless of who wrote it. The risk and premium bordereau lists what was bound: inception, sums insured, gross premium, brokerage, tax. The claims bordereau tracks paid and outstanding amounts, reserves, recoveries. The technical-account bordereau nets it all into settlement: gross written premium, deductions, the net to underwriter for the period.

The three are supposed to reconcile. The technical account is where they are forced to. If your premium lines say one thing and your header says another, the gap is visible in a single subtraction.

Why the technical account is the document the syndicate finance team trusts least

Finance teams do not read every risk line. They read the technical account because it drives cash. A signed-off technical-account bordereau becomes a credit or debit against the syndicate's premium ledger, feeds the year-of-account result, and pushes data into Lloyd's central reporting. An error here mis-states money the market has already booked, so it gets the least benefit of the doubt.

When the period total does not match the sum of the underlying premium lines, the bordereaux manager cannot absorb it. They query it, hold settlement, and log it. That log is the part the operations director never saw.

How small recurring mismatches escalate into a DA audit and binder risk

One quarter where premium totalled a few hundred euros off is a query. The same query four months running is a pattern, and patterns trigger a delegated-authority review. Lloyd's and managing agents set audit frequency on a risk basis, weighing class of business, premium income, level of authority delegated, and the coverholder's track record on clean bordereaux. Recurring data-quality failures move you up that list and are among the most common reasons a binder gets pulled forward for a full DA audit.

The failures that compound:

None is dramatic alone. Stacked over a few cycles, they read as a coverholder that cannot vouch for its own numbers, which is exactly what an audit is sent to confirm.

Data-quality controls that survive a coverholder audit

The fix is not a stricter review of the spreadsheet before you send it. By then the errors are baked in. The control has to sit at the source, where the policy schedule, the premium calculation and the actual fleet stay in agreement continuously, so the technical-account total is a by-product of reconciled data rather than a figure someone hand-totals at month-end. When the carrier subtracts your lines from your header, it comes to zero every time.

FleetLedger runs each fleet program as its own tenant, reconciling RDW registration data against the policy schedule as vehicles move on and off cover, and generating premium, claims and technical-account bordereaux in the Coverholder Reporting Standards layout from that one reconciled source. The number on the technical account is the same number your lines add up to, because they were never allowed to diverge. See how the reconciliation works.