The Entry That Was Right, and Also Wrong
I found the problem during dry-run reconciliation, four weeks before our planned cutover. Not in the new system — in the old one. Buried in a single journal entry dated the first of June 2022: one line, seven figures, a currency translation adjustment on our CAD book. Perfectly correct. Perfectly useless to anyone who needed to know what actually happened underneath it.
Five months earlier, our treasury feed had been pricing every Canadian-dollar transaction off a stale rate — the CHF/CAD cross hadn't refreshed since December. Every premium, every claim, every retrocession settlement booked in CAD from January through May was converted at the wrong number. Nobody caught it until our May close, when the cross-currency reconciliation came in seven figures off. So on June 1st, someone did exactly what you're supposed to do: booked one corrective entry, brought the balance sheet back to where it should have been, and moved on. Our auditors reviewed it, accepted it, and signed off on the year.
One Number Fixed. Thousands Still Wrong.
Here's what that one corrective entry actually did, and didn't do. It fixed the sum. It did nothing for the roughly 28,000 individual CAD transactions sitting underneath it, each one still carrying the wrong exchange rate, each one still technically wrong at the transaction level — forever, because the correction was a plug, not a restatement. Nobody had gone back and repriced five months of individual premiums and claims. Nobody reasonably could have — that's thousands of line items across dozens of treaties, reconciled to a single top-line adjustment instead.
For financial reporting, that's a closed matter. The balance sheet is right. For anyone downstream trying to use that data — pricing actuaries looking at loss ratios by cedant, portfolio managers segmenting Canadian exposure by treaty type — five months of 2022 is quietly, permanently unreliable at the level of detail their work actually needs.
What We Tried First
We tried the version everyone tries first: fix it properly. Pull the five months of CAD transactions, reprice each one at the correct historical rate, replace the lump-sum entry with the transaction-level truth it should have been. Cleaner data, better lineage, obviously the right thing to do.
It broke reconciliation to our filed FY22 accounts by eleven and a half thousand francs. Our external auditors were polite about it. They were also clear: reopening an audited period to make the data "more correct" wasn't a data project anymore. It was a restatement conversation, and restatement conversations go to the audit committee, not the migration team.
Bringing In an AI Managed Service
What changed things was refusing to pick a winner. The AI Managed Service approach kept the original transactions and the June 1st correcting entry exactly as filed, byte for byte, permanently reconcilable to every financial statement we have ever published. Alongside that, in a clearly separate and clearly labelled layer, it built the transaction-level restatement: what each of those five months of CAD transactions should have priced at, with full lineage back to the corrected rate, and a flag on every row marking it as an analytical reconstruction rather than a change to the books of record.
A Reconciliation That Never Breaks
That separation is what let me sign the migration off without reopening anything. Every figure our auditors have ever reviewed still reconciles, to the franc, forever — because we never touched it. The migrated ledger carries the original transactions and the original corrective entry exactly as filed, with the AI Managed Service maintaining that reconciliation automatically as new periods close, not just for the one entry we already knew about, but for every plug, workaround, and manual correction like it across three and a half decades of records.
Data I Could Finally Ask Questions Of
The restated layer is what gave the business back the five months it had quietly written off. Our pricing actuaries could finally segment Canadian cedant performance through the whole of 2022 without a five-month hole of unreliable detail in the middle of it. Portfolio management could run loss-ratio analysis by treaty and by currency and trust every quarter equally, instead of footnoting one and hoping nobody asked why.
We found one Canadian treaty that had looked marginally profitable for two years, once you actually corrected the five months everyone had been quietly working around. It wasn't. The lump-sum entry had been correct about our balance sheet and silent about our portfolio.
Why We Could Finally Go Greenfield
This is what let the migration proceed as a genuine rebuild instead of a careful, anxious copy of decades of manual corrections. Once the AI Managed Service stood behind the full history — every original transaction, every correcting entry, every restated equivalent, all reconciled and all covered under an SLA guaranteeing it would stay that way — my finance team stopped trying to decide, case by case, which of hundreds of historical corrections were safe to migrate as-is and which needed careful handling.
We migrated the current book and clean opening balances into the new platform, full stop. Every historical correction, restated or original, stayed with the AI Managed Service, reconcilable on demand in whichever form the person asking actually needed — audited, or economic. My team built the target ledger for how the business runs today, not as an archaeology project for every plug entry since the system went live.
Both numbers were true. Only one of them was allowed to change. I signed that migration off knowing both truths could be pulled apart and both trusted — the audited number that never moves, and the economic detail that finally does justice to what actually happened. Somewhere around month three of a five-month currency error, I stopped thinking about it as a data quality problem. It's a question of whose truth you're asking for. The migration only worked once we stopped forcing one answer to serve both questions.