General-purpose LLMs handle the happy path in reconciliation well. The failures appear in exception handling, mid-process data changes, and audit trail requirements. Accounting agents require stateful architecture, deterministic execution, and domain-specific infrastructure that cannot be replicated by a prompt.
When a finance team says they are already using an LLM for reconciliation, or that their engineering team is planning to build something similar, the instinct makes sense. General-purpose AI tools are powerful, the interfaces are familiar, and the first results often look promising. The problems emerge later, and they emerge in specific, predictable places.
The assumption behind that decision is usually the same: reconciliation is a logic problem, and logic is something AI handles well. That is true up to a point. The issue is that accounting workflows do not stop at the easy cases. They involve exception handling, stateful data that changes mid-process, audit trail requirements, and entity-specific rules that vary across ERPs and chart-of-accounts structures. None of that is solved by a prompt.
What makes this harder to see is that general-purpose tools perform well on the happy path. A clean two-way match, a straightforward journal entry, a simple balance check: these work. The failure modes appear at the edges, and in accounting, the edges are where most of the work actually lives.
Understanding where general-purpose tools stop and purpose-built accounting agents begin is not an academic distinction. For teams managing multi-entity close, reconciliation at scale, or any workflow that touches audited financials, it is a decision with real consequences.
The easy case is never the problem
Every reconciliation system handles the happy path well. Two records match. A journal entry posts. The balance clears. Almost any system, including a well-prompted LLM, can execute that reliably.
The question is what happens next.
When discrepancies appear
Discrepancies are not the exception in reconciliation. Timing differences, partial payments, currency rounding, intercompany eliminations that do not net to zero: these are daily realities for any multi-entity accounting team.
A system that cannot handle discrepancies does not reduce work. It creates a new category of risk: outputs that appear correct but are not, and that no one catches until close review or, in worse cases, an audit.
General-purpose AI tools produce plausible responses. In accounting, plausible and correct are not the same thing. A reconciliation that is directionally right but off by a rounding error at the entity level can produce materially incorrect consolidated financials. The error is not dramatic. It is quiet, and it compounds.
When data changes mid-match
Reconciliation is not a single-pass operation. Source data changes while matching is in progress. A transaction posts late. A payment gets reversed. An ERP feed delivers a duplicate.
A system that processes a snapshot and stops has no mechanism for handling those updates. It produces a result that was accurate when it ran and is wrong by the time anyone reads it.
Handling this correctly requires stateful architecture: a system that tracks what has been matched, what is still open, and what has changed since the last sync. That is an infrastructure problem, not a prompting problem.
How exception knowledge compounds over time
The most underestimated requirement is memory. Not short-term context, but persistent, structured knowledge about how exceptions have been handled before.
When a specific intercompany transaction pattern generates a discrepancy every month, a well-run accounting process builds a rule around it. The next time it appears, it routes correctly without manual review. This is how accounting teams get faster over time.
A general-purpose LLM has no memory between sessions. Every reconciliation cycle starts from zero. The same exceptions that required manual handling last month require it again this month. The efficiency that should compound over time never materializes.
What developers underestimate when they start building
Developers who decide to build their own accounting agent typically begin with the data layer. They pull transactions from an ERP, store them in a database, and write matching logic on top. This approach underestimates the problem at almost every step.
The GL is not just a database
A general ledger is not a database. It is a structured system of record with double-entry constraints, entity hierarchies, period locking, intercompany elimination logic, and audit trail requirements that govern every transaction that flows through it.
Building a GL-adjacent system that behaves like a real GL, one that produces auditable financials, handles period close correctly, and maintains integrity across entities and currencies, requires domain-specific knowledge that is hard to acquire and harder to encode correctly.
Getting it wrong does not produce a bad result that is easy to spot. It produces financial statements that are materially incorrect in ways that may not surface until an audit or a board review.
Normalization across ERPs
Many multi-entity companies run more than one ERP. Acquisitions, regional entities, and legacy systems mean the chart of accounts in one entity looks nothing like the chart of accounts in another. Account codes differ. Currency handling differs. Transaction structures differ.
Nominal mirrors the entire general ledger and maps accounts from different ERPs into a unified, normalized chart of accounts, including currency translation. Building that layer from scratch, covering ERP connectors, the normalization engine, and the unified data model, is the kind of scope that looks manageable until the edge cases arrive. Most engineering teams that attempt it do not fully appreciate what they have signed up for until the project is several months in.
Why deterministic agents matter in accounting
Most AI agents in the market today are LLM-powered: they receive a task, reason about it, and produce an output based on probabilistic inference. For many use cases, this works well. For accounting, it is not sufficient on its own.
Related post: AI Agents in Finance and Accounting: Automating Close, Reconciliation, and Reporting with Intelligence
The difference between reasoning and executing
There is a meaningful architectural distinction between an agent that reasons about what a reconciliation should look like and an agent that executes a reconciliation according to defined rules and surfaces exceptions for human review.
Nominal's agents are deterministic. They follow rules and produce consistent outputs across runs. The same inputs produce the same outputs every time, and every action is traceable to a specific logic or decision point.
An LLM-based agent applies probabilistic reasoning to every decision it makes. Most of the time, it will be correct. Occasionally, it will not. In accounting, the failures are rarely obvious, and the cost of a subtle error in a reconciliation or a consolidation can be significant.
What audit-readiness actually demands
Audit-readiness is not a feature. It is a baseline requirement for any system that touches financial statements.
Actions must be documented. Outputs must be traceable. Exceptions must be explainable. That trail exists by default, with every reconciliation action and exception logged against the rule that triggered it and the human approval that followed.
A ChatGPT output is not a workpaper. It cannot be audited, traced, or defended in a review. Nominal's outputs can.
Why reconciliation is not a prompt problem
When accounting teams experiment with Claude or Cursor for reconciliation, the first results often look promising. The tool handles the easy cases, produces readable outputs, and responds to follow-up questions. The problems emerge at the edges.
What general-purpose tools were not built to do
General-purpose AI tools were built to assist with a broad range of tasks. They were not built to maintain persistent state across accounting periods, connect to ERP APIs and normalize schemas across entities, apply entity-specific matching rules and accounting policies, or produce audit-ready documentation for external review.
These are not gaps that can be closed with a better prompt or a more detailed system message. They are architectural requirements that need to be built, maintained, and kept in sync with ERP changes, entity structure changes, and accounting policy changes over time.
You might also like: What Are Matching Agents? The Foundation of Modern Reconciliation
What a purpose-built system handles instead
Nominal connects directly to existing ERPs. It maintains a continuous, normalized view of every transaction across every entity. It applies deterministic matching rules configured for each company's specific accounting policies, and it keeps a complete audit trail of every action, every exception, and every human approval.
New entities are absorbed without reconfiguration. ERP schema changes are handled at the normalization layer. Exception patterns that repeat feed back into the system's matching logic. It becomes more capable over time because it was designed to learn from the work it does.
For a deeper dive, check out: Agentic Performance Management: The Next Step After Finance Automation
What it actually takes to build what Nominal built
Describing the scope plainly is the most useful thing here. Building what Nominal has built means connecting to ERPs across multiple systems, constructing a unified and normalized general ledger, designing a deterministic agent architecture, maintaining stateful reconciliation with memory across periods, building exception handling with learning mechanisms that compound over time, and shipping all of it with SOC 1 and SOC 2 compliant infrastructure from day one.
Engineering teams that have attempted parts of this consistently find that the complexity compounds as the layers interact. A normalization engine that works across two ERPs breaks on the third. Matching logic that handles clean transactions struggles with late postings and reversals. Compliance requirements that seemed straightforward at the start end up reshaping the architecture underneath.
Nominal has spent years building and refining this stack across real accounting teams at multi-entity companies. That depth does not get replicated in a sprint, and it does not emerge from prompting a general-purpose model, however capable that model might be.
What this means for teams already using an LLM solution
General-purpose AI tools are useful for many tasks in a finance function. Drafting commentary, summarizing reports, answering ad hoc questions about data: these are genuine use cases and they work reasonably well.
Reconciliation, consolidation, and close management are different. They require state, traceability, accounting-domain understanding, and infrastructure that connects directly to the systems of record. A well-prompted LLM does not have those things. Building them is the work Nominal has spent years doing.
For teams evaluating whether to build or buy, the most useful exercise is mapping the actual scope: ERP connectivity, GL normalization, stateful reconciliation, exception handling, audit trail, compliance infrastructure. Most engineering teams, when they do that exercise honestly, find that the timeline stretches well beyond what they expected. Building accounting infrastructure is a multi-year commitment, and every month spent on it is a month not spent on the work that moves the business forward.
Agentic AI in accounting works. What determines whether it works reliably is the layer underneath: the domain knowledge encoded into the system, the infrastructure it runs on, and the architectural decisions made long before the first reconciliation runs.
General-purpose tools are broadly useful. Accounting-grade reliability requires something more specific. The gap shows up in the exceptions, in the audit trail, in the data that changes after a match runs, in the entity added last quarter that needs to reconcile across three different ERPs. These are not edge cases. They are the job.
That gap takes time to close, and infrastructure takes time to build correctly. If your team is ready to see what purpose-built accounting agents look like in practice, book a demo with Nominal.
About the writer
