By Yair Knijn · February 13, 2026

The bordereau balanced in the wrong currency, and settlement broke for three months

The claims manager balanced the bordereau to the penny and called it done. Every row footed, the spreadsheet totals matched the bank, and the file went to the broker the same afternoon. The assumption buried in that confidence: currency, settlement, and tax fields are formatting. Cosmetic. Something the binding authority team tidies up later. They are not. They are the keys the technical account reconciles against, and when they drift, money stops.

This is the failure that does not announce itself. The bordereau looks right. It just will not settle, and three months later you are explaining to a syndicate why their cash is stuck behind a column you treated as decoration.

The fields in Lloyd's Coverholder Reporting Standards that actually gate settlement

The Lloyd's Coverholder Reporting Standards (the v5.2 user guide is the one most binders still map to) treat currency as three separate facts, not one. There is the Premium (Original) Currency, the Settlement Currency the coverholder pays the broker in, and the Broker Settlement Currency the broker pays insurers in. When those differ, the standard expects each one stated explicitly, with the settlement financial fields populated to bridge them. Tax is the same: the standard makes you declare whether no tax, one tax, or multiple taxes are reported, and IPT or VAT then has to sit in its own field with its own territory, not folded into the gross.

Skip the distinction and the bordereau still totals. It just totals against a structure the receiving system cannot parse, because you have told it everything settles in EUR while the binder writes premium in GBP and the IPT belongs to a different territory entirely.

How a currency or tax mismatch breaks the technical account

The technical account is the reconciliation the market runs on. It checks that the net premium per the account equals the sum of the premium bordereau entries, that claims paid tie back to prior reserves, that the tax declared matches the territory rules. When the net premium in the technical account is computed at one rate and your bordereau carries another, the two numbers will not agree, and the account fails on a difference you cannot find by re-footing your spreadsheet, because your spreadsheet was internally consistent the whole time.

A single misplaced IPT amount does the same thing. Report it inside the gross premium instead of its own field and the tax reconciliation flags a territory mismatch. The line is not wrong by much. It is wrong in a way that blocks the whole submission, and the manager who built it has no error to chase because, line by line, every figure is correct.

Why settlement delays escalate into a relationship and cash-flow problem

A failed technical account does not bounce back in an hour. It sits in a query, goes to a person, comes back as a request for a corrected bordereau, and the corrected version waits for the next reporting cycle. Each round trip is weeks. Three cycles and you are at a quarter, with premium the syndicate has earned and not received, sitting in your settlement account because a currency code and a tax field did not line up.

That is when it stops being an operational nuisance. The syndicate's capital providers expect cash on a schedule. A coverholder whose bordereaux routinely query is a coverholder whose audit gets harder, whose terms get reviewed, whose binder renewal conversation opens with a complaint instead of a number. The fields you treated as formatting are now the reason your relationship is under question.

Field-level validation before the bordereau leaves your building

The fix is to validate against the standard's structure, not your own arithmetic, before anything goes out. A check that catches the four things that actually fail accounts:

• Premium, settlement, and broker settlement currencies are each present and the conversion between them is stated, not assumed.
• Every tax sits in its own field with its own territory, and the no-tax / one-tax / multiple-tax declaration matches what the rows contain.
• Net premium reconciles to the technical account at the same rate the account uses, before submission, not after the query.
• Claims paid tie to a reserve that existed in the prior period.

None of that is glamorous. It is also the difference between a bordereau that settles on the first cycle and one that costs you a quarter. A fleet program carries its own currency and territory facts already, from the policy schedule and the registration data, so the values you report should be derived from the source of truth, not retyped into a spreadsheet where a manual EUR can quietly overwrite the real one. FleetLedger keeps those fields tied to the binding terms for each fleet program, so the bordereau that leaves the building is the one the technical account will actually accept.