Norvalayne  /  Insights

Connecting AI to your ERP: what actually works

Published 3 August 2026  ·  Norvalayne  ·  9 min read

There is a persistent gap between what AI vendors demonstrate and what mid-market companies actually deploy. The demo shows a model answering questions about inventory in natural language. The reality is that the inventory data lives in three systems, two of them undocumented, and nobody is quite sure which one is authoritative.

This guide covers what the work actually involves: how long it takes, what drives cost, why most attempts stall, and which use cases return value fastest. It is written for companies running an established ERP who want AI to do real operational work rather than produce a proof of concept that never ships.

Why do most AI and ERP projects fail?

The failure rate is not a secret and it is not small. Gartner projects that more than 40% of agentic AI projects will be cancelled by the end of 2027, driven by escalating costs, unclear business value, and inadequate risk controls.¹ Among mid-market companies specifically, 62% found generative AI harder to implement than expected and 92% hit implementation challenges.²

Two causes dominate.

1. The data is not ready, and nobody budgeted for that

Over 60% of organizations cite data quality as a major barrier to AI adoption, and among mid-market companies, 41% name it their single largest obstacle.² This is not a surprise once you look at how most mid-market data actually lives: distributed across disconnected systems, with 79% of teams reporting undocumented data pipelines.²

An LLM asked to reason over inconsistent, duplicated, or stale ERP records will produce confident and wrong answers. The model is not the problem. The problem is that three departments each maintain their own version of the customer record and none of them agree.

Budget accordingly. On a realistic project, data access, mapping, and cleanup consume 40 to 60% of total effort. Teams that treat this as a small preliminary step before the interesting AI work discover the ratio the hard way.

2. The scope is too broad on day one

The most common structural mistake is launching AI across the organization at once rather than isolating it in a contained module. When AI is embedded in forecasting and it underperforms, forecasting is degraded. When AI is wired simultaneously into payroll, order fulfillment, and procurement, a single failure stalls the entire programme and burns the political capital needed to try again.

Deploy AI where failure is survivable, prove the value, then expand. Companies that reverse this order rarely get a second attempt.

How long does it take to connect AI to an ERP system?

For a single, well-scoped use case, six to twelve weeks from kickoff to production is a realistic range. The distribution looks roughly like this:

Projects that stretch past six months almost always did one of two things: attempted multiple departments simultaneously, or discovered mid-build that the data required a remediation project nobody had scoped. The second is avoidable with an honest two-week discovery phase.

Which AI use cases pay back fastest in an ERP environment?

The best first project has four properties: it is document-heavy, high-volume, low-risk if wrong, and has a measurable baseline. That last one matters more than teams expect — if you cannot state how many hours the process consumes today, you cannot prove the project worked.

Strong first candidates

• Invoice and purchase order extraction. High volume, structured output, immediately measurable in hours saved. Errors are caught downstream by existing reconciliation.
• Quote and proposal generation. Pulls from ERP pricing and product data, drafts the document, a human reviews before it leaves. The review step makes the risk profile acceptable.
• Natural-language reporting. Lets non-technical staff query ERP data without waiting on an analyst. Read-only, so the blast radius of a mistake is a wrong answer rather than a wrong transaction.
• Intake and ticket triage. Classifying and routing inbound requests. Misrouting is recoverable; the time saved is continuous.

Poor first candidates

• Anything touching payroll or payments. The error cost is severe and the regulatory exposure is real.
• Autonomous order fulfillment. Physical-world consequences, and errors compound before anyone notices.
• Demand forecasting as a first project. The feedback loop is months long, so you cannot tell whether it is working until far too late. Excellent second or third project, poor first one.

What drives the cost

Mid-market companies already allocate 3 to 5% of annual revenue to integration and ERP systems.³ AI work priced against that baseline is usually a rounding error by comparison, provided the scope stays disciplined.

Cost is driven by four factors, in descending order of impact:

1. Data condition. Clean, documented, API-accessible data can cut project cost by half. Undocumented data spread across systems can double it.
2. Number of systems touched. Each additional system adds integration surface, authentication complexity, and failure modes. One system is straightforward. Four is a different category of project.
3. Accuracy requirement. A process that tolerates 95% accuracy with human review is dramatically cheaper than one requiring 99.5% autonomous accuracy. Be honest about which you actually need.
4. Ongoing model costs. Usually the smallest line item and frequently the one people fixate on. For most mid-market workloads, inference costs are modest relative to the engineering.

Should a mid-market company replace its ERP to adopt AI?

Almost never. ERP replacement is a multi-year project with a well-documented history of failure, and adopting AI is a poor reason to trigger one.

Nearly every established ERP exposes an API, a database layer, or an export mechanism sufficient to build against. Connecting AI to what you already run delivers most of the operational benefit at a fraction of the cost and risk, and critically it can be done one process at a time — which is exactly the incremental approach the failure data argues for.

The legitimate exception is an ERP so old it has no programmatic access at all. Even then, the correct sequence is to solve the access problem specifically, not to restructure the entire business around a replacement.

A practical starting sequence

1. Pick one process that is document-heavy, high-volume, and survivable if it fails.
2. Measure it honestly. Hours per week, error rate, cost. Without this number you have no way to prove value later.
3. Audit the data that process depends on before committing to a build. Two weeks here prevents most six-month overruns.
4. Build the narrow version. Resist adding adjacent use cases mid-project, which is where scope creep enters.
5. Run it in parallel with the human process until accuracy is proven against real output.
6. Publish the result internally — the measured before and after. This is what funds the second project.

The pattern that works is unglamorous: narrow scope, honest measurement, incremental expansion. The pattern that fails is a broad transformation programme announced at an all-hands and quietly cancelled eighteen months later.