Most ERP replacement decisions get framed as a choice between two dates: the go-live on a new platform, and the sunset of the old one. That framing is what makes them slip. The real choice a finance-systems buyer faces in 2026 is architectural, and it lives twelve months before any cutover: run agents on top of the ERP already in place, or replace the ledger underneath them.
Both paths can end up in the same destination, an AI-native close with agents doing the labour. What differs is the order of operations, what breaks in year one, and how much of the budget is spent buying optionality rather than posting entries. The answer is rarely universal. It turns on the state of the current ledger, the shape of the chart of accounts, and how much of the close is already reconciliation work rather than data-entry work.
So what actually decides it?
What the Wrap Path Actually Does
Wrapping means the legacy ERP stays the system of record. Agents read from it, prepare work, and write back approved entries through supported APIs. This is now a recognisable pattern in the market. Vendors describe agents that work alongside NetSuite, pulling GL balances and subledger data, and posting adjustment journals back once reconciliation is complete. The ledger does not move. The labour layer does.
The mechanics matter. An AP agent extracts an invoice, codes it against the vendor master and PO, checks it against approval thresholds, and stages a bill for posting. A reconciliation agent pulls bank feeds, matches them against GL entries using dates, amounts and metadata, and puts exceptions in a queue. A close agent walks the checklist, flags variances against prior period, and drafts flux commentary. The ERP stays the ledger of record. The erp.io platform runs a parallel shadow ledger that reconciles every posted entry back to the source system each morning, so a wrap does not become a second set of books nobody trusts.
The appeal is speed and reversibility. Nothing about the general ledger, chart of accounts, or intercompany structure changes on day one. If the agent layer fails a control test, the ERP still closes the way it always did.
What the Replace Path Actually Does
Replacement is a different order of operation. The chart of accounts is redesigned before the first agent runs. Intercompany eliminations, revenue recognition rules under ASC 606, and consolidation logic get rebuilt inside the new platform. Agents are then native to that ledger, not translators sitting on top of it.
The cost profile is different in kind, not just in size. A single-site Tier II ERP implementation for a mid-sized business runs between $600,000 and $2,000,000, with durations that can span eight months to more than a year. Panorama Consulting's 2026 survey of 170 organisations found that roughly 30% of ERP projects exceeded their planned budgets and about 22.3% ran past their anticipated schedule. Those are the base rates, not worst cases.
Replacement makes sense when the underlying data model is the constraint, not the user experience. If the chart of accounts cannot represent the business you actually run, no wrapper fixes that. A chart of accounts migration is where most of the value and most of the risk in a replacement actually sit.
The Conditions That Favour Wrapping First
Wrapping is cheaper, faster and lower risk in a specific set of conditions. Not all of them need to be true. Two or three usually settle the question.
- The ledger is intact. Trial balance ties, intercompany eliminations work, and auditors have not raised a material weakness on the close.
- The chart of accounts is broadly usable. It may be untidy, but it represents the business and does not require restructuring for a new reporting need.
- The pain is labour, not structure. AP coding, cash application, bank reconciliation and flux commentary consume the calendar. These are agent-shaped problems.
- The vendor is still investing in the platform. Support is live, the API surface is stable, and the roadmap is credible for the next 24 months.
- A migration window does not exist. A pending acquisition, an audit, or a systems freeze makes a cutover reckless in the near term.
When those hold, an agent layer delivers close-time reduction in months rather than years, and the ERP replacement becomes a decision the CFO can make later, from a position of better data. Augmentation bypasses the need for a full rip-and-replace, targeting surgical improvements without disturbing the stable core.
The Conditions That Force Replacement
The wrap path breaks down when the ledger itself is the problem. Signs the ERP has to move:
- The chart of accounts cannot support required reporting without a rebuild. Segment structures are exhausted, or dimensions the business needs (entity, product line, cost centre) live in custom fields rather than the natural chart.
- Customisations block the upgrade path. Panorama Consulting notes that customisations can create compatibility issues on cloud ERPs with automatic upgrades, and can conflict with or be overwritten by vendor updates.
- The vendor has announced end-of-support, or the release you run is no longer being invested in.
- The APIs are inadequate for agentic work. Deloitte, citing Gartner, warns that many agentic AI projects will fail because legacy systems were not designed for agentic interactions and rely on APIs and data pipelines that create bottlenecks.
- Technical debt has grown to a size that starves new work. McKinsey research indicates technical debt may represent up to 40% of the technology estate in large enterprises, with 10% to 20% of new-product budget diverted to servicing it.
If two or more of these describe the current environment, a wrap buys optionality that will be paid back with interest. The agent layer will end up encoding the ledger's flaws rather than routing around them.
The Shadow Ledger Test
The mechanical question that decides most of these evaluations is whether the wrap can be reconciled to the penny every day. An agent that posts entries into a legacy ERP creates a new class of audit risk: the agent's version of the truth and the ledger's version of the truth can drift, and drift is not discovered until close.
A shadow ledger is the control that prevents this. Every agent action, every proposed entry, and every posted transaction gets recorded in a parallel deterministic ledger. Each morning, the shadow ledger reconciles against the ERP's trial balance. Any variance is a stop condition, not a report. This is the discipline that makes a wrap defensible under SOX, and it is the same discipline a migration needs. Closing faster is mostly a reconciliation problem, and the wrap-versus-replace question is largely a question of which reconciliation problem is smaller.
If the current ERP cannot support that reconciliation (limited read APIs, no reliable audit trail on posted entries, no way to detach the agent's writes) then wrapping is a false economy. The honest answer is to plan the replacement.
Integration Reality and the API Surface
A wrap is only as good as the APIs it runs on. Enterprises average more than 1,000 applications, and the ERP has to talk to a meaningful subset of them for agents to do useful work: banks, payment processors, expense systems, billing platforms, tax engines, HR. The wrap does not remove that integration surface. It concentrates it.
Before committing to a wrap, three questions get answered on paper: which reads are supported, which writes are supported, and what the rate limits are on both. A close agent that can read a trial balance but cannot post an adjusting journal is an assistant, not an agent. Two-way sync is a governance question before it is a technical one, as covered in two-way sync ownership.
A Sequenced Path Most Buyers Land On
The pattern that shows up repeatedly in mid-market and enterprise evaluations is neither pure wrap nor immediate replacement. It is a sequenced path: wrap for twelve to twenty-four months to compress the close, clean the data, and prove out agent controls, then migrate the ledger with the agent layer already trusted and the chart of accounts already redesigned. The migration is smaller because the labour is already automated and the data is already reconciled daily.
This works because the two projects front-load different risks. The wrap tests whether agents can operate inside your controls without breaking them. The replacement tests whether a new ledger can absorb your business without losing history. Doing them in parallel is where the failures cluster. Doing them in sequence, with the shadow ledger as the bridge, is where the compounding starts.
How to Decide in the Next Sixty Days
The decision does not need a year of consulting. It needs three artifacts on the same page: the current chart of accounts with a note on what it cannot represent, the API inventory for the incumbent ERP with read and write coverage marked, and a plain list of where the close calendar actually goes hour by hour. If the calendar is labour, wrap. If the chart is structural, replace. If both are broken, wrap the labour first and replace the ledger next, in that order, with the shadow ledger holding the seam.
A free assessment against those three artifacts is usually enough to name the path. What it will not do is make the choice comfortable. Both paths are real work. The point of naming the conditions is to stop paying for the wrong one.
- 1Week 1–2Pull the current chart of accounts · Export CoA with segment usage; mark dimensions the business needs but cannot represent natively · Annotated CoA gap list
- 2Week 2–4Inventory the ERP API surface · List every endpoint agents would touch; mark read vs write coverage and rate limits · Read/write coverage matrix
- 3Week 3–5Map the close calendar to labour vs structure · Walk the close checklist; tag each task as agent-shaped labour or ledger-shaped structure · Labour/structure split of the close
- 4Week 5–6Run the shadow ledger feasibility test · Confirm the incumbent ERP can be reconciled to the penny daily from its own APIs · Go/no-go on wrap defensibility
- 5Week 6–7Score wrap vs replace conditions · Check the two condition lists against the environment; count how many hold on each side · Weighted decision sheet
- 6Week 7–8Commit to a path and a sequence · Choose wrap, replace, or wrap-then-replace; set the twelve-month milestone that would trigger the next phase · One-page decision memo