18,000 Unreconciled Transactions, Three Years of Backlog. Here's How AI Cleared It in 3 days
Published June 2026 · Boris Korol, AI Automation Studio
A company came to us with 18,000 transactions that had not been reconciled since 2022. Three years of backlog, spread across several bank accounts. Transactions recorded in their banking app had never been matched to their internal accounting system. We built a four-layer AI matching pipeline. 3 days from receiving the first file to final output, only 100 transactions remained for a human accountant to review.
This article explains exactly how we approached it, where standard matching broke down, and what it took to close the gap.
The Scale of the Problem
The company had two systems that had drifted apart over three years.
Their banking app held the authoritative record of every payment made and received. Their internal accounting system held a parallel set of manually entered records, typed in by staff after each transaction. The intention was for the two to match. In practice, by the time we were brought in, 18,000 entries across multiple bank accounts had no confirmed match between the two systems.
This is not a rare situation. Manual double-entry creates drift. Staff change. Processes slip. The problem compounds silently until someone needs to produce audited accounts and the reconciliation has to happen all at once.
Three years of backlog at 18,000 transactions is a large but not extreme example of what happens when reconciliation is deferred. The ICAEW requires member firms to maintain accurate and complete accounting records — a deferred reconciliation backlog of this scale puts that obligation at risk.
Why Simple Matching Was Not Enough
The obvious first step is exact matching: find every transaction where the date and amount in the banking system match the date and amount in the internal system. This works well for straightforward cases and eliminates the bulk of the volume.
After running exact matching across all 18,000 transactions, we were left with approximately 3,000 unmatched records.
Three thousand unmatched transactions from 18,000 is a significant problem. Those 3,000 represent the cases where the data does not align cleanly, and each one could indicate an error, a duplicate, a misposting, or a legitimate discrepancy.
Standard reconciliation tooling stops here and hands everything to a human reviewer. We did not.
The Four-Layer Approach
| Layer | Method | Input | Output |
|---|---|---|---|
| 1 | Exact match | Date + amount | Confirmed matches; ~3,000 unresolved |
| 2 | Grouped match | Amount sets across systems | Many-to-one and one-to-many resolved |
| 3 | Recipient analysis | Sender/recipient name fields | Mismatched-name transactions flagged |
| 4 | AI web search | ~800 flagged transactions | ~100 genuine discrepancies identified |
Layer 1: Exact one-to-one matching
Date and amount match exactly across both systems. This cleared the majority of transactions and confirmed which records were straightforwardly aligned. Output: a set of confirmed matches and a set of unresolved records.
Layer 2: Approximate and grouped matching
Not every transaction maps to a single counterpart. Salary payments, for example, may appear as one transaction in the banking system and as several component entries in the internal system. We built a matching step that compared each record in one system against sets of records in the other, looking for groupings where the combined amounts aligned within a defined threshold.
This layer reduced the unresolved set further by identifying many-to-one and one-to-many relationships that exact matching cannot detect.
Layer 3: Recipient and sender analysis
With the remaining unmatched transactions, we ran a comparison of the named sender and recipient fields. The financial team had already flagged that some transactions had been sent to the wrong entity or recorded incorrectly, and that the banking record was the source of truth.
We flagged every case where the sender or recipient name in one system did not match the corresponding name in the other.
Layer 4: AI web search for company identity
This is where the problem became genuinely interesting.
Approximately 800 transactions remained where the names in the two systems appeared to differ but might still represent the same counterparty. The question was whether a name discrepancy was a data error or a legitimate difference in how the same company was recorded.
We built an AI agent that ran a web search for each of the 800 transactions. The agent searched for both names and attempted to determine whether they referred to the same legal entity.
In one example: the banking system recorded a payment to East Eagle Ltd. The internal system recorded the same transaction as South East London Ltd. To a human reviewer scanning rows in a spreadsheet, these look like two different companies. They are the same nightclub. East Eagle is the trading name; South East London Ltd is the registered legal entity — a distinction verifiable via the Companies House register.
The AI found approximately 100 more cases of this pattern. A trading name in one system, a legal entity name in the other. Same company, different label, recorded inconsistently across three years.
Results
Starting position: 18,000 transactions with no confirmed reconciliation status.
After running all four layers:
Confirmed matches covered the vast majority of the 18,000 transactions
100 transactions remained unresolved and required human accountant review
Total time from file receipt to output: 3 days
The agent now understands the matching logic and the company-name disambiguation approach. A follow-on batch of similar volume would take a few hours rather than 57
The reduction from 18,000 unknown-status transactions to 100 items for human review meant the accountants could do their work in a fraction of the time originally projected. They received a prioritised list rather than a raw data problem.
What This Pattern Looks Like in Other Engagements
Transaction reconciliation backlogs are not unique to the type of company described above. The same pattern appears in any organisation running parallel record-keeping across systems that were never fully integrated.
The specific technical approach will differ depending on the systems involved, the volume of transactions, and the nature of the discrepancies. But the four-layer structure, moving from exact matching through grouped matching, recipient analysis, and identity disambiguation, transfers across most reconciliation problems we encounter.
AI Automation Studio builds these pipelines for accountancy practices, audit firms, and finance teams dealing with reconciliation backlogs or ongoing reconciliation inefficiencies. Each engagement starts with a 30-minute scoping call to understand the data sources, systems, and volume involved before any build begins.
Frequently Asked Questions
How did you access the data from both systems?
The client provided exports from both systems in structured formats. We did not require direct system access or integration during the reconciliation phase. The AI agent worked from the exported files. Data is processed and stored within the client's jurisdiction — UK or EU — in compliance with UK GDPR and data residency requirements. For ongoing automation rather than a one-off project, we build live connections between the systems.
What happens to the 100 transactions that needed human review?
Those records were delivered to the client's accountants with the full context for each: what matched, what did not, and the closest candidate match found. The accountants made the final determination on each one. The AI did not make decisions about transactions it could not confidently match.
Can this work if one of the systems is not a standard accounting package?
Yes. The approach works on any structured data export. We have run similar pipelines against bespoke internal systems, legacy databases, and ERP exports. The matching logic is built around the data structure of the specific files provided, not around a fixed integration with a named software platform.
Book a 20-Minute Automation Snapshot
If your organisation has a reconciliation backlog, or if your team is spending significant time on transaction matching that should be automated, a short conversation is usually enough to establish what is possible.
Book a 20-minute Automation Snapshot with AI Automation Studio: http://ai-automation.studio/call
No pitch. No obligation. We look at the data sources and the volume, and give you a realistic picture of what an automated approach would involve.
Boris Korol is the founder of AI Automation Studio, a London-based automation consultancy working with accountancy practices, audit firms, and finance teams on transaction reconciliation, workflow automation, and AI agent development. Connect on LinkedIn.
