Reconciliation is the clearest example of work that looks like it needs an accountant and mostly does not. Ninety per cent of the lines are obvious. The remaining ten are why the job takes three days.
AI reconciliation tools go after that split. The claim is that the obvious matches clear themselves and your attention goes to the exceptions. Worth understanding what that means mechanically, because the gap between the good tools and the marketing is wide.
Why rules run out
Conventional reconciliation matches on exact values: same amount, same date, same reference. It works, right up until the real world interferes.
A customer pays three invoices in one transfer. A supplier is paid short by the value of a credit note. Payment lands two days after the invoice date, and the bank narration says PYMT 4471 DXTRS GRP where the ledger says Dexterous Group Pty Ltd. Someone pays the wrong entity in a group and it gets corrected next month.
None of those match on exact values. All of them are obvious to a person who spends four seconds looking. That four-second gap, repeated across a few hundred lines, is the reconciliation backlog.
Bank rules in Xero and similar tools patch the common cases. The catch is that you have to anticipate each pattern and write it down, then maintain it as suppliers, references and banking platforms change. Rules are a decent floor. They are a poor ceiling.
What AI matching does differently
Similarity instead of equality. The model considers amount, date proximity, narration, supplier history and the shape of past transactions together, then scores how confident it is that two records are the same event.
That gets you several things rules cannot do:
- One-to-many and many-to-one matching. A batched payment split across invoices, or several receipts against one bill.
- Fuzzy reference matching. Abbreviated, truncated and mangled bank narration mapped to the right supplier.
- Tolerance for timing and small differences. Payments that land late, or short by a credit note or a bank fee.
- Learning from correction. Reject a proposed match and the same pattern is handled correctly next month, without anyone writing a rule.
The confidence score is the part that makes it usable. Above your threshold, matches clear straight through. Below it, they are proposed with the reasoning visible, so you are reviewing a conclusion rather than starting an investigation.
Exceptions are the actual product
Here is the test that separates tools. Feed it a month of messy data and look at what it hands back.
A weak tool returns a list of unmatched lines. That list is the same list you would have got from a spreadsheet, and you still have to work out why each item is on it.
A good tool tells you what it thinks happened: this looks like a duplicate receipt, this payment is short by exactly the value of credit note CN-1042, this transaction has no ledger entry at all, this one matches an invoice raised against a different entity in the group.
The matching is table stakes. The diagnosis is where the hours come back.
Beyond the bank feed
Bank reconciliation gets the attention, but the same engine should run on everything else that needs matching, and those are often the jobs that actually delay a close:
- Supplier statements against the AP ledger, to catch invoices you never received.
- Remittance advice and cash receipts against open invoices.
- Purchase orders against invoices and goods receipts.
- Clearing, suspense and intercompany accounts.
- Card and expense transactions against receipts.
Several of these depend on documents that arrive by email. If your reconciliation tool is disconnected from the accounts inbox, someone is still manually hunting for the supplier statement before the reconciliation can start. Tools that read the inbox already have it.
What to check before you trust one
Does it show its working? Every automated match should carry a confidence score and the evidence behind it. If you cannot see why it matched, you cannot audit it.
Who sets the threshold? You should, per account if needed. A vendor-set threshold you cannot see is a vendor deciding your materiality.
What is the false-positive rate on your data? A tool that clears 95% of lines but gets 2% of them wrong has created a worse job than the one it replaced, because now you are hunting for errors that look settled. Test on your own history, and check the matches it cleared, not just the count.
Is the trail exportable? Auditors will ask what cleared automatically and on what basis. That needs to come out as a file, not a screenshot.
Does it touch the ledger without approval? For anything with financial consequence, the answer should be no by default.
Where dexIQ sits
dexIQ matches bank lines to ledger entries, scores its confidence, and clears only what is beyond doubt within your limits. Everything else is proposed with the likely cause attached. The same engine runs on supplier statements, remittances, purchase orders, clearing accounts and expenses, and because dexIQ is already reading your accounts inbox, the documents those reconciliations depend on are usually in hand before anyone goes looking.
Every automated match is logged with its confidence and evidence. Every manual decision is logged with the person who made it. The whole trail exports for audit.
See how reconciliation works in dexIQ or run it against your own history.