ERP implementation cost: what the quote leaves out

The number you are given is not the number you will spend

Three vendors have quoted your ERP implementation and the numbers are far apart. The instinct is to read the spread as a market rate and pick somewhere sensible in the middle.

The spread is rarely telling you what it appears to. Each quote covers a different amount of work, drawn at a different boundary. One has priced discovery properly and looks expensive for it. One has left integration as an allowance and looks competitive until the allowance runs out. One has assumed your data is in the state your export suggested.

A quote is a price for a vendor’s scope: their people, their build or configuration, their testing, their go-live support. A project is everything that has to happen for the business to run on a new system. The second is always larger than the first, and the difference is not padding. It is real work somebody has to do, usually your own team, usually alongside their existing jobs.

So the useful question is not which number is lowest. It is which number is complete, and what each vendor has assumed about the parts they did not price.

The cost risk is in the tail, not the average

One dataset is large enough to answer the cost question empirically rather than anecdotally. Bent Flyvbjerg and colleagues collected estimated and actual costs for 4,677 IT projects, of which 1,612 were ERP, and published the analysis in the Journal of Management Information Systems in 2022.

The result is not what either the vendor pages or the horror stories would lead you to expect. The median ERP project in that sample finished at 0.9 times its estimate, meaning slightly under budget. The mean was 1.3. The authors state plainly that overruns and underruns are about equally frequent.

Then the tail. The worst ERP project in the sample came in at nearly eighty times its estimate, and ERP is statistically distinct from every other project type in the data at p below 0.001. A companion paper published in the Project Management Journal in 2026 found that IT was the only one of twenty-three project categories whose distribution implies unbounded risk, with a mean and variance that do not converge.

Two honest caveats on that data: the projects completed between 2002 and 2014, and the figures compare implementation estimates against implementation actuals, explicitly excluding maintenance and operations. It is a study of how well this kind of work is estimated, not a study of what ERP costs to own.

It still reframes the exercise. You are not trying to predict a number. You are trying to work out, before you sign, which of the known tail risks your programme is carrying and what removing each one would take. The rest of this article is that list.

Most ERP cost and failure statistics are folklore

Before the quotes arrive, most buyers go looking for a benchmark. It is a reasonable instinct, and the search results are full of them: a cost per user, an average project total, a multiple of the licence fee, a failure rate. Very few survive being checked.

In 2019 two researchers at Trinity Business School traced the ERP failure rates that the field repeats, and published what they found. Almost every number you are likely to meet appears in it. The most widely quoted claim, that around ninety percent of ERP implementations fail or run late, traces to a personal estimate by the chairman of the Standish Group, quoted in a magazine article in 1998. The frequently cited fifty-one percent figure came from a 2001 survey in which only thirty-six percent of the respondents had an ERP system or were implementing one. A well-known consultancy study is cited for a sixty-seven percent failure rate; what it actually reported was that thirty-three percent of interviewees rated their initiative positively, and the failure figure is the citing author’s inference. Two further widely repeated ranges are, in the researchers’ words, based on their authors’ guesstimates.

The current crop is no better. In July 2026 we read eleven pages that search engines returned for ERP cost queries and recorded what each published and what it credited. The per-user benchmark that appears most often showed up at four different values. The rule of thumb expressing implementation as a multiple of licence cost appeared as five different multiples, none reconciled against the others. Fewer than half gave a working link to any source. On one page updated in 2024, the supporting citation was analyst research from 2016.

There is a definitional problem underneath the numbers too. Most of these statistics define failure as exceeding a budget or a date, which counts a system that works and is still in use years later as a failure, and treats the original estimate as though it were a fact. It is not a fact. The largest study of IT cost overruns describes budgets as an outcome of organisational negotiation, typically presented as a most-likely case and typically carrying little contingency.

So use published benchmarks to check the shape of a budget, never to set its size. We do not publish cost figures for our own work, for the same reason: a number offered before anyone has looked at your integration surface is an opening position rather than a price.

What actually puts a project in the tail

If the risk is concentrated rather than average, then the evidence worth having is about causes, not totals. Two published sources answer that with data instead of opinion.

What the projects that overran said went wrong

Panorama Consulting Group surveys ERP projects annually and publishes the reasons given by organisations whose projects went over budget. In the 2026 edition, the most common reason was that additional technology had to be purchased to meet the project’s goals, named by 54.9 percent, up from 32.6 percent three editions earlier. Scope expansion followed at 51.0 percent, technical issues at 43.1, organisational issues at 39.2, understated project staffing at 35.3, understated consulting fees at 31.4, and data issues at 29.4.

The schedule picture differs in an instructive way. Among projects that ran late, organisational issues led at 57.9 percent and scope expansion at 55.3. In the previous edition, data issues were the single largest cause of timeline overrun, at 63.6 percent. Data problems tend to cost you time before they cost you money, which is exactly why they surface after the budget has been agreed.

Two structural predictors: size, and how far you bend the product

The Standish Group’s 2015 CHAOS report, drawn from more than 25,000 software projects, published two gradients that are more useful than any cost estimate. Projects that purchased an application and made no modifications succeeded 57 percent of the time. Those that purchased and then modified succeeded 42 percent of the time. A fifteen point drop, attributable to customisation alone.

The size gradient is starker still. Small projects in that data succeeded 61 percent of the time and failed 7 percent. The largest category succeeded 6 percent of the time and failed 43 percent. Standish sells the report and its standing recommendation is to break large projects into small ones, so read it knowing that, and note the figures are now a decade old. The direction of both gradients has been reproduced too consistently to wave away.

Taken together, those are the strongest available arguments for the two decisions that most reduce cost risk: change the product as little as your process genuinely allows, and deliver in stages small enough to actually finish.

What the tail looks like from inside a public company

The most reliable accounts of ERP projects going wrong are not case studies. They are regulatory filings, written by the buyer under a legal obligation to be accurate. Revlon told the SEC that an ERP launch had left it unable to fulfil product shipments, and that it had not maintained effective internal control over financial reporting, naming the ERP implementation among the causes. Tile Shop Holdings disclosed that it had not designed effective controls over its ERP implementation to ensure appropriate data conversion and data integrity, nor provided sufficient end user training for its employees to operate the system and carry out their responsibilities.

Neither company describes software that did not work. Both describe readiness and governance that were not there: data that was not right, controls that were not designed, people who had not been trained. Every one of those is a line somebody decided not to fund.

What a vendor quote actually covers, line by line

Most ERP quotes contain the same eight lines. What varies, and what decides whether the total means anything, is which of them is a commitment and which is an assumption wearing a number.

The pattern worth noticing: the two lines most often quoted as an allowance, data migration and integration, are also the two whose real size is least knowable when the quote is written. That is not necessarily anyone being dishonest. It is what happens when a number is required before the work that would inform it has been done.

The costs that land on your side of the line

None of the following appears on a vendor quote, because none of it is the vendor’s money to spend. All of it is real, and together it is where the difference between the quote and the project lives. If you build one document before you compare vendors, build this one, with your own figures against each line.

1. 01

   Your own people, for the length of the programme

   Process owners answering questions, a finance lead making data decisions, someone from IT on access and infrastructure, and superusers testing what they will later teach. On most programmes this is the largest cost outside the quote, and the one least often written down, because it is paid in salaries that were being paid anyway.

2. 02

   The months before you chose anyone

   Writing the requirement, running demos, checking references, negotiating, and reviewing contracts. Selection is real work by senior people, and all of it is spent before a single vendor is engaged.

3. 03

   Getting your data into a state worth migrating

   Deciding which customer record is the real one, what happens to ten years of exceptions, and which fields nobody has populated since 2019. A vendor can move data. Only your team can decide what it should say.

4. 04

   Running two systems while the new one proves itself

   For a defined window the old system stays up, both are fed, and somebody reconciles them. That is a genuine operating cost, and it is the price of having a way back. Skipping it costs less right up until the day you need it.

5. 05

   The dip after go-live

   Experienced people work more slowly on a system they have used for a week than on one they have used for nine years. Throughput falls before it rises. Planned for, it is a manageable few weeks. Ignored, it turns into a hiring conversation.

6. 06

   The system you are replacing, until it is actually off

   Licences, support contracts, and the infrastructure underneath continue while the new system beds in. Programmes routinely pay for both for longer than planned, and the overlap is rarely in the original budget.

7. 07

   Backfill for the people you seconded

   The person who understands your process best is the person the project needs most, and they still have a day job. Either it waits or somebody covers it, and both have a price.

The two lines that decide whether the number holds

Data quality, not data volume

Migration estimates are usually built from record counts, because record counts are the one thing you can get quickly. Record counts are not what makes migration expensive. What makes it expensive is that after a decade of live use, the same customer exists three times with different payment terms, a field intended for one purpose has been quietly used for another since a system change in 2018, and a handful of processes depend on that workaround.

None of that is visible in an export. It surfaces when somebody tries to load the data into a system with real validation, which is usually well after the number was agreed. The way to price migration honestly is to migrate a sample of the real data during scoping, not to estimate from the schema.

The integration surface

An ERP is only as useful as the systems that keep talking to it. Every system that stays is a boundary, and boundaries are where fixed prices become open ones. The variables are not technical exotica. They are ordinary questions with expensive answers.

Ask for integration to be priced per boundary, named system by named system. A single line called integration cannot be compared between two quotes, and it is the line that most often turns a fixed price into an open one. This is the same boundary that decides the cost of any custom software development project, not only an ERP.

The comparison nobody runs: what the current system costs you

Almost every ERP business case compares the cost of the new system against zero. That is the wrong baseline. The alternative to implementing is not spending nothing. It is continuing to pay whatever the current arrangement costs, and that figure is rarely written down anywhere.

It usually shows up in these places:

• Days of every month lost to closing the books, and the overtime attached to them
• People whose real job has become moving data between two systems that do not talk
• Reporting that arrives accurate and too late to change the decision it was for
• Stock, cash, or capacity held as a buffer against numbers nobody fully trusts
• Errors that reach a customer or a regulator, and the rework behind each one
• Licences and support on the system you already run, which continue either way
• The decisions nobody makes, because assembling the data to make them takes a week

None of that is hypothetical, and most of it is measurable inside a fortnight by asking the people who live it. A business case built on those numbers survives a finance review in a way that one built on projected efficiency gains does not, and it gives you a defensible answer to the only question that matters at approval: compared with what.

When the money leaves matters more than the total

Two programmes with the same total are different propositions if one spends it over eighteen months before anything works and the other spends it in stages that each go live. The total is what the board approves. The shape is what the business lives with, and it is also the better risk control.

A programme built around a single switchover date concentrates both the spend and the risk at the end. Everything is paid for before anything is proven, and if the date moves, which it usually does, the cost of waiting is carried on top. A programme delivered capability by capability spends less before the first proof, and each stage earns its place before the next begins. That is the staged approach we use for replacing systems that cannot go offline, and the cash-flow profile is a large part of why.

So ask for the payment schedule alongside the total, and ask what each milestone actually certifies. A milestone tied to a document being delivered proves that a document was delivered. A milestone tied to a capability running on real data with real users proves something you can bank.

There is also a predictable moment when the extra invoices arrive, and it is later than most plans assume. Change requests cluster around user acceptance testing, because that is the first time the people who will actually operate the system see it. The stakeholders who agreed the scope were usually functional managers; the people in testing are end users looking for the workflow they have today. Budget for that gap before you meet it, because meeting it with no contingency left is how a fixed price turns into a negotiation.

What you can cut, and what cutting it costs you

Every ERP budget gets cut somewhere. The question is whether the cut is made deliberately, with its consequence understood, or made late in a spreadsheet because a number had to come down.

Two of those are usually worth cutting: custom work where standard behaviour is genuinely acceptable, and integration to a system that turns out not to matter. Both are real savings with no later bill. The rest buy a reduction now against a larger cost later, which is a trade a programme can make on purpose and should never make by accident.

Training is the cut that looks most harmless and reads worst afterwards. It is a clean line on a quote, it is easy to defer, and it is the one a company ends up describing to its regulator, as Tile Shop did, as insufficient end user training for employees to operate the system and carry out their responsibilities.

What to demand in writing before you compare quotes

These eight items make two quotes comparable. Ask for them before you put totals side by side, because without them you are comparing documents that describe different projects.

1. Integration priced per boundary, named system by named system, never as a single line
2. Data migration priced against a sample of your real data, with a stated position on what happens if the rest is worse than the sample suggested
3. The definition of a defect, the definition of a change request, and who decides which one a given item is
4. The change request rate, and how long a change takes to be priced once raised
5. Named people, their role on the programme, and what happens when one of them leaves
6. What go-live support includes, for how many weeks, and what parallel running is expected of your side
7. What the first year of support covers, and what it explicitly excludes
8. The renewal terms, and any cap on the increase. An introductory discount that expires at the end of the initial term is a decision you are making now about a bill that arrives in three years
9. What it costs to leave: how you get your data out, in what format, and whether direct access to your own database is included or chargeable
10. What you own at the end: the code, the configuration, the data model, and the documentation

A vendor who answers all eight readily is telling you something useful about how their projects run. A vendor who cannot answer six of them before contract is usually not being evasive. They have not done the work yet, and the number they gave you reflects that.

When a custom ERP build is the wrong answer

Three situations where the honest answer is not to build, and where we say so on the call:

• A mature product already fits your process. Buy it and configure it. Custom earns its cost where a process is genuinely yours, not where it is merely familiar, and where the line falls between what you buy and what you build is worth settling before either.
• The process itself is the problem. New software makes a broken process faster and more expensive rather than better. Fix the process, then decide what it needs.
• You cannot free your own people. Every cost in this article that falls on your side of the line needs an owner. If nobody can be spared, the timing is wrong, and no vendor can solve that for you.

Where a build is the right answer, the sequence that keeps a number honest is unglamorous: scope the integration surface, migrate a sample of the real data, and price both before anyone commits to a total. It is slower at the proposal stage and considerably faster everywhere after it, and it is the sequence our own ERP delivery is built around.