Most writing about AI in finance either argues the buy-vs-build question or lists features the shortlist should carry. The engineering problem sitting underneath both is different. A custom AI ERP is not an application with a chatbot bolted on; it is a system where probabilistic components propose changes to a book of record that has to stay deterministic, auditable and reconcilable to the cent. The architectural choices that decide whether that works get made in the first weeks of design, not during QA.
Skepticism is the right posture. In Onapsis's 2026 research, 68% of business units fear corrupted data or automated decision errors from model hallucinations, and the hesitation is well founded. What follows is the decision list a controller or CTO should resolve before any code is written for an agentic ERP: ledger boundaries, agent authority, retrieval scope, evaluation harness, and reconciliation proof.
Decide Where the Ledger Ends and the Agent Begins
The first architectural line is also the hardest to move later. In an AI-native ERP, the agent proposes; the ledger disposes. That means the general ledger, subledgers and journal infrastructure are deterministic services with their own API, their own idempotency keys and their own transaction semantics. The agent never writes directly. It drafts a journal, calls a validator, and the validator either posts or returns a reason code.
This boundary pays for itself in two places. First, it is the only way to preserve the audit trail every external auditor will ask for. In Datarails' 2026 CFO survey, 75% of CFOs cite lack of auditability as the biggest reason to distrust AI in finance work. Second, it keeps the ledger replayable: when a model is swapped or a prompt changes, nothing about the posted history changes with it.
Design implications are concrete. Ledger writes go through a narrow API with typed journal objects. Every proposed entry carries the agent identity, the model version, the prompt hash, and the source document reference. The agent runtime holds no database credentials with write scope. Posted entries are immutable; corrections are reversing journals, never updates. The site has written separately about what an agent cannot do in a ledger, and the list is longer than most buyers expect.
Author the Agent Authority Schema Before the Agents
Authority is not a feature of the model. It is a schema the system enforces, independent of what the agent asks to do. For each agent role (AP, AR, Controller, CFO), the schema should specify: which document types it can parse, which GL accounts it may touch, dollar thresholds for auto-post, counterparties it may transact with, and the human approval class required above each threshold.
Three authority tiers are usually enough:
- Draft only. The agent prepares the entry; a human reviews and posts. Appropriate for new vendors, unmatched POs, or any entry above a materiality threshold.
- Post with notice. The agent posts; a controller receives a summary and can reverse within a set window. Appropriate for well-matched three-way-matched invoices under threshold.
- Post silently. The agent posts and reconciles. Appropriate only for high-volume, low-dollar, fully deterministic flows like matched bank fees.
These tiers should be versioned configuration, not code. Approval thresholds and segregation-of-duties rules change with headcount, with new entities, and with every audit cycle. The site has a longer piece on AP agent approval thresholds under SOX that gets into the specifics.
Scope Retrieval Narrowly and Record Its Provenance
Retrieval is where most custom builds leak. The temptation is to index everything and let the model search; the result is an agent that cites a two-year-old contract when posting a current-period accrual. Retrieval scope should be explicit per task: a revenue recognition agent sees the contract, the order, the delivery confirmation and ASC 606 policy, and nothing else. A payables agent sees the PO, the GRN, the invoice, the vendor master and the applicable tax rules.
Every retrieved document carries provenance: source system, version, effective date, and a hash. When the agent cites a clause to justify a posting, the clause's identifier is written to the journal metadata. Freshness controls matter as much as scope. The MuleSoft 2025 benchmark reports organizations averaging 897 applications with only 29% integrated, which means the retrieval corpus will contain stale copies of the truth unless the architecture names a system of record for each data class and refuses to retrieve from the others.
Build the Evaluation Harness Before the First Agent
Finance AI evaluation is not a QA task performed late in the project. It is the control that lets the agent ship at all. The harness has three parts: a golden set of representative transactions with known-correct outcomes, a continuous replay against production proposals (not postings), and a drift alarm that fires when agreement with the golden set degrades.
The reason this matters is empirical. Research on tabular financial reasoning finds that frontier models still show 10 to 20 percent error rates on multi-step numerical tasks, and errors cluster in the harder reasoning categories (comparative, bivariate, multivariate) rather than direct lookup. An evaluation harness should score each reasoning class separately; a 95% top-line accuracy that hides 30% error on multivariate accruals is worse than useless.
Protiviti's 2026 survey found that 77% of finance organizations use AI but only 14% have a defined AI strategy. The gap is largely about evaluation discipline. The NIST AI Risk Management Framework is a reasonable spine to map controls against, particularly its measure and manage functions. The site's piece on must-have features for custom ERP builds treats evaluation as a primary surface, not an afterthought.
Reconciliation Proof Is the Only Output That Matters
An agent that saves time but requires humans to re-verify every entry has moved the work, not reduced it. The Datarails survey reports finance teams spending 26% of the working week checking AI outputs. That number falls only when the system produces reconciliation proof as a byproduct of posting, not as a separate downstream project.
Concretely, the architecture should emit a daily reconciliation artifact per subledger: opening balance, agent-posted entries by authority tier, human-posted entries, reversals, closing balance, and a tie-out to the bank, the AP aging, the AR aging and the inventory ledger. Any variance surfaces with the specific journal that caused it and the agent run that produced it. CIO reporting on the ERP reckoning notes that custom code and bespoke workflows create a black-box risk for agentic AI because customization fragments the single process agents need to act against. Reconciliation proof is what refuses to let that fragmentation hide.
This is also the operational link between a custom build and real migration planning. The erp.io platform is organized around that daily reconciliation artifact, and so is the migration process with reconciliation proof on the services side. The point is not the brand; it is that reconciliation has to be a first-class output of the architecture, not something generated by a weekend script.
What to Resolve Before Writing Code
The decisions above are not sequential; they interlock. Ledger boundaries determine what the authority schema can express. The authority schema determines what the evaluation harness has to measure. The harness determines whether retrieval scope is working. Reconciliation proof is the single external signal that all four are correct on any given day. A custom AI ERP that treats any of these as a late-stage detail will spend its first year rediscovering why they were listed first. A build that treats them as the design brief has a reasonable chance of producing a ledger that finance can defend to an auditor and a CFO can defend to a board.