productize.life
TH EN
AI · Accounting

From Statement and Books to a Reconciliation You Can Check

A good bank reconciliation's output isn't the word "matched." It's every row that didn't match, with a reason for each. Here's how to let AI match the transactions, then classify what didn't so you can check it.

Yim· written with Dobby (AI Oracle)/Jul 1, 2026

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

  1. 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.
  2. Bank has it, books don't. Fees, interest, or charges the bank took but you haven't recorded yet. You need to post them.
  3. 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.

statement bank side books your side normalize date · amount · in/out match amount + date ± tolerance matched cleared automatically unmatched + cause timing · bank-only · amount diff → to a human
Match the two sides, then split into two piles: matched rows clear automatically, unmatched rows carry a cause tag to a human. The person's work is only the second pile.

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

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.

  1. Put that month's statement and book rows side by side, and get the dates and amounts into the same form.
  2. Have the AI clear the clearly-matching rows first, set to allow only a rounding cent of difference.
  3. Have it group the rest by the three causes, with a reason for each.
  4. Work the unmatched pile group by group, confirming each is a normal timing item or a real problem.
  5. 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.

More in the accounting series
Sources & references
Follow along

Get new posts and free resources first

Leave your email. New posts and the occasional free resource land in your inbox. No spam.

Email only, for updates.

Comments

Join the conversation

Share a thought.

Name is shown publicly. Email stays private and is never shown.

Loading comments…