Account Reconciliation as a Month-End Discipline, Not a Software Feature

Reconciliation tools keep arriving inside planning and close platforms, and each announcement invites the same question: does the software do the reconciliation, or do we? Our answer is firm. The software stores, matches, and reports. The reconciliation itself is a bookkeeping judgement, and it stays with you.

This article covers the practice: what a reconciliation actually asserts, how to sequence it inside the close, and where matching automation helps or quietly misleads.

What does a reconciled account actually assert?

A reconciliation is a signed statement that the balance in the ledger is right, and that you can prove it. For a bank account, the proof is the statement. For a balance sheet control account, the proof is a subledger, a schedule, or a working paper that ties to the general ledger to the cent.

That is why reconciliations concentrate on the balance sheet. A profit and loss error usually distorts one period. A balance sheet error compounds. It corrupts every opening balance that follows it, and it can hide for years inside an account nobody reconciles because "it always looks about right."

In what order should you reconcile?

Sequence matters more than speed. We reconcile balance sheet accounts first, in a fixed order, because each reconciliation feeds the next:

1. Cash and credit cards, against statements. These are the most independent evidence you have.
2. Payroll and sales tax liabilities, against filing confirmations.
3. Accounts receivable and payable control accounts, against the aged reports.
4. Inventory, against the count or the valuation working paper.
5. Prepayments, accruals, and every "clearing" or "suspense" account, against a schedule that shows each item and its age.

The last group deserves special suspicion. A suspense account with a balance that survives the close is an unreconciled item wearing a name tag.

What does automation actually do for you?

Matching engines compare the ledger to a source, flag pairs, and surface exceptions. That is genuinely useful. Transaction-level matching is slow, error-prone manual work, and a machine does the first pass better than a tired bookkeeper on day three of the close.

What the machine cannot do is decide materiality, judge whether a difference is an error or a timing cut-off, or recognise that a "matched" pair is actually two different transactions that happen to share an amount. Auto-match confidence is not evidence. Review the exceptions, sample the auto-matches, and keep the reconciliations signed by a person.

How do you tell a timing difference from an error?

This is the core judgement. A timing difference is explained by cut-off: the bank cleared it in the next period, the invoice arrived after the subledger cut, the payment hit before the invoice. It has a known cause, a known direction, and it reverses.

An error does not reverse. It sits there. A duplicate payment, a posting to the wrong account, a transposed amount, an unrecorded bank fee: each needs a correcting entry, not a reconciling item. If a reconciling item appears in two consecutive reconciliations with the same value, treat it as an error until proven otherwise.

What should the working paper contain?

Every reconciliation you sign should show, at minimum: the ledger balance, the independent source balance, a list of reconciling items with dates and explanations, and a clear split between timing items and identified errors. Old items should carry an age, not just a description.

The working paper is the evidence. If a reviewer, an auditor, or a successor bookkeeper cannot reconstruct your reconciliation from it, it was not a reconciliation. It was an opinion.

Where does this stop being routine bookkeeping?

Most reconciliation work is ordinary close work. It stops being routine when the ledger itself is in doubt: when opening balances do not tie to prior reconciliations, when the subledger and control account disagree by amounts no journal explains, or when the data has a history of damage or a botched migration. At that point the problem is not the reconciliation. It is the ledger underneath it, and it needs a specialist rather than another pass at the matching screen.