Categorizing bank transactions looks like an obvious job for AI. We deliberately didn’t start there. Our matching is exact, a person stays in charge, and it’s less impressive than a demo. Here’s why.
What a mistake costs
A wrong movie recommendation costs nothing. A wrong entry in a client’s books can sit there until someone finds it at year-end, and then the work is finding every entry like it. So the question we asked wasn’t “how often is it right?” but “when it’s wrong, how would anyone know?”
Two ways to match, both exact
- Rules. Exactly one active rule has to match the counterparty, account, direction and amount range. A rule starts as a candidate, and only a person can approve it.
- History. At least two approved, uncorrected decisions with the same counterparty, account, direction and exact amount, all allocated the same way.
If neither applies, the transaction goes to a person. There’s no confidence score to argue with: it either matched, or it didn’t.
Automation has to be switched on
Posting without review is off until you turn it on, and then it only applies to exact matches within your own limit, in your base currency, outside closed periods. We suggest building rules for a month first, then starting with a low limit.
A client’s answer always goes to review. It never posts by itself, however confident they sound.
Ask the person who knows
Some transactions can’t be worked out from the bank line, and only the client knows what they were. So they get an emailed link and answer each one, with no account needed. That turned out to help as much as any matching, because it replaces the long email thread.
Keep the reasoning
Each posted item keeps a locked record of how it was decided: which rule or which history, who approved it, and when. Mistakes are fixed by reversing with a reason, so the history stays. Months later, “why was this coded that way?” has an answer.
What this costs us
- It won’t recognize “HYDRO ONE 8842” as a new kind of utility bill without a rule. Fuzzy and AI matching aren’t built.
- Varying amounts need a rule, because history only matches exact amounts.
- The same permission can currently propose and approve, so separating those two jobs is a process rule for now, not something the software enforces.
If you’re adding AI to something similar
Start by making a record of every decision, because that’s the data any model would need later, and it’s useful on its own. Keep a person reviewing wherever a mistake is expensive. Then add suggestions where the exact rules run out, not in place of them.