Brian Kalms
Partner & Managing Director - London
The AI-ERP debate most boards are having is the wrong one. The question is not whether AI replaces ERP. It is which parts of the enterprise need certainty, and which parts need judgment—what must be deterministic and what can be probabilistic.
Get that right, and the downstream decisions on budget, architecture, and headcount will follow. Get it wrong, and you buy the wrong thing.
The dividing line that matters: deterministic versus probabilistic
Most leaders conflate two questions: what must be true and reproducible, and what requires judgment. ERP’s job is the first.
Invoice recording and three-way matching are both deterministic. Same inputs, same answer, every run, testable by an auditor. There should be no room for interpretation and no value in adding any.
The reasoning starts when the match breaks. Why the 3% price variance? It might be supplier error, an unpriced contract change, or a coding decision on the unmatched invoice. That exception work is where the headcount and the frustration have always sat.
The same cut appears across the enterprise: the purchase order, the contract, and the supplier master are record; should-cost, supplier risk, and variance explanation are reasoning. That is exactly where AI earns its place. The architecture becomes more agile as a result, and—as we highlighted in AlixPartners’ 2026 State of Enterprise Technology Report—that agility demands stronger governance, not less.
Loyalty programs show the same pattern. The points balance is a balance-sheet liability and therefore deterministic; propensity and offer design are not. Even the breakage assumption is judgment that must be frozen.
Judgment already sits in the ledger; it just needs to be frozen
The objection here is predictable: finance systems must be judgment-free. They never were. IFRS 15 variable consideration, IFRS 9 expected credit loss, inventory provisions and transfer pricing are all estimates sitting inside audited accounts today.
The requirement was that judgment is documented, governed, reviewable, and owned, then frozen into a determinate record. The question is the freezing mechanism: who signs, what inputs are captured, and what reproduces on re-run. This is architectural, not a model capability. Model quality will keep improving; the requirement will not move.
What AI changes in ERP
AI collapses the cost of judgment, not the cost of truth, and that distinction is the whole argument. AI reasons over whatever state you give it. Feed it a clean, governed record, and it produces fast, defensible analysis. Feed it inconsistent extracts, and it produces the 2005 spreadsheet estate with better grammar and unearned confidence. That is the trap. AI amplifies the record layer beneath it, which means the better your core gets, the more valuable your AI workflows become. Skip the core, and you get agents reasoning over noise.
It helps to be precise about which part of the ERP is under pressure. It has three layers stacked vertically: the interface through which people interact with it, the workflow logic that encodes how processes run, and the back-end system of record that holds governed transactional state.
AI dissolves the interface layer, because a conversational agent that retrieves and acts replaces the screens and menus users navigate today. It erodes much of the workflow layer, because an agent can orchestrate a process and handle its exceptions, rather than a user stepping through configured transactions. It leaves the back-end record layer standing, and in fact makes it more valuable, because that governed state is exactly what the agent must reason over to be trustworthy. The disruption is vertical and uneven, and the value migrates downward, toward the record and away from the screens and bespoke process logic.
So, AI raises ERP’s return; it does not substitute for it. What changes is what you should be buying from an ERP program: less bespoke workflow in the core and more strength in data, integration, governance, testing, and the reasoning layer above it. AI also earns its place inside the implementation itself, in migration, entity resolution, master data harmonization, and test generation.
What actually dies
Not ERP, not governance, not architecture. What dies is heavy ERP workflow customization, bespoke reporting embedded in the core, and integration sprawl bolted tightly to the ERP version. The economic logic of the three-year implementation program goes with it, because that program was never really about the ledger in the first place.
Clean core has been preached for twenty years and lost every time, because there was nowhere else to put the differentiation. The advice is old; the alternative is new.
That new layer is faster to change and cheaper to reverse, not merely cheaper. Prompts are cheap; knowing you have not degraded exception-handling accuracy is not.
The new architecture: a vanilla core and two custom layers
ERP will not disappear, but much of the customization will. AI makes it viable to keep the core vanilla and build the difference in two loosely coupled layers above it.
- The integration layer. This connects operational systems to a vanilla core, and it is largely deterministic. AI-supported coding makes it more affordable and feasible to build than before.
- The reporting and analytics layer. The goal is to replace the homegrown Excel and custom Power BI estate with a well-architected analytical layer, largely deterministic, fronted by a business-oriented conversational interface that fetches the right report or dashboard rather than forcing users to hunt for it.
Both layers stay loosely coupled. Upgrading the ERP no longer triggers a large program. It triggers a suite of no-regression tests and minor API adjustments where needed.
Where this advice fails
An ungoverned reasoning layer above a clean core rebuilds the same estate one floor up. Nobody owns the logic. There is no version control over decisions written in natural language, and no regression test when a model is deprecated.
Changes in underlying models impose a rework cadence that ERP never had, and that nobody is budgeting for. Skip that, and you have simply moved the mess upstairs and given it a confident voice.
The enabler is business data literacy, owned by the business. None of this works without a business-centric data team that owns what terms actually mean. What is an “active customer”? What is “fully-loaded cost”? Once a reasoning layer runs on them, they become architectural constraints, and the wrong choice is now expensive.
The functions that win will interrogate the data in depth and argue with AI outputs, rather than just receive them.
What this means for how you invest
For a leadership team holding an ERP estate, a meaningful tranche of planned and in-flight spend is now at risk of obsolescence, specifically the customization and tightly coupled integration the vanilla-core-plus-layers model is designed to avoid.
The decision is where to stop investing in configuration that an embedded agent or a loosely coupled layer will soon render redundant, and how to redirect that capital toward the data, governance, and integration foundations that make the reasoning layer pay off. This is a capital-allocation question before it is a technology question, and it is answerable now rather than after the next upgrade cycle.
The vendors understand this. Microsoft, SAP, and Oracle are embedding AI directly into the platforms because the commercial question is no longer whether AI eats ERP, but whether value shifts from seat-based licensing of screens to consumption-based agentic execution, and who captures that margin.
For buyers, that also changes the switching-cost equation. The moat has long been accumulated configuration, integrations, and process embedding; if AI lowers the cost of reconfiguration and migration, the moat thins.
The honest position on savings is that the direction of travel is clear, but the magnitude is not yet benchmarkable. What can be stated with confidence is the shape of the risk: the exposure is misallocated capital and stranded configuration, not a missed savings target that competitors have already booked. That reframes the urgency correctly.
What this means for execution
The immediate question is cost and value: which committed spend is now exposed, and what to stop or defer. The harder question is execution: how to move to a vanilla core and an agentic layer without breaking control, and how to reshape the operating model as exception and process-navigation work is absorbed.
In a carve-out or separation, the assumption that the separated entity needs its own fully customized ERP instance, at significant cost-to-achieve and a long stand-up, no longer holds if the interface and workflow layers are commoditizing. That changes both the separation cost model and how a buyer should value the target’s systems estate in diligence.
Winners and losers
The losers are clear: the traditional system-integrator economics of the three-year implementation program are under real pressure. This is not the death of large ERP work, but the shape of it is changing fast.
The winners are the organizations that have already invested in data infrastructure, governance, architecture, and business data literacy. That investment used to look like overhead, but it is now the foundation that makes AI pay.
Let the tech stack follow the value; everything else is detail.
