Automating bank reconciliation with AI

Bank reconciliation has a property that makes it unusually suited to automation: there is an objectively correct answer, and it is checkable. Either the ledger agrees with the statement or it does not. No judgement about treatment, no estimate, no opinion.

So why does it still take three days at many month ends?

Because the matching is only the easy half. The hard half is everything that does not match, and that is where the work has always been.

What the feed changed, and what it did not

Direct bank feeds removed the typing. Transactions arrive structured — date, amount, description, reference — without anyone keying a statement.

What feeds did not remove is the matching problem. A payment of RM 14,382.50 leaves the bank. Which invoices does it settle? The reference field says "PYMT" or is empty, or contains a supplier's own internal number that means nothing in your ledger.

Rule-based matching handles the clean cases: exact amount, exact reference. It fails on everything else, and everything else is where the days go.

The four cases that consume the time

One payment, several invoices. A customer settles nine invoices with one transfer, less a credit note. The amount matches no single invoice. Finding the combination that sums correctly is arithmetic a person does slowly and software does instantly — and can then show you which nine.

Payments with deductions. The customer paid RM 340 less than invoiced. Settlement discount, disputed line, short delivery, or an error. The match is nearly right, which is worse than clearly wrong because it needs investigating.

Timing differences. Cheque issued in March, cleared in April. Payment initiated on the 30th, landing on the 2nd. Genuinely unreconciled at period end, and correctly so — the skill is distinguishing this from a real error.

Transactions in the bank and nowhere else. Bank charges, interest, direct debits nobody told finance about, a customer paying an invoice that was never raised. These are not matching problems; they are missing-record problems.

Automation genuinely helps with the first two, flags the third correctly, and — importantly — makes the fourth visible rather than letting it hide in an unexplained difference.

What a well-built process looks like

• Feed in, continuously. Not a monthly import. Reconciliation as an ongoing state rather than a period-end event is the change that removes the scramble.
• Automatic matching on high confidence. Exact matches and strong combination matches post without review.
• Proposals on medium confidence. "This payment appears to settle these nine invoices less this credit note" — with the arithmetic shown, so a person confirms rather than reconstructs.
• Exceptions with reasons. Not an undifferentiated unmatched list, but grouped: short payments, unidentified receipts, items over 30 days old.
• Recurring items learned. The monthly bank charge, the standing order, the subscription. After a couple of cycles these should not require attention.

The design target we work to is around 98% of lines matched without a person — deliberately not 100%, because the remainder is genuine ambiguity that a human should look at. A vendor claiming 100% is either not counting exceptions or absorbing them somewhere.

The residue, and why it matters

What is left after automation is not noise. It is usually the most financially significant thing in the reconciliation.

An unidentified receipt sitting for two months might be a customer paying an invoice you never issued. A recurring short payment might be a customer applying an unauthorised discount across every invoice. A direct debit nobody recognises might be a subscription that should have been cancelled a year ago.

These were always there. Manual reconciliation tended to bury them, because when the whole task is exhausting, the instinct at day three is to clear the difference and move on. Automation's real contribution is that it hands you a short list where these are the only things left — which makes ignoring them a visible decision rather than an accident.

The trap: the balancing figure

The single worst practice in reconciliation, and it survives into automated systems.

If items do not match, they can be written off to a suspense or adjustment account to make the reconciliation balance. Done occasionally with investigation, that is legitimate. Done routinely, it means the reconciliation is not a control any more — it always balances, so it can never tell you anything is wrong.

Automation makes this trap easier to fall into, because the write-off can be automatic. Ask any system: what happens to what it cannot match, and is there anything that gets absorbed into a balancing figure without a person deciding? That is the difference between reconciliation and the appearance of reconciliation, and it is what full traceability means in practice.

Realistic expectations

Week one: matches on the obvious, learns your recurring items, produces a long exception list that is mostly historical mess.

Month two: exceptions drop sharply as recurring patterns are learned and the historical backlog is cleared.

Steady state: reconciliation is continuous, month end is a review rather than a task, and the exception list is short enough to work daily.

The businesses that do not reach steady state are almost always the ones that never cleared the historical backlog — old unreconciled items accumulate, the queue never gets short, and it stops being worked.

Common questions

Can AI fully automate bank reconciliation?

It can match the large majority of transactions without human intervention, including multi-invoice payments and payments with deductions, but not all of them. A realistic design target is around 98% of lines matched automatically, with the remainder being genuine ambiguity — unidentified receipts, disputed short payments, timing differences — that requires a person. Claims of 100% automation usually mean exceptions are being hidden rather than resolved.

Why doesn't my bank feed solve reconciliation?

A feed removes the data entry but not the matching. Transactions arrive structured, yet the reference fields are frequently empty or contain the counterparty's own numbering, so working out which invoices a payment settles remains unsolved. That matching problem, particularly for payments covering multiple invoices or arriving short, is where reconciliation time is actually spent.

What should happen to transactions that cannot be matched?

They should appear in an exception queue grouped by reason — short payment, unidentified receipt, aged item — and be investigated rather than written off. Routinely clearing unmatched items to a suspense or adjustment account makes the reconciliation always balance, which removes its value as a control entirely, since it can no longer indicate that anything is wrong.

How long does automated bank reconciliation take to settle in?

Typically a month or two. The first weeks produce a long exception list that is largely historical mess, which drops sharply once recurring items are learned and the backlog is cleared. Businesses that never clear the historical backlog tend not to reach steady state, because the queue stays long enough that people stop working it.

Related: what full traceability actually means · the exception queue as a control · AI in accounting