AI in Finance
LLMs for Financial Reconciliation: A Practical Guide
29 December 2025
Reconciliation is the unglamorous heart of finance operations. Every finance professional knows this. Every finance function does it. Most do far too much of it manually, and a significant proportion of that manual effort is the kind of low-judgment, high-volume matching work that should be automated.
Large language models are increasingly being applied to this problem. Not because LLMs are the right tool for every reconciliation task, but because a meaningful subset of reconciliation work is fundamentally a language problem: matching descriptions that mean the same thing but are written differently, explaining why items do not align, categorising exceptions based on textual characteristics. These are problems LLMs are well-suited to.
This post explains precisely what LLMs can and cannot do in reconciliation, what you need in place before deploying them, and what realistic automation rates look like with and without the right foundations.
Why reconciliation is still a manual problem in most organisations
The traditional automation approaches work well for structured matching: same amount, same reference, same date. The problem is that real-world financial data is inconsistent. Invoice references get truncated or reformatted in transit. Payment descriptions are entered by humans who use shorthand, abbreviations, or inconsistent formats. The same transaction appears differently in two systems because it was captured at different points in the process with different amounts of information available.
The items that fall out of automated matching are the ones where the evidence is there but not in a directly comparable form. A bank statement entry that says “ACME CONS SVCS JAN” needs to be matched to an invoice that says “Acme Consulting Services Ltd. January Retainer.” A human recognises this immediately. Traditional rule-based automation does not.
This is the specific gap that LLMs address. They are good at recognising that two text descriptions refer to the same thing, even when the textual match is imperfect.
What LLMs can do in reconciliation
Matching unstructured descriptions across ledger entries. This is the primary use case and the one with the clearest evidence base. LLMs trained on financial text can match invoice descriptions, payment references, and ledger entries with a high degree of accuracy even when the descriptions are not identical. The underlying task is a natural language similarity problem: exactly what large language models are built for.
The practical impact: organisations running LLM-assisted matching on previously unmatched items are typically clearing an additional 20 to 40% of items that would otherwise require manual investigation. The exact figure depends heavily on the consistency of the underlying data.
Explaining why items do not match. This is the time-consuming part of manual reconciliation and one of the least-discussed benefits of LLM application. When an item does not match, a finance team member has to investigate: check the original transaction, look at related entries, review emails or notes for context, and write an explanation for the exception log.
LLMs can draft that explanation. Given the relevant transaction data and access to a knowledge base of historical exceptions and resolutions, an LLM produces a draft explanation that a human reviews and approves rather than writes from scratch. In a function that handles hundreds of reconciling items per month, this is a material time saving even if the human reviews every one.
Categorising and coding exceptions. Exception categories drive the resolution workflow and provide management information about where reconciliation problems are concentrated. Consistent categorisation requires applying the same logic to every item: exactly what LLMs do well once the categories are defined.
Where finance teams categorise manually, categorisation is inconsistent because different team members apply the rules differently, particularly for borderline cases. LLM categorisation is consistent by construction. The category definitions still need human judgment to establish. The application of those categories to individual items is a task LLMs handle reliably.
What LLMs cannot do in reconciliation
Being precise about the limitations matters, because vendors are not always careful about this distinction.
LLMs cannot catch systematic errors caused by bad process design. If your reconciliation is consistently off by a fixed amount because of a system configuration issue, or if there is a structural timing difference between two systems that has never been resolved, an LLM will consistently fail to reconcile those items. Efficiently. At scale. It will not fix the underlying problem. An LLM can tell you that items are unmatched. The diagnosis of why requires a human with process knowledge.
LLMs cannot fix data that is inconsistent at source. If the supplier master in your accounts payable system has not been maintained and the same supplier appears as “Acme Ltd”, “ACME LIMITED”, and “Acme” with three different supplier codes, an LLM matching tool will partially compensate for this. It will not resolve it. The data quality problem needs to be addressed at source. Automating around bad master data is a losing proposition. See the upcoming post on data quality for finance AI for the full treatment.
LLMs cannot replace human judgment on novel exceptions. The value proposition of LLM-assisted reconciliation is handling items that follow patterns the model has seen before. Novel exceptions do not follow those patterns. A large payment from an unfamiliar counterparty, a transaction that appears to be a duplicate but involves a legitimate timing issue, an intercompany entry reflecting a commercial arrangement that has not been documented in the system: these still need human judgment. The LLM will flag them as exceptions. It cannot resolve them.
What you need in place before you start
The gap between the 40% automation rates many organisations achieve and the 80 to 90% rates that are achievable comes down almost entirely to three prerequisites.
Consistent data formats. The most common reason LLM matching fails on items a human would quickly recognise is inconsistent formatting: dates stored in different formats across systems, amounts with and without VAT depending on the system, reference numbers that are truncated or padded differently. These are not AI problems. They are data format problems that need to be resolved either at source or through a normalisation layer before the AI sees the data.
Clean source data. This goes beyond formatting. The underlying records need to be complete and accurate. Missing fields, placeholder values, test entries that were never removed: all of these create noise that degrades matching performance. A data quality assessment before deployment is not optional. It is the single most valuable thing you can do to ensure the deployment achieves its potential.
Defined exception categories and documented reconciliation process. LLMs categorise exceptions well once the categories are defined. Defining the categories is a human task requiring an understanding of your specific reconciliation landscape. What types of exceptions arise? What is the resolution workflow for each? What does “resolved” mean for each category? This documentation work serves a dual purpose: it forces process clarity that is valuable regardless of AI, and it provides the configuration foundation the AI tool needs to work properly.
The three-tier automation framework is relevant here. LLM-assisted reconciliation sits in the middle tier: it handles the cases too complex for simple rule matching but not requiring the full judgment of an experienced finance professional. Getting the tier boundaries right requires exactly the kind of exception category definition described above.
Realistic automation rates
Reconciliation automation that does not address process design first rarely achieves more than 40% automation rates on high-volume matching. The remaining 60% is the messy middle: items that need more than a simple match but less than a full investigation. This is the segment that LLMs address well, provided the preconditions are in place.
When organisations address process design and data quality first, and then apply LLM-assisted matching to the residual items, 80 to 90% automation rates on high-volume reconciliations are achievable. I have seen this in practice. It requires the investment in foundations that most organisations are reluctant to make before seeing AI results, which is exactly backwards. The foundation work is what produces the results.
The economics are clear. A finance function running three people on manual bank reconciliation and intercompany matching for 20 days per month has a significant cost base in that process. An 80% automation rate does not mean two and a half people are freed up immediately. It means the function can absorb significant volume growth without adding headcount, can redeploy the team toward higher-value work, and has a more reliable and auditable reconciliation process. Those are real outcomes. They are not achievable at the 40% rate. They are at 80%.
The role of reconciliation in the AI transformation case
Reconciliation is one of the clearest proof points for AI in finance. The task is well-defined, the inputs and outputs are measurable, the current manual cost is quantifiable, and the automation opportunity is large.
For a finance leader building the case for AI investment, a reconciliation pilot is often the most defensible starting point. The success criteria are clear. The measurement is concrete. The risk of error is lower than in a process where the AI has write access to the ledger. The results, if the foundations are right, are compelling enough to build broader support for the wider transformation programme.
Read the full argument for why AI will not fix a broken finance function before you start, and explore the complete AI in Finance Strategy for where reconciliation fits in the broader picture.
Maebh Collins is a Fellow Chartered Accountant (FCA, ICAEW) with Big 4 training and twenty years of operational experience as a founder and senior finance leader. She writes about AI in finance transformation from the inside out.