This follows on from training a finance team to use AI on real work. Once invoice extraction was in place, the next job that eats every month-end was bank reconciliation: taking the bank statement and matching it, line by line, against the transactions in the books.
People tend to think the job is "make the balances agree." Do it a few times and you learn the balances almost never agree on the first pass, because there are always items in transit: cheques not yet cleared, transfers posted on different days, fees the bank took that you haven't recorded yet.
So the real job of a reconciliation isn't making it balance. It's explaining why each row that doesn't match doesn't match. This piece goes in order: why "the balance agrees" isn't the hard part, how to let AI match and then classify what didn't, and how to put it to work on real jobs.
Part 1Why "the balance agrees" isn't the hard part
Most rows on the statement and in the books already agree: same amount, close dates, easy to match. Even across a thousand lines, the clearly-matching ones pair up in a straightforward way, almost all of them.
The part that eats time and attention is what's left: rows one side has and the other doesn't, or has at a different amount. Those rows are the actual work, because each one has to answer whether it's a normal item in transit or a sign that something is wrong.
Unmatched rows come in only a few shapes
- Timing items. A cheque issued but not yet cashed, or an end-of-day transfer posted on different days by each side. It sorts itself out soon.
- Bank has it, books don't. Fees, interest, or charges the bank took but you haven't recorded yet. You need to post them.
- Amounts differ. Close but not exact, usually a typo or a fee deducted from a transfer amount.
Once you see the unmatched rows fall into a few shapes, it's clear where AI fits. It's good at matching large numbers of clearly-matching rows and at guessing which shape a leftover row is likely to be. But signing off that the reconciliation closes is still a person's call.
Part 2Let AI match, then classify what didn't
The approach that works is three steps: get both sides into a comparable form, let AI match, then classify only the rows that didn't match.
Step 1: Get both sides comparable
Before matching, the statement and the books have to be in the same form: one date format, amounts as plain numbers with no symbols, and money-in versus money-out clearly separated. It sounds minor, but skip it and the matching goes wrong from the start, because a different format makes the same transaction look like two different ones.
Step 2: Match, with a tolerance set
Have the AI match rows across both sides by close amount and date, with a clearly-set tolerance for acceptable differences, such as no more than one cent from rounding. The most important rule: never force a match. Rows that don't meet the bar stay unmatched, don't push them together, because one wrong match makes the balance look right while a problem hides underneath.
Step 3: Classify only the unmatched rows
For the rows that didn't match, have the AI group them by the causes from Part 1: timing items, bank-has-it-books-don't, and amount differences, with a note on why each landed in its group. What you get is every unmatched row tagged with a cause, not a pile you have to sort through by hand.
Anyone can follow these three steps by hand. What we put the work into is the tooling that makes the matching and classifying fast and repeatable every month, on the same principle as invoice extraction: the interface stays fixed, the matching engine inside can be swapped, and the guard against a forced match keeps doing its job.
Part 3Putting it to work on real jobs
Where this helps
- Month-end bank reconciliation with too many transactions to work through by hand
- Multiple books, such as several banks and accounts to reconcile one by one each month
- Credit-card or e-wallet reconciliation, where the rows look different but the principle is the same
- Suspense accounts that need a quick daily look to catch odd items before month-end
The one rule to remember
If you take one thing from this article, take this: the goal of a reconciliation isn't the word "reconciled," it's every unmatched row with a reason you can trace. Forcing matches to make it balance faster hides the problem, it doesn't fix it.
Where to start
Don't build automation on day one. Try it by hand on a single month first.
- Put that month's statement and book rows side by side, and get the dates and amounts into the same form.
- Have the AI clear the clearly-matching rows first, set to allow only a rounding cent of difference.
- Have it group the rest by the three causes, with a reason for each.
- Work the unmatched pile group by group, confirming each is a normal timing item or a real problem.
- Count how many rows you couldn't explain. That number is how clean the account is.
Once you can see which pile closes itself and which needs eyes, you'll know how to scale it to many accounts across many months. We teach this to in-house finance teams hands-on, details on the AI training for accounting teams page.
And if you'd rather not assemble the tooling yourself, FlowAccount has AI bank reconciliation built into the accounting system, ready to use: it matches transactions and separates out what doesn't, so you don't start from scratch.
- From a Photo of an Invoice to Import-Ready Data, using AI to extract invoices into import-ready rows
- Filing financial statements online with DBD e-Filing, the steps after closing the books
- Written from real work: a training program for in-house finance teams using Claude Cowork to reconcile and check line items (productize.life/services-en)
- The match-then-classify framework (match, then bucket differences by cause such as timing items) comes from building a reconciliation tool in practice.
- Bank reconciliation and its adjusting entries are a standard accounting internal control.