The debate over whether AI agents belong inside an ERP has moved past philosophy. The useful question now is narrower: which specific finance workflows degrade when an agent runs them unsupervised, by how much, and what deterministic check has to sit downstream before the posting hits the ledger. Vendor demos tend to be built around the workflows where accuracy is already high. The failure catalogue is where the controller actually lives.
What follows is the empirical map. Six workflows where accuracy is known to drop, the reason it drops, and the control that has to catch the residual error before it reaches a signed-off trial balance. It is a diagnostic checklist, not an argument against automation.
Why the Accuracy Average Hides the Risk
Aggregate accuracy numbers are reassuring and misleading. On the FinMaster benchmark, frontier models hit roughly 96% on fundamental financial literacy tasks but collapse to around 40% on complex multi-source reasoning, where errors propagate across steps. On the FrontierFinance long-horizon benchmark, human experts averaged 77.2% against 70.9% for GPT-5.4 and 61.8% for Opus 4.6. The spread is not uniform. It concentrates in workflows that require stitching data from systems the model cannot see, applying firm-specific policy, or resolving ambiguity a human would escalate.
Market-level signals point the same way. Nasuni's 2026 enterprise survey found that 57% of AI projects are not delivering their stated objectives and only 18% of organisations have deployed agents at real scale. Gartner's outlook is similarly cautious, projecting that more than 70% of recent ERP initiatives will not fully meet their original business case by 2027, with up to 25% failing catastrophically. The question for a finance leader is which specific tasks sit inside that failure band.
Novel Vendor Onboarding Is a Classification Problem the Agent Will Guess
A first-time vendor arrives with a W-9, an invoice, and no history. The agent has to choose a GL account, a tax treatment, a 1099 flag, a cost centre, and often a project code. On a recurring vendor these fields come from precedent. On a novel vendor the model is pattern-matching against the invoice text and whatever it can retrieve from a general ledger of similar companies. That is exactly the "multi-source integration" band where FinMaster accuracy fell to 40%.
The failure mode is confident miscoding: subscription software posted to professional services, a capitalisable implementation fee expensed, a foreign contractor missed by 1099 logic. The downstream check is a two-stage gate. First, every novel vendor posts to a holding account until a human approves the mapping. Second, the mapping becomes a rule the agent must cite on the next invoice, not re-derive. Thresholds for the human gate are the lever worth tuning, and the specifics of that calibration deserve their own treatment in AP agent approval thresholds.
Intercompany Eliminations Break When the Two Sides Disagree
Intercompany is where ledger integrity meets taxonomy. The matching problem looks simple in principle: entity A's IC receivable should equal entity B's IC payable at month end. In practice the two sides book on different days, in different currencies, against different account strings, with transfer-pricing adjustments that only one side has applied. Agents framed as "learning matchers" can close most of the volume, but the residual breaks are where consolidation goes wrong.
The structural weakness is that LLM-driven matching reasons in natural language about why two balances differ. That is useful for triage and almost useless as an audit artifact. A note from an analysis of intercompany tools puts the dividing line cleanly: learning-based matching exposes reasoning differently from a deterministic rule that can be cited in the audit entry. The control is a deterministic elimination layer the agent cannot bypass: every proposed match carries a rule ID, every unmatched delta is aged and reported, and the consolidation close waits on both. The design question is covered in more depth in multi-entity close design.
Cutoff Accruals Require Judgement the Model Does Not Have
Period-end accruals are a cutoff problem dressed up as a data problem. The agent can read the PO, the receipt, and the invoice date, but the question of whether services were performed before or after midnight on the last day of the period is often answered by a project manager's recollection, a signed delivery note that lives in email, or a client acceptance that will not arrive until the second week of the next period. Nothing in the invoice text resolves it.
Agents left to accrue autonomously tend to over-accrue predictable monthly services and under-accrue lumpy professional-services engagements, because the training signal rewards the common pattern. The deterministic check is a three-way: an accrual proposal is only auto-posted when PO, receipt, and invoice all agree inside a tolerance. Everything else routes to a prepared-by-client schedule that a human owns. Close speed suffers more from reconciliation gaps than from manual journal time, a point worked through in closing faster is a reconciliation problem.
FX Revaluation at Thin-Traded Rates Produces Confident Nonsense
Standard-currency revaluation is a solved problem. The failure band is the long tail: a receivable in a frontier currency, an intercompany loan in a currency with weekly rather than daily published rates, an exposure in a jurisdiction with parallel official and market rates. The agent will fetch a rate. The question is which rate, from which source, as of which cut, and whether it is the right rate for this transaction type under the firm's policy.
The failure mode is a plausible number with no provenance. The control is to deny the agent any rate it did not pull from a named, versioned source that the controller approved, and to require it to log the source, the retrieval timestamp, and the policy rule for the account being revalued. Rates below a liquidity threshold trigger human sign-off, not an auto-post. The PCAOB's 2025 inspection priorities and the EU AI Act both push in this direction, with the Act bringing full obligations for high-risk financial AI by August 2026, including traceability logs and human oversight.
Non-Standard Revenue Contracts Are a Policy Problem, Not a Reading Problem
ASC 606 at scale is the sharpest test of agent judgement in the ledger. For standard SaaS contracts, extraction of start date, term, and MRR is near-solved. The failure band is non-standard: a multi-element arrangement with uneven delivery, a usage-based component with a floor, a reseller contract that changes the principal-versus-agent determination, a contract modification that may or may not create a new performance obligation. These are policy calls, and policy varies by firm.
Agents that read the contract and propose the schedule tend to anchor on the most common pattern in their training data, not on the firm's revenue recognition memo. The deterministic check is a mandatory routing rule: any contract that touches a non-standard clause set, or that modifies an existing one, posts a draft schedule to a revenue accountant's queue before any deferred revenue is booked. The right place to debate what the agent is permitted to touch unsupervised is before signing, as laid out in AI ERP contract terms.
OCR on Handwritten Remittance Advices Falls Off a Cliff
Cash application depends on remittance detail. Printed remittance text extracts cleanly, with field-level accuracy in the 97 to 99.5% band for digital PDFs. Handwritten remits are a different document class entirely: the same benchmark puts handwritten field accuracy at 62 to 85%. Independent reviews report similar collapses on messy inputs, with frontier models stopping at roughly 85% of fields read correctly on real handwritten forms.
The arithmetic matters. If a remittance total is eight digits and the character error rate is 10%, there is a 57% chance at least one digit is wrong. Confidence scoring routes the low-confidence cases to review, so the operational metric is straight-through rate, not raw accuracy. The deterministic check is a cash-application rule that refuses to clear an open invoice unless the extracted amount matches the open balance within tolerance; anything else drops to a worklist. The pattern applies more generally to any workflow where a document feeds the ledger.
Two More Risks That Sit Across All Six
Prompt injection is now an operational concern, not a theoretical one. Google's telemetry reported a 32% relative increase in malicious indirect prompt injection content between November 2025 and February 2026, with hidden instructions seeded in documents and web content designed to hijack agents. A finance agent that reads emailed invoices is in scope. The control is to treat every ingested document as untrusted input and to deny the agent any action that is not explicitly whitelisted for the role.
Data readiness is the quieter problem. A Cloudera and HBR Analytic Services survey found only 7% of organisations say their data is completely ready for AI adoption. Anthropic's 2026 agents report identified integration (46%), data quality (42%), and change management (39%) as the top obstacles to scaling agents. Both findings matter here because every failure mode above gets worse when the underlying master data is dirty. The architectural response, and the reason a deterministic ledger has to sit under the agents rather than beside them, is set out in AI in ERP and in the architecture note on orchestration and ledger access.
What the Checklist Looks Like in Practice
The pattern across the six workflows is consistent. Accuracy is high where the input is structured, the policy is standard, and the task is a single step. Accuracy drops where the input is messy, the policy is firm-specific, or the task spans systems. The deterministic check in each case is the same shape: the agent proposes, a rule evaluates, and only matched or human-approved items post to the ledger. Everything else is held in a worklist that the controller sees, not buried in a confidence score.
A finance leader evaluating an agent-based ERP should ask vendors to demonstrate each of these workflows on the firm's own data, with the deterministic check visible, before signing. If the demo cannot show the gate, the gate is not there. A structured way to run that evaluation is in the piece on a two-week pilot that proves something.