Summarise the article with your AI
Here you can read:
Bank reconciliation is the process of matching transactions on a bank statement against entries in the general ledger of a company to confirm that both records agree. Finance teams reconcile to catch errors, fraud, and timing differences, ultimately closing the books on cash figures they can confidently trust.
What is bank reconciliation?
Bank reconciliation in accounting explained simply: it compares two records that should mimic the same business transaction: the bank statement issued by a bank, and the general ledger account in the accounting system reflecting the transaction. If everything were perfect there are two mirror transactions that match to the penny. In practice, however, this is not always the case. Transactions typically hit the bank statement and the ERP record at different times, charges and interest may appear in one place before the other, multiple payments may correspond to a single ERP lodged invoice and any types of errors can happen.
The goal with reconciliation in not to make two numbers equal but rather to explain any difference: why the bank statement says one thing and the ledger says another, what one needs to correct, and what to document.
Bank reconciliation, that can also be partly automated with the human always making the ultimate decisions, sits within a broader family of account reconciliation automation that finance teams run, including customer (accounts receivable) reconciliations, supplier (accounts payable) reconciliations, and intercompany reconciliations. Yet, the bank reconciliation is the most foundational, because cash is both the most liquid asset and the most susceptible to misstatement or errors.
Cash book vs general ledger
The cash book is the internal running record of money in and out of a bank account. In most accounting systems it occupies the bank general ledger account.
Bank statement vs general ledger (bank-to-book)
Reconciling the bank statement to the general ledger is sometimes also called bank-to-book reconciliation. The bank statement is the external source of truth for which payments actually cleared; the general ledger is what a firm has recorded. Bank-to-book reconciliation connects the two and proves the cash received links to sales and the cash spent links to expenses.
Why bank reconciliation matters for finance teams
For a finance team, reconciliation is the foundation of a fast, reliable close. Three reasons make it non-negotiable:
Accurate records and audit-readiness
UK companies must keep adequate accounting records under the Companies Act 2006 and file accounts at Companies House.. Reconciliation is how a business meets that obligation. Auditors may ask for the reconciliation statement, supporting bank statements, and evidence that each reconciliation was reviewed and signed off.
Error and fraud detection
Reconciliation surfaces duplicated payments, missing receipts, unauthorised transactions and bank errors while they are still easy to fix. ICAEW's guidance for finance professionals explicitly lists bank reconciliation as a key cash management control. Regular reconciliation tends to go hand in hand with earlier fraud detection.
A cash position you can act on
Unreconciled accounts mean unreliable reporting and a slower close. Reconciling the ledger and a finance leader can release cash figures to the board with confidence, because the forecast is built on real cash rather than guesses.
How to do a bank reconciliation, step by step (in 5 steps)
The manual bank reconciliation process is the same whether you use a spreadsheet or an accounting system.
Step 1: Gather the bank statement and the cash book for the period
Use the same start and end dates for both. Confirm that the opening balances agree with the closing position of the previous reconciliation. Watch out for this: reconciling a statement period that doesn't line up with the ledger period creates permanent "differences" that are actually just date mismatches.
Step 2: Match transactions line by line
Tick off every transaction that appears in both records, matching on amount, date and reference or payee. Whatever remains unticked is a difference to explain. A common mistake: matching on amount alone, which pairs up two unrelated transactions that happen to be for the same figure.
Step 3: Identify and adjust the bank-side items (timing differences)
These appear on one record because of timing and do not require a journal entry: BACS payments in transit (initiated but not yet cleared), uncleared card terminal batches (deposits recorded in your books but not yet on the statement), and genuine bank errors (which the bank will correct). A common error is posting a journal for a bank-side item; a deposit in transit is not a new transaction, it is one you already recorded.
Step 4: Identify and post the book-side items
These are real transactions the bank processed, but you have not recorded, so they do require a journal entry: bank charges, interest, direct debits, failed direct debits, and any posting errors of your own. A common error is leaving these unrecorded until next month, which understates expenses and overstates cash.
Step 5: Confirm the adjusted balances match.
After adjustments, the adjusted bank balance should equal the adjusted cash book balance. Any difference left over needs investigation before you sign off.
The three methods: manual, CSV import and bank feed
The three most common ways to run a bank reconciliation:
Manual reconciliation
Comparing a printed or downloaded statement against the ledger by hand. Cheap and universal, but slow and error-prone at volume.
Download and import (CSV)
Export the bank statement and import it into your accounting system, which often already suggests automated matches. Faster, but still batch-based and dependent on file quality.
Bank feed
A direct connection streams transactions from the bank into the accounting system in near real time, so reconciliation runs continuously rather than once a month. This method drops the manual burden most, because continuous reconciliation becomes practical. Modern treasury platforms with bank connectivity support this approach.
Bank-to-GL matching and posting
How does each transaction get matched to the right open item and posted to the correct account? This is where reconciliation either scales or breaks.
One needs to answer two questions for each transaction: which document or ledger account does this belong to, and what posting is correct? This is rarely one-to-one. A single payment might settle several invoices, or one invoice might be paid across several transfers, or a receipt might be a customer payment net of a deduction.
For example, a customer payment of £1,200 referencing invoice INV-1045 must be matched and posted correctly: a debit to your cash at bank ledger (e.g., GL code 1200) and a credit to the trade receivables account (e.g., GL code 2100).
Whatever cannot be matched with confidence goes to an exception queue for a person to review, rather than being forced. The size of that queue is the real measure of how well your matching works.
Rule-based vs AI/Machine Learning matching
Rule-based matching applies fixed rules, for example, "payments referencing PAYROLL post to wages". It works reliably for repetitive, predictable transactions, but fails when a reference format changes or a payment groups several invoices, and you need a new rule for every new case.
AI and Machine Learning matching reads context the way a person would, learning from past decisions to match partial and grouped payments and to suggest the right general ledger account without requiring a rule for every scenario. Many finance teams use both: rules for the predictable majority, contextual matching for the long tail. The key is that the human always stays in control even with AI based matching as an assistant. The architecture is designed to propose matches, but the human always stays in control of the final financial data.
Reconciliation at scale: multiple banks, entities and currencies
Reconciling one account once a month is straightforward. Scale is the difficulty: dozens of accounts across several banks and legal entities, some in different currencies. Manual reconciliation stops working at that point, because the volume grows faster than the team.
Multiple entities
Each legal entity reconciles against its own general ledger, but the group needs a single, consolidated view. The practical challenge is running the same disciplined process across every entity, on the same calendar, so that consolidation rests on ledgers that are all reconciled.
Multiple currencies
A foreign-currency account creates conversion differences between the date a transaction is recorded and the date it settles. You need a consistent policy for which rate applies and you need to post the resulting FX difference so the account reconciles in both the transaction currency and the functional currency.
Controls and team workflow
Reconciliation is also a control, so it needs strict governance, in line with guidance from professional bodies such as ICAEW:
- Segregation of duties (SoD): The person who prepares payments should not be the person who reconciles the account, and ideally not the person who approves the reconciliation.
- Approvals and sign-off: Each completed reconciliation should be reviewed and approved, with the reviewer named.
- Audit trail: Every posting and sign-off should record who did what, when, why, and against which document.
A hypothetical example: the reconciliation statement and the journal entries
Hypothetical Business Machines of Mercia Ltd is reconciling its main account on 31 May 2026. Cash book balance: £12,500. Bank statement closing balance: £13,000.
After matching, these items remain:
| Item | Type | Treatment |
|---|---|---|
| BACS payments in transit £1,200 | Bank-side (timing) | Deduct from bank balance. No journal entry. |
| Card terminal batch in transit £450 | Bank-side (timing) | Add to bank balance. No journal entry. |
| Bank charges £45 | Book-side | Post journal entry. |
| Interest received £30 | Book-side | Post journal entry. |
| Failed direct debit (customer) £75 | Book-side | Post journal entry. |
| Direct debit (insurance) £160 | Book-side | Post journal entry. |
Reconciliation statement:
| Cash book side | £ | Bank statement side | £ |
|---|---|---|---|
| Balance per cash book | 12,500 | Balance per bank statement | 13,000 |
| Less: bank charges | (45) | Less: BACS payments in transit | (1,200) |
| Add: interest received | 30 | Add: Card batch in transit | 450 |
| Less: direct debit | (160) | ||
| Less: failed direct debit | (75) | ||
| Adjusted cash book balance | 12,250 | Adjusted bank balance | 12,250 |
Only the book-side items require corresponding journal entries in the ledger to reflect the reality of the statement. The timing differences naturally clear in the following period.
Common pitfalls and how to handle exceptions
- Rolling differences forward: Never carry an unexplained difference into the next period. Investigate it while the trail is fresh.
- Aged unreconciled items: Payments in transit more than a few months old usually mean a posting error. Set a threshold to review and clear them.
- Forcing a match: Adjusting the ledger just to make the numbers agree hides the real problem. Every adjustment needs a reason and a document.
- Leaving the period open: If a reconciliation can still be edited after sign-off, it isn't a control. Lock the period once you've reconciled and approved it.
Automating bank reconciliation
Automation doesn't change the accounting; it removes the manual work around it. Bank feeds bring transactions in continuously, matching engines clear the predictable majority, and the team reviews only the exceptions. By month-end you're reviewing exceptions rather than running a full match, because the ledger is already reconciled.
Modern treasury management platforms connect directly to banks and ERPs, apply intelligent matching rules, and post reconciled entries back to your general ledger automatically.
