Making two independently kept records of the same money agree, and proving it
Bank reconciliation is the practice of making two independently kept records of the same money agree, and proving it: your cashbook on one side, the bank statement on the other. The same discipline reaches past the bank to accounts, payments and the documents behind them. The hard part is never the arithmetic. It is the matching, which is why the two figures diverge and what a system quietly puts right.
What bank reconciliation is (and why the two figures never agree)
Your cashbook is what you believe happened; the bank statement is what the bank has settled. They drift apart for one ordinary reason: timing. A £500 supplier payment sent by BACS on a Friday sits inside a three-working-day cycle, so your cashbook shows the money gone while the bank still shows it present. Send it by Faster Payments instead and it lands near-instantly. Neither is an error, just the rails moving at different speeds: the everyday version of two systems that should agree but don't.
An open banking feed, a live bank feed from a provider such as TrueLayer or Plaid, replaces importing statements by hand. Clean, digitally linked records are what let you file a confident VAT return, because Making Tax Digital expects HMRC to see a joined-up audit trail.
Book balance vs bank balance: the book balance is the figure in your cashbook and the bank balance is the figure on the statement, and they rarely match on any given day because payments still in flight belong to one and not yet the other.
Why records never line up (the anatomy of a mismatch)
Every accounting package has a tab for unmatched items, and in most businesses it never quite empties. There is usually one person who can look at a stray bank line and say, with no reference to go on, which customer it belongs to and why it is odd. That knowledge lives in their head, not the system. Timing, the ordinary reason covered above, only explains the easy differences that clear themselves within a few days. The stubborn mismatches come from the shape of the money itself, and they fall into a handful of recurring patterns.
One line, several invoices (one-to-many)
A single £900 bank deposit clears three separate sales invoices at once, so no invoice on its own matches the amount that landed.
Several lines, one invoice (many-to-one)
A customer settles one invoice in two instalments, so neither payment matches the total it is paying down.
A reference-free bank line
A payment arrives with no invoice number and no remittance advice, just a name and a figure, leaving nothing to match it against.
Short by design (partial payment)
A customer takes a £10 early-settlement discount and pays £10 under the invoice, so the two figures never tie exactly.
Fees taken at source
Stripe pays out £970 on a £1,000 sale, having deducted its fee before the cash ever reaches your account.
Currency rounding residue
Converting a foreign payment leaves a 1p difference that no amount of staring will reconcile.
None of these is an error to hunt down. Each is a normal, predictable way for two honest records to describe the same money differently. Naming which pattern you are looking at is the first half of the work. What a system does with that £900 deposit next is the second.
What a matching engine does (and why a spreadsheet can't)
A matching engine is the part of reconciliation software that decides which bank line belongs to which invoice, and it does the one job a spreadsheet cannot: it tests thousands of possible pairings in the time it takes you to scroll a single screen. Instead of one blunt pass, it works as a cascade, trying the cheapest, most certain match first and escalating a line only when it cannot settle it with confidence. Everything the machine clears on its own drops out of sight, so a person only ever sees the leftovers.
| Area | Matching by hand in a spreadsheet | What an engine does |
|---|---|---|
| Finding a match | You scroll the statement and eyeball each line for a customer you recognise. | It tests every open invoice against the line at once. |
| One line, several invoices | You add invoices together by hand until they happen to hit £900. | It searches for the invoice set that sums to the deposit. |
| The awkward customers | One person remembers their quirks, and nobody else can cover. | Their quirks become written rules that run on every line, every time. |
| Proof of the match | A ticked cell with no note of why. | A logged allocation with its reason and a confidence score. |
The stages run in a fixed order, each catching what the one before could not. An exact match clears the obvious lines untouched. A rule-based pass then settles anything that agrees within a set tolerance, a few pence of rounding say. Fuzzy scoring rates the awkward remainder by likelihood, using string-distance measures such as Jaro-Winkler to judge how close a garbled payment reference sits to a real invoice number. Whatever survives all three is genuinely ambiguous, and the engine routes the genuine exceptions to a person.
Follow the £900 deposit through. It is expected to clear three sales invoices of £400, £350 and £150, which sum to exactly £900. The exact match allocates all three and posts them without anyone lifting a finger, touchless and done. A second customer's line arrives at £890 against an expected £900, a £10 early-settlement discount taken at the last moment. It fails the exact match and slips past the £5 tolerance, so fuzzy scoring flags it low-confidence and drops it into the exception queue. A person opens it, recognises the discount, allocates £400, £350 and £140, and posts the remaining £10 to a discount account. The exception is resolved.
Match rate: the number that decides how fast you close
Once a system is doing the matching, you can measure how much of the work it lifts off you. Match rate is that measure: the proportion of bank lines the engine clears on its own, without a person ever seeing them. You will also hear it called the touchless or straight-through rate, and its mirror image is the exception rate, the slice that lands in the human queue. Some share of that queue never goes away, because a few lines are genuinely ambiguous and will always need someone to decide.
Match rate: the percentage of reconciliation lines matched automatically, with no human touch. The remainder is the exception rate, the portion a person has to work by hand.
The number is not fixed, and it climbs as the rules are tuned. Every exception a person resolves is a lesson the system can keep: the customer who always short-pays by their settlement discount, the supplier whose reference is a garbled sort code. Each one gets written down as a rule that clears the same pattern next time without a second glance, so the queue shrinks month on month, one learned quirk at a time.
This is what the month-end close process actually rides on. The close is only ever as fast as the slowest reconciliation to finish, so an account still carrying a pile of unmatched lines holds up the period cut-off and the accruals that hang off it. A high match rate means most of the ledger has settled itself before you sit down, and the close becomes a short review of a handful of exceptions rather than a scramble. That is the quiet engine underneath record-to-report.
Reconciling card and online payments (gross vs net)
Card and online takings arrive already trimmed. Stripe, PayPal and GoCardless deduct their processor fees before the money reaches your account, so the figure that lands never matches the invoice you raised. This is the part of payment reconciliation that defeats naive one-to-one matching, because the amounts are wrong by design. The gap between gross (what the customer paid) and net (what you actually received) is the fee, and it hides inside a batched payout.
A single Stripe payout of £2,910 lands in the bank as one line. Inside it sit three separate £1,000 sales, £3,000 gross, with £30 taken from each, so £90 of fees in total. No £1,000 invoice will ever equal £2,910, which is why matching the bank line against any single invoice fails every time. The fix is to match the payout to the gateway settlement report (Stripe's version of a remittance advice), which lists the three underlying sales and the fee on each. You then book each £1,000 gross sale and its £30 fee separately, so your ledger shows £3,000 of income and £90 of cost rather than a mysterious £2,910. One payout is many transactions minus fees, not one invoice. GoCardless and PayPal batch their settlement payouts the same way, so the same settlement-report approach carries across.
VAT trip-up: The sale and the processor fee carry different VAT treatment, so you cannot net the fee off the sale. Record the gross sale and the fee as separate lines, or your VAT return will be wrong.
Matching the payout to the sales inside it is where this job ends. Chasing and collecting the money is a separate discipline, and it sits with your wider financial operations.
What to do with what will not match (the exception discipline)
Some lines will never auto-match, and no amount of rule tuning changes that. The discipline is not pretending the residue does not exist: it is deciding, deliberately, what happens to it. Earlier we followed a £900 deposit down to an exception where a person recognised a £10 early-settlement discount and posted it. That item got resolved, not parked. When a line genuinely cannot be understood yet, it goes to a suspense account, a holding account that keeps a truly unresolved item out of the profit and loss until you know what it is. A clearing account is different: a temporary staging account money passes through on its way to its proper home.
Those three habits are what separate a reconciliation that closes from one that quietly accumulates unexplained lines nobody owns.
Warning: an ageing pile of unmatched items is exactly where errors and duplicate payments hide. The exception queue has to be worked on a regular rhythm, not parked at the bottom of a spreadsheet and forgotten.
Beyond the bank: account, balance-sheet and three-way matching
A bank feed is only one record among many, and the same matching discipline applies wherever two sets of numbers are meant to agree. Account reconciliation compares a control account in the general ledger against its subsidiary ledger: the sales-ledger control account, for example, against the sum of unpaid customer invoices sitting in the subledger. Balance sheet reconciliation goes a step further. It substantiates a balance, meaning you can show the supporting detail behind the number rather than simply prove that two totals match. A substantiated figure is one you can break down line by line when an auditor or your accountant asks what it is actually made of.
Three way matching is the purchasing-side version of matching more than two records. It checks that three documents agree before a supplier is paid: the purchase order (PO) says what was ordered, the goods received note (GRN) says what actually arrived, and the supplier invoice says what is being billed. All three must line up before payment goes out. You need it when you buy physical goods and want to catch being billed for quantities that never turned up or prices that drifted from what you agreed. That is where automating supplier-invoice matching in accounts payable earns its keep, so the check runs on every invoice rather than the ones someone remembers to look at.
When it is overkill: for services with no physical goods, there is no goods received note to compare against, so a two-way match (purchase order against invoice) is enough. Do not add a GRN step you will never fill in.
The same principle extends to data reconciliation across your business systems: e-commerce takings checked against the ledger, or subscription billing checked against the accounts, so every figure that reaches finance traces back to a source that agrees with it.
Native matching or a custom layer (and what we build)
Most small businesses do not need dedicated reconciliation software. The native bank rules built into Xero, QuickBooks and Sage clear the routine volume perfectly well, and for a lot of firms that is the whole job done. If your feed is mostly one-to-one and the manual queue is short, native matching is the right answer, and paying for anything more would be paying for a problem you do not have. The honest read is that a custom matching layer earns its place at the edges, not in the middle of the road.
| Approach | When it is enough | The limit |
|---|---|---|
| Native bank rules (Xero / QuickBooks / Sage) | Routine, mostly one-to-one bank matching at modest volume, where the built-in rules catch the bulk of the feed. | Struggles with one-to-many settlements, batched processor payouts and multiple feeds, so the match rate drops and the manual queue grows. |
| A custom matching layer | When volume, one-to-many settlements, processor payouts or several feeds push the native match rate down and the manual residue up. | It is a build, so it only earns its keep once the manual cost is real. Do not build it before you need it. |
The trigger to move is simple: when the exception queue is eating real hours every month and the close keeps slipping past the date you promised. At that point we build a custom matching layer that lifts the touchless match rate and shrinks the exception queue down to genuine oddities.
A month-end that mostly runs itself
If reconciliation has stopped being routine, we can talk through where a custom matching layer would pay for itself.
Talk to us about matching →