What a bank reconciliation statement has to prove, as a data object

A bank reconciliation statement asserts one thing: at a stated instant, the balance the bank reports and the balance the ledger reports differ by exactly the sum of a named list of items, each with a reason to exist. It is not a report you print at month end. It is a claim with 2 sides and a list, and everything useful about it — reviewability, re-derivation, an audit trail — follows from storing it as that claim.

Neither balance is the truth. The bank's figure reports what the bank booked, excluding anything not yet processed. The ledger's includes payments issued that nobody presented. They are 2 partial views, and the reconciling list is the function mapping one onto the other.

Both sides must be as at the same instant, and usually are not

The commonest defect in a stored reconciliation is that its 2 sides were captured at different moments. A statement closing balance is as at the end of a banking day; a ledger balance pulled from Xero or QuickBooks Online 3 hours later includes that morning's postings. The difference then holds real activity, and the list absorbs it.

• Pin the as-at instant and store it. Both balances are then defined against one point, not against whenever a query ran.
• Snapshot the ledger side at that instant rather than querying live at review time, or the object changes whenever somebody opens it.
• Use the bank's booked balance, never its available balance. Available includes holds and pending items, so reconciling against it is not reconciling.

Four kinds of item explain the gap, and only three may be carried

The fourth row quietly ruins reconciliations. An error parked on the list balances the arithmetic perfectly and sits there for a year, because nothing in the object distinguishes waiting from wrong. Type the item and the distinction becomes queryable. Confirm row 2's staleness period with the bank rather than assuming a number: it follows local practice and the instrument, not accounting convention.

An item's age is the only field that says whether it is still timing or has quietly become an error.

The fields that let someone else recompute it months later

• Identity. Account, as-at instant, period, version — a corrected attempt is a new version, not an edit.
• The bank side. Closing balance, currency, and a reference to the source artefact.
• The ledger side. Balance at the same instant plus the lock state, so a later reader knows whether the period could still move.
• The item list. Per item: type, amount, sign, first-seen date, age in days, evidence link, and an expected clearance date that makes an overdue item detectable without anyone reading it.
• The residual after items, which must be 0, stored explicitly.
• The match set — the identifiers matched — which allows recomputation, and why what a tickmark means when a machine put it there matters as much as the match.
• Preparer, reviewer, both timestamps. A reconciliation with 1 name on it is a calculation, not a control.

A difference of zero is not the same as a reconciled account

Zero proves arithmetic. It says nothing about whether the right transactions were matched, and there are 3 ordinary ways to reach it wrongly.

1. A plug. Someone posted a balancing entry to force agreement, detectable because it has no evidence and no counterparty — which is why the evidence link is required.
2. Offsetting mismatches. Two transactions matched to the wrong partners for the same amount net to nothing — reading a recurring difference by its shape is the separate diagnostic in the reconciliation out by the same small amount.
3. A clean zero over a rotting list. Every item ticks, the residual is nil, and the list holds 14 unpresented payments older than 6 months. Impeccable arithmetic; unreconciled account.

Completeness therefore needs a second test beyond the residual: nothing past its expected clearance date, nothing without evidence. Both are computable, so both can be a gate rather than a review comment. That is what makes reconciliation state usable at close beside flux analysis and the thresholds that make it useful — one control proves the cash, the other explains the movements.

Modelling the assertion properly is a bounded build: one object, a typed item list, 2 computed gates, a version history — the sort of narrow first system we scope as an MVP and product build, inside the reconciliation and close topic for accounting and tax practices.

• bank reconciliation
• close
• data model
• controls