Bank Reconciliation Process: A Worked Example

The bank reconciliation process compares a bank’s closing position with the accounting cash balance, explains every difference, posts supported corrections, and retains evidence of review. The following example uses one euro current account for 31 July.

Starting evidence

The preparer obtains:

• the bank’s July statement, showing account identity, currency, opening balance, all booked movements and closing balance;
• the July cash-ledger detail and trial-balance amount;
• June’s signed reconciliation and its outstanding items;
• supporting documents for charges, transfers and disputed entries.

The bank statement closes at €48,200. The cash ledger closes at €47,730. The difference is €470, but that number alone says nothing about its cause.

Step 1: prove both populations

First agree the bank statement’s opening balance to June’s closing statement. Agree the ledger opening balance to June’s signed reconciliation and the accounting roll-forward. Recalculate:

opening balance + credits − debits = closing balance

Do this independently for the bank and ledger populations. Check that the export covers the entire period, all pages or API pages are present, and booked transactions have not been filtered out. A line-by-line match performed on an incomplete feed can look successful while the closing balance remains wrong.

Step 2: match clear transactions

Using transaction identifiers where available, then amount, currency, date, reference and counterparty, match entries represented in both records. Preserve each source line and store the relationship rather than deleting matched rows.

After matching, four items remain:

1. A €600 customer receipt booked by the bank on 31 July is absent from the ledger.
2. A €30 bank charge is absent from the ledger.
3. A €400 supplier payment recorded in the ledger on 31 July is not booked by the bank until 1 August.
4. A €100 receipt appears twice in the ledger but once at the bank.

Step 3: classify before correcting

Items 1, 2 and 4 require accounting action:

• Post the customer receipt: debit cash €600 and credit accounts receivable or an appropriate unapplied-cash account €600, depending on whether the payer and invoice are established.
• Post the bank charge: debit bank charges €30 and credit cash €30, with supporting bank evidence.
• Reverse the duplicate receipt entry: debit the account incorrectly credited and credit cash €100, preserving the correction’s link to the original journal.

Item 3 is a timing difference. The payment exists in the ledger and subsequently clears at the bank. No new July journal is needed if the original entry is valid. Retain the 1 August bank evidence and list it as an outstanding payment at 31 July.

Step 4: calculate the adjusted balance

The ledger adjusts from €47,730 as follows:

€47,730 + €600 − €30 − €100 = €48,200

The adjusted ledger now agrees directly to the bank’s €48,200 closing balance. Why does the €400 outstanding supplier payment not create a remaining difference? In a complete real reconciliation it normally would affect the bridge between bank and ledger. The fact that the figures already agree indicates that one of the starting facts or classifications is inconsistent.

This is precisely the control point a worked process should expose. Re-checking reveals that the stated ledger closing balance already included the €400 as a bank-side reconciling adjustment copied from a worksheet rather than the raw trial balance. The preparer replaces it with the raw ledger balance of €48,130.

The corrected calculation is:

€48,130 + €600 − €30 − €100 = €48,600 adjusted ledger

€48,200 bank balance + €400 outstanding payment = €48,600 adjusted bank

Both sides now agree. The initial inconsistency was not solved with a plug; it was traced to an unsuitable source balance.

Step 5: document and review

The reconciliation should show:

• account, entity, currency and period;
• raw bank and ledger balances;
• each adjustment and journal reference;
• each timing item, origin date, expected clearing date and subsequent-clearance evidence;
• unresolved items, owners and due dates;
• preparer and reviewer sign-off dates.

The reviewer should inspect source balances, challenge unusual or old items, sample matches, verify journals and recalculate the bridge. Review is not merely changing a status to “approved.”

Integration considerations

Bank APIs may paginate transaction results and distinguish booked from pending transactions. For example, Enable Banking documents date filters, continuation keys and transaction-status filtering for its transaction endpoint. Integration partners should test pagination, retries, stable identifiers, time zones and duplicate delivery against the provider’s API reference.

Value date and booking date can also differ. Use the company’s documented cut-off policy consistently and retain both fields rather than silently replacing one with the other.

In Invunion

Invunion’s alpha scope centres on issued-invoice and incoming-payment matching. It may assist with the €600 receipt once invoice and bank data are available, but that is one part of this example. Bank fees, supplier payments, ledger completeness, closing-balance proof and journal posting remain outside that narrow matching conclusion unless current alpha capability is expressly verified.

Use Invunion output as supporting work, review it against source data, and retain the full account-level reconciliation. Confirm available imports, statuses, export evidence and correction workflows with the product team before designing a close dependency.

Sources

• Enable Banking, API reference
• European Central Bank, TIPS

Updated 5 August 2026

Was this article helpful?

Feedback helps us improve the next version of this article.

Yes Not yet Tell us what is missing