Nordlet

Docs / Glossary

What Is Bank Reconciliation? A Step-by-Step Walkthrough

Why the ledger and the bank statement disagree, a worked reconciliation from statement to ledger, and how automated matching handles most of it.

Bank reconciliation is the check that your ledger's bank balance and the bank's own record agree, and the investigation of every difference between them. It is the closest thing accounting has to an external audit that runs every month, because the bank statement is evidence produced by someone with no interest in your books being right.

The check is simple. The reasons the two numbers differ are what make it worth doing.

Why they differ at all

The ledger and the statement record the same reality on different clocks:

  • Timing. You post a supplier payment on 30 June; the bank executes it on 2 July. The money is gone from your books and still in the bank's.
  • Items you didn't know about. Bank fees, interest, FX charges, direct debits, a customer paying without telling you — the bank knows before you do.
  • Errors. Yours (wrong amount keyed, payment posted twice) or, rarely, theirs.
  • Fraud. A payment you never authorized. This is the reason reconciliation is a control and not just tidying: it is often the only routine process that would catch it.

A difference is normal. An unexplained difference is the finding.

The walkthrough

Reconciling June for the running example, in euros:

Step 1 — Fix the endpoints. Ledger balance on account 2710 at 30 June: 6,200 €. Bank statement closing balance at 30 June: 6,845 €. Difference to explain: 645 €.

Step 2 — Import the statement. Load the bank's own file rather than typing from a PDF: camt.053 (the ISO 20022 standard) or the older MT940. Both are supported by POST /v1/bank/statements/import, which creates bank transactions with dates, amounts, counterparty names, IBANs and payment descriptions.

Step 3 — Match what matches. Walk the statement lines against open items:

Statement line Ledger item
+1,210 UAB Alfa, ref. "S-1041" Sale invoice S-1041 — settle in full
−121 Lieferant GmbH Purchase invoice L-77 — settle in full
−18 "Account maintenance fee" Nothing in the ledger — new expense

Step 4 — Post what only the bank knew. The 18 € fee has no document; it is booked from the statement itself:

Account Debit Credit
6800 Financial expenses 18
2710 Bank 18

Step 5 — List genuine timing differences. The 30 June supplier payment of 663 € that the bank executes on 2 July: correctly in your ledger, correctly absent from the June statement. It needs no entry — only listing.

Step 6 — Prove the reconciliation.

Bank statement closing balance          6,845
− payments in transit                    −663
+ fee already deducted by bank, now posted  +18   (already in both after step 4)
= Reconciled ledger balance             6,200 ✓

The ledger balance is confirmed. Anything that cannot be explained at this step is the reason you reconciled.

Step 7 — Lock the period. Once bank, receivables and payables reconcile, the accounting period can close and be locked so the reconciled figures cannot move afterwards.

How much of this is automatic

Most of it. Matching a payment to an invoice is pattern work: amount, reference, counterparty, IBAN. Nordlet's POST /v1/bank/transactions/suggest-matches scores every open invoice against a statement line and returns ranked candidates with the reasons behind each score:

Signal Weight
Amount equals the invoice's remaining balance +50
Document number appears in the payment description +40
Counterparty IBAN matches a partner bank account +30
Counterparty name matches the partner name +20

A payment that hits all four is unambiguous. Confirming a match with POST /v1/bank/transactions/match settles the invoice, posts the ledger entries and updates the invoice's payment status to partial or paid, firing a sale_invoice.paid event that downstream systems can react to.

What stays human is what should: partial payments, one transfer covering five invoices, payments with no reference at all, and anything where the amount doesn't match for a reason nobody has written down. The bank imports guide covers the file formats and the import flow in detail.

Doing it well

  • Reconcile monthly at minimum, weekly if you can. Differences are cheap to explain while they are fresh and expensive to reconstruct a quarter later.
  • Never force a balance. A plug entry to make the numbers agree destroys the entire value of the control. If it doesn't reconcile, something is wrong, and that is information.
  • Reconcile every account. Every bank account, every currency, every card. The account nobody watches is the one with the problem.
  • Investigate old unmatched items. A statement line unmatched for three months is not waiting for its invoice; it is a missing document, a duplicate, or an error.
  • Separate duties where you can. The person who can move money should not be the only person who reconciles it.

FAQ

What is bank reconciliation in simple terms?

Comparing your accounting records of a bank account against the bank's own statement, then explaining every difference — timing, unrecorded items, or errors — until the two agree.

What formats can bank statements be imported in?

Nordlet supports camt.053 (the ISO 20022 XML standard used across SEPA) and MT940, the older SWIFT format still offered by many banks. Both are imported through the same endpoint and produce identical bank transactions.

What is a reconciling item?

Anything that legitimately explains a difference between the two balances at a point in time — most commonly payments issued but not yet cleared, deposits not yet credited, and bank charges not yet recorded in the ledger.

How often should bank reconciliation be done?

Monthly is the accounting minimum, because the period cannot be closed reliably without it. Weekly or daily is better operationally: it keeps the receivables picture current and shortens the window in which an unauthorized payment goes unnoticed.

What if the reconciliation doesn't balance?

Then stop and find the cause — that is the point of the exercise. Common causes are a transaction posted twice, an amount keyed wrongly, a payment posted to the wrong account, or a statement line nobody recognizes. Never post a balancing entry to make the difference disappear.