Common Bank Reconciliation Errors and How to Prevent Them

The most dangerous reconciliation error is not an obvious difference. It is a false agreement: the balances appear to reconcile, but transactions are missing, duplicated, allocated to the wrong invoice, or cleared with an unsupported journal.

The following errors occur in both manual and automated processes. The control objective is not to eliminate every exception; it is to make exceptions visible, explainable and reviewable.

1. Incomplete bank data

An export may omit an account, date, page, currency, transaction status or API page. A preparer then matches everything received and assumes the population is complete.

Prevention: agree account identity and statement closing balance; recalculate the bank roll-forward; record query dates and filters; process every continuation token; and compare transaction counts and sums between raw and transformed data. Preserve the original response or statement.

2. Duplicate imports

Overlapping date windows, retries and changed provider identifiers can load a transaction twice. Matching both copies may close two invoices against one real receipt.

Prevention: use an idempotent import design. Prefer a stable provider transaction identifier, but combine it with account, status, amount, currency, dates and references where lifecycle changes are possible. Do not deduplicate solely on amount and date: two genuine payments can be identical.

3. Confusing pending and booked transactions

Pending entries can change amount, disappear, or reappear with a booked identifier. Treating them as final can produce premature allocations and reversals.

Prevention: represent status explicitly. Define whether pending items are informational or eligible for provisional matching, and only close accounting items when the organisation’s policy permits. The Enable Banking transaction API reference documents transaction-status filtering; actual status availability depends on the bank connection.

4. Wrong sign or currency

A debit represented as a negative amount in one source and as a positive amount plus direction in another can be inverted during transformation. An equal numerical amount in EUR and GBP is not an equal economic amount.

Prevention: define a canonical signed-amount convention and test credits, debits, refunds and reversals. Store original amount, original currency and any converted reporting amount separately. Never match cross-currency items merely because displayed numbers agree.

5. Over-reliance on amount and date

Round-value receipts and recurring invoices create plausible but incorrect candidates. A close date is not proof of a relationship.

Prevention: combine independent evidence such as invoice reference, verified payer, remittance advice and open-item context. Require review where two candidates are similarly plausible. Keep thresholds conservative and documented.

6. Reference normalisation that destroys evidence

Removing spaces and punctuation can help compare INV-1042 with INV1042. Excessive cleaning can merge distinct identifiers or discard leading zeroes.

Prevention: keep raw and normalised fields. Version transformation rules, test them against real formats, and show reviewers the original remittance text.

7. Incorrect cut-off

Teams may mix transaction date, booking date, value date and ledger posting date. Month-end items then land in inconsistent periods.

Prevention: document the accounting cut-off basis and preserve all supplied dates. Check transactions around midnight, weekends and holidays. The ECB notes that TIPS operates around the clock, while associated business-day and value-date conventions still matter; see the ECB TIPS information.

8. Forced balancing entries

A “reconciliation difference” journal makes balances equal without explaining the underlying transactions. This can mask missing income, duplicate expenses or fraud.

Prevention: every adjustment needs a business reason, account coding, evidence, approver and link to the reconciling item. Use suspense only under a defined policy, with ownership and ageing.

9. Ignoring reversals and returns

A receipt can be returned after an invoice was marked paid. If the reversal is handled as an unrelated debit, receivables remain understated.

Prevention: identify lifecycle relationships where data supports them. Reverse the allocation traceably, reopen the invoice when appropriate, and retain both original and reversal records.

10. Clearing old differences without resolution

Ageing items may be carried forward mechanically or deleted during “clean-up.”

Prevention: age by origin date, assign an owner, define escalation thresholds, inspect subsequent clearing, and apply approved write-off policies. Carry-forward is not evidence.

11. Weak segregation and review

The same person can import, match, post adjustments and approve the reconciliation. Even accurate work lacks an effective challenge.

Prevention: separate preparation and review where staffing permits. At minimum, require targeted review of manual journals, overrides, changed rules, unusual counterparties and aged exceptions.

A practical error check

Before sign-off, ask:

• Do raw bank and ledger control totals roll forward?
• Were all accounts, currencies, statuses and API pages included?
• Can every deleted, merged or transformed record be traced?
• Do allocations respect transaction and invoice residuals?
• Are corrections and overrides evidenced?
• Did timing items clear subsequently?
• Does an independent reviewer understand why each material difference exists?

In Invunion

Invunion alpha may assist with candidate matching between issued invoices and incoming bank transactions. It does not remove the need for source-population controls, duplicate detection validation, cut-off policy, journal governance or full bank-account reconciliation.

Teams should test the alpha with representative duplicates, missing references, reversals, pending items, currencies and ambiguous candidates. Verify current behaviour and available audit evidence with the product team. A system that leaves a difficult item unmatched is preferable to an unsupported confident match.

Sources

• Enable Banking, API reference
• European Central Bank, TARGET Instant Payment Settlement

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