Reconciling returns — which differences are real

A reconciliation that expects two returns to agree will fail, and the failure tells you nothing. Different reporting frameworks define common-sounding concepts differently on purpose — a loan balance under a prudential framework and under a statistical one are answers to different questions. The skill is not making the numbers match. It is knowing which differences are definitional and expected, which are timing, and which are defects — and only chasing the third.

1. Three kinds of difference

2. The pairs worth building

Not every pair of returns repays a formal reconciliation. Three categories do:

• Return against the ledger. The most valuable single control, because it is the only one that tests whether the reporting pipeline and the books of account agree at all. Everything else tests one return against another, both of which could be wrong in the same way.
• Returns sharing a data point. Where the same data point appears in more than one framework, the frameworks’ own cross-validation will compare them eventually. Doing it first is cheaper.
• Granular against aggregate. Where one return carries record-level data and another carries totals over the same population, the aggregate should be derivable from the granular file. Where it is not, one of the two populations is wrong — and this is the reconciliation that most often finds a real scope error.

3. How to run one

The method that produces a usable bridge rather than a difference:

• Start from one population, not two numbers. Reconcile the populations first — which records are in each — before reconciling amounts. Most large differences are population differences wearing a valuation costume.
• Reconcile at the lowest common level. Two totals that differ tell you nothing; two record sets that differ tell you exactly which records.
• Attribute every item. An unattributed residual is not a reconciliation result, it is an unfinished reconciliation — and it is the line a supervisor will ask about.
• Record the expected size. A definitional difference has a size you can predict. Monitoring the difference against its expectation turns a one-off exercise into a control.

4. A worked case

Facts: a firm’s statistical return shows a customer-funds figure materially below the corresponding balance in its financial reporting, and the difference has grown over two quarters.

What the analysis does: reconciles populations first. The statistical framework’s population is defined by counterparty sector and residence; the financial framework’s is defined by the accounting boundary. Records present in one and not the other are listed, and the difference is attributed: part definitional — a sector excluded from the statistical population — and part unexplained.

What the practitioner finds: the definitional part is stable and expected. The unexplained part traces to a product launched two quarters ago whose accounts were mapped into the financial reporting model but never added to the statistical population — a scope defect, invisible in either return alone, and exactly the failure the growing trend was signalling.

What follows: the mapping gains the new product, the affected periods are restated in order — because cross-period validation compares consecutive reference dates — and the reconciliation itself gains a control step at product launch, since the root cause was a process gap rather than a calculation error.

5. Cadence and ownership

A reconciliation run only when something looks wrong is not a control. Three practical rules:

• Run it before filing, not after. A reconciliation that runs post-submission finds errors you have already reported.
• Give the bridge an owner. The reconciling items are institutional knowledge; if they live in one person’s spreadsheet they leave when that person does.
• Re-baseline on framework releases. A definitional difference is defined by two framework versions. When either changes, the expected size changes with it — and an unchanged expectation will start producing false alarms or, worse, absorbing a real one.

FAQ

Related: Building a reporting pipeline · Resubmissions and corrections · Validation rules