Bank reconciliation: matching books to the statement

The purpose of a bank reconciliation is not to make two numbers equal. It is to explain, item by item, why they are not, and to be left with nothing unexplained.

The balances differ because they are maintained by two parties who learn about events at different times. Your books record a cheque when you write it. The bank records it when it is presented and cleared, which may be days later. The bank records a service charge when it deducts it, and your books record it when you notice. A payment gateway deducts its fee before remitting, so the amount that lands is not the amount your invoice said. None of these is an error by either side. Both records are correct about what each party knew.

This is why an expectation of a zero difference on the first attempt is misplaced. In a business with any real volume, some divergence on any given day is the normal state, and a reconciliation that comes out exactly level immediately is more often a sign that something was forced to match than a sign of unusual accuracy.

What the exercise is really doing is using the bank statement as an independent witness. It is the only record in your accounting system that your business did not produce, which is precisely what makes it capable of testing everything else.

The mechanics are the same whether done on paper or in software, and doing one by hand once is the best way to understand what the software is doing.

Start with a defined period and a closed set of books for it, because reconciling a period that is still being edited means repeating the work. Take the bank statement for exactly that period and the ledger for the same account.

Then match. Work through the statement and find each entry in the books, ticking both sides. Match on amount and date together rather than amount alone, because amount alone produces false matches whenever a business has repeating payments of identical value, which most do. Where the amounts differ slightly, note the difference rather than adjusting it, because a small unexplained difference is usually a fee or a partial payment and both are findings.

What is left after matching falls into two groups, and keeping them separate is the whole discipline. Items in the books with nothing in the bank: cheques issued but not cleared, deposits recorded but not yet processed, and payments recorded that never actually happened. Items in the bank with nothing in the books: charges, interest, direct debits, customer payments received without notification, and transactions nobody entered.

Then prepare the statement of reconciliation: start with the bank balance, adjust for each unmatched item with its explanation, and arrive at the book balance.

The two groups above contain two fundamentally different things, and confusing them is the most common way a reconciliation ends up meaningless.

A timing difference is an item both parties will eventually record, currently known to only one. A cheque issued on the twenty-eighth and cleared on the third is a timing difference. It requires no correction at all, because both records are right and the gap closes by itself. The correct treatment is to list it and expect it to disappear next period.

An error is an item that will not resolve on its own. A payment entered twice, an amount entered with transposed digits, a bank charge nobody recorded, a receipt credited to the wrong customer, a transfer between your own accounts recorded on one side only. These need a correcting entry.

The test that separates them is a question about the future: will this item appear on the other side without anyone doing anything? If yes, it is timing. If no, it is an error and somebody has to act.

The reason this distinction earns a section of its own is that a timing difference carried forward month after month stops being a timing difference. An uncleared cheque still outstanding after several months is not waiting to clear; it is probably lost, cancelled, never sent, or the payment was made another way and recorded twice. Ageing the unmatched items, rather than just listing them, is what surfaces that.

A handful of transaction types account for most of the time spent on a stubborn reconciliation, and knowing them shortens the search considerably.

Net settlements are the first. Payment gateways, marketplaces and card acquirers deduct their charges and sometimes tax before remitting, so a single credit in the bank represents several sales minus several deductions. Matching it against one invoice is impossible, and the correct treatment is to record the gross and the deductions separately from the settlement report, not to record the net as revenue, which quietly understates both sales and expenses.

Transfers between your own accounts are the second, because they appear twice and are frequently recorded once. They are also the classic cause of a difference that equals exactly the transfer amount, which is a useful clue: a difference matching a round number that also appears elsewhere in the statement is usually a one-sided transfer.

Partial payments and short payments are the third. A customer pays slightly less than the invoice, deducting something for a dispute or a deduction of tax at source, and the receipt does not match the invoice. Forcing it to match writes off the balance without a decision being taken.

Cash is the fourth and it is different in kind. Money that never entered the bank cannot be reconciled against it. Cash sales and cash expenses must be reconciled against a physical count instead, which is a separate exercise, and a business that reconciles only its bank has left its least evidenced transactions untested.

Sometimes the work is done and a difference remains. What happens next determines whether the reconciliation was worth performing.

The wrong move, and the common one, is to post an adjusting entry for the amount to a head called suspense or difference in books, and move on. This makes the two balances agree and destroys the information. The books now assert something that was never verified, next month starts from a base containing a known fiction, and if the cause was systematic it will recur invisibly, adding a second adjustment to the first.

The right move is to keep the difference visible and treat it as an open item with an owner and a date. A reconciliation that reports a balanced position and an unexplained remainder of a stated amount is more useful and more honest than one that reports a perfect match achieved by a plug, because the first tells you exactly how much of your own record you cannot vouch for.

Some differences are worth a size threshold, below which the search is not economic, and setting that threshold openly is legitimate. What is not legitimate is letting the threshold hide a pattern: many small differences all in one direction is not a rounding issue, it is a systematic problem presenting in small pieces, and the direction is the clue. Write down what was investigated and what was concluded, even when the conclusion is that the cause could not be established, because a note of that kind is what lets someone recognise the same thing recurring.

A completed reconciliation with everything explained proves something precise and narrower than it feels: every movement of money through that bank account is accounted for in your books, and every entry in your books relating to that account corresponds to a real movement or to a listed timing difference.

That is a strong statement about completeness of banked transactions. It is silent on three things.

It says nothing about classification. A supplier payment recorded consistently against the wrong expense head matches the bank perfectly, because the reconciliation compares amounts and dates, not the correctness of the account chosen. Reconciled books can be misclassified from top to bottom.

It says nothing about transactions that never touched the bank. A cash sale never recorded leaves both sides undisturbed, so the reconciliation balances precisely and the revenue is missing. This is worth stating plainly because a clean reconciliation is often taken as assurance about the books generally, and it is not.

And it says nothing about whether the underlying transactions were legitimate.

That is also the boundary for automated matching. Software can compare a statement to a ledger, propose matches by amount and date, learn recurring patterns, and report the unmatched remainder without shrinking it. Suggesting matches is genuinely most of the labour. What it cannot know is which of two identical payments a credit relates to, whether a difference is a fee or an error, or that a transaction it has never seen exists. A matching engine that resolves ambiguity by picking the most probable option is a matching engine that occasionally hides exactly the item you needed to see.