Most finance-systems teams who ask "could we just build this ourselves with AI?" are reacting to a real signal. NetSuite renewals keep moving in one direction. Customization debt accumulates in SuiteScript. And the gap between what a modern coding agent can produce and what a 2015-era ERP exposes to its users is now wide enough that the question is no longer absurd. It is a plan question.
What follows is the actual construction plan: the five components a serious team would assemble, where each one should come from, and the two or three places where the build path quietly breaks. The goal is not to argue for or against building. It is to make the trade honest.
The Five Components of a Custom AI ERP
A credible custom ERP with AI is not one system. It is five, loosely coupled, each with its own failure mode. In order of how often teams underestimate them:
- Deterministic ledger. Double-entry, period-aware, immutable journal. The AI never writes to it directly.
- Agent layer. Role-scoped workflows (AP, AR, Controller) that extract, code, check, and propose postings.
- Policy engine. Approval thresholds, segregation of duties, SOX-aligned gates expressed as code, not prompts.
- Integration bus. Bank feeds, payroll, billing, CRM, tax, expense. Idempotent, replayable, versioned.
- Evaluation harness. Golden datasets, offline scoring, online drift detection, CI gates that block a bad agent before it reaches the ledger.
Removing any one of these does not produce a smaller ERP. It produces a system that cannot be audited. The order matters: the ledger has to exist and be trusted before the agent is allowed near it. For the reasoning behind that constraint, the piece on what an agent cannot do in a ledger covers the specific primitives the agent must be denied.
What Should Never Be Custom-Built
Three pieces fail badly when written from scratch, and every honest build plan outsources them.
The first is the ledger core. A double-entry engine with period locks, multi-currency revaluation, intercompany elimination and audit trail is a decade of corner cases. Teams that start here always underestimate the eliminations. Use an open-source ledger kernel or a commercial accounting engine as a dependency; wrap it, do not rebuild it.
The second is tax and compliance content. Sales tax rates, VAT rules, e-invoicing mandates and withholding tables change weekly in some jurisdictions. License this from Avalara, Vertex, Sovos or equivalent. The build team's job is the integration, not the content.
The third is bank connectivity. Plaid, Finicity and the direct bank-feed aggregators exist because the long tail of regional banks is not a software problem a finance team can solve.
Everything else — the agent layer, the policy engine, the UI, the reporting surface — is in play. That is where a custom build earns or loses its justification.
The Agent Layer Is Where the Build Actually Happens
The agent layer is the only component where custom construction is clearly more interesting than the licensed alternative in 2026. Coding assistance has moved far enough that building role-scoped agents is tractable for a small team. AI generates over 30% of new code at both Google and Microsoft, and adoption among developers worldwide now sits near 84%. The leaderboard numbers are less relevant than the floor: Claude Opus 5 reached 97% on SWE-bench Verified as of September. That means a two-engineer team can realistically ship an AP agent that reads an invoice, normalizes the vendor, picks a GL account from a learned chart, checks the PO, and proposes a journal entry.
What the leaderboard does not show is the cost of making that agent production-safe. An Opsera benchmark of 250,000+ developers found AI reduces time-to-PR by up to 58%, but AI-generated pull requests wait 4.6x longer in review and introduce 15–18% more security vulnerabilities. In ledger code, those vulnerabilities are not CVEs. They are posting errors that only surface at close.
The architectural pattern that actually works is the same one described in the walkthrough of orchestration, RAG and ledger access: the agent reads, retrieves, reasons, and proposes. A deterministic service writes. The agent's output is a structured proposal, not a SQL statement.
The Policy Engine Is Where SOX Lives
Most teams building an agentic ERP in-house skip straight from "the agent proposed a journal" to "we posted it" without a policy engine in the middle. That is the design flaw that forces a rebuild in year two.
The policy engine is a separate service that evaluates every proposed posting against a declarative rule set: who can approve what, at what threshold, with what evidence, under what segregation-of-duties constraint. Open Policy Agent is the obvious starting point. The rules themselves are the governance deliverable your auditor cares about. The piece on approval thresholds for an AP agent walks through how those thresholds should be structured so a Big Four auditor can test them.
A policy engine built this way gives you two things licensed ERPs rarely do cleanly: a single source of truth for approval rules across every workflow, and the ability to replay any posting against the policy that was in force on the day it happened. That matters when the auditor's sample lands on a transaction from February.
The Evaluation Harness Is the Build You Will Skip and Regret
Of the five components, the evaluation harness is the one teams cut when the timeline slips. It is also the one that determines whether the system is trustable in month 18.
A real harness has four parts: a golden dataset of labeled transactions (invoices, bank lines, expense reports with the correct coding), an offline runner that scores agent proposals against the golden set, an online sampler that scores live production traffic against an LLM-judge or deterministic check, and CI gates that block a model or prompt change from shipping if accuracy drops. Harness, Arize, Braintrust and Promptfoo all sell versions of this; the build decision is whether to license the harness or write it against open-source scorers like Ragas and DeepEval.
The reason this matters inside an ERP: an agent that codes 94% of invoices correctly sounds excellent until you realize the 6% errors cluster in one GL account and distort the P&L of one entity. Without a harness that slices accuracy by vendor, entity, account and amount band, you will not see the cluster until the controller does, during close.
Where the Build Path Breaks
Three failure modes recur across teams that attempt this build. All three are predictable from the research on ERP projects generally.
The first is budget drift. 55% of ERP implementations exceed their original budget, and 65% of overspending comes from modifications made to improve usability. A custom build is a 100% modification project by definition; the overrun curve is steeper, not flatter.
The second is maintenance tail. Annual maintenance on custom software runs 15–20% of initial build cost, with enterprise systems ranging from $200,000 to over $1 million. That is a line item that does not appear in the build-vs-buy spreadsheet most teams produce, and it compounds for as long as the system is live.
The third is the evaluation gap. A build team can ship a working AP agent in a quarter. They cannot ship an auditable one that quickly, and the gap between the two is where most pilots die. The reference piece on running a two-week pilot that actually proves something is as relevant to a build as to a vendor evaluation, because the question is the same: can you measure what the agent is doing well enough to trust it.
Build, Buy, or Buy an AI-Native Platform
The honest framing for a mid-market finance team in 2026 is not build vs. buy. It is three-way. Buy NetSuite and absorb the roughly 30% license increase in 2025 plus the SuiteScript governance limits that constrain customization. Build in-house and accept the maintenance tail and the evaluation gap. Or buy an AI-native platform where the ledger, agents, policy engine and harness were designed together.
The build path makes sense when a team has at least four engineers who can commit for 18 months, a controller willing to spend 30% of their time on design, and a tolerance for shipping the first version without the harness. Most teams who think they fit that profile do not, which is why the erp.io platform exists in the shape it does: the five components, pre-integrated, with daily reconciliation proof included. For teams weighing the full comparison before committing, the keep-versus-replace analysis is the right next read, and a free assessment will put a number on which path is cheaper for a specific entity structure.
The question was never whether AI can run finance workflows. It is whether the ledger underneath them is deterministic enough to prove they ran correctly. That is the component that decides which path works.