ERP implementation cost: what the vendor’s quote leaves out

The eight lines on an ERP quote

Most ERP implementation quotes contain the same eight lines and a total. The total is the figure that goes to the board. It is the vendor’s price for the vendor’s scope: their people, the configuration or build, their testing, their go-live support.

ERP implementation cost is a larger number. The project also spends your own people, the months you spent choosing, and the old system you keep paying for until the new one takes over. A quote can be accurate on every line and still fall well short of the budget.

So this article reads the quote as a document. It starts with the eight lines and what moves each one. Then it goes down what is missing: the license, any benchmark to check the total against, and firm numbers for data and integration. After those come the costs on your side, the cost of the system you already run, and the dates the money leaves.

We offer ERP software development services, so we are one of the vendors whose quotes this article shows you how to take apart. We publish no prices of our own. None of the projects our clients have reviewed on Clutch is an ERP, so there is no client story here either. Every figure comes from a vendor’s price list, a review platform, a peer-reviewed study, an industry survey or a regulatory filing. Where a source sells something, we say so.

Read down the middle column. Some lines are commitments, and some are assumptions with a number attached. Data migration and integration are the two most easily quoted as allowances, because their real size is the least knowable when the quote is written.

That is usually a matter of timing, not bad faith. The number was needed before the work that would inform it had been done. Ask each vendor to mark every line as fixed, an allowance against a stated assumption, or excluded. A total made of allowances is a different kind of number from a total made of fixed lines.

What ERP software costs, where a vendor publishes it

ERP software is usually priced per user per month, and the license is the only part of an ERP with a public price. With a subscription product the implementation partner is paid separately, so first check whether the quote in your hand includes the license at all.

Only some vendors publish the price, and Microsoft is one. We read its US price pages in October 2026. Dynamics 365 Business Central costs 80 US dollars per user per month for Essentials and 110 for Premium, with Team Members at 8, all paid yearly. Dynamics 365 Finance, the product aimed at larger organizations, is 210 US dollars per user per month, or 300 for Finance Premium. Microsoft notes that prices vary by currency, country and region.

Take an illustration, which is no quote. A hundred people on Business Central Premium is 100 × 110 dollars × 12 months, or 132,000 US dollars a year in licenses. That is before a single process is configured, a record migrated or a person trained.

Almost every ERP quote follows one of three pricing models, and they move money at different times. A subscription charges per user per month, indefinitely, as Microsoft does. It is cheap to start and grows with headcount. A perpetual license is a large payment up front, followed by an annual maintenance fee calculated on that license for as long as you want updates and support.

The third model is a custom build, which carries no seat license at all. You pay for the build and then own the code, which means you also own its hosting, support and change.

Which is cheaper depends on how long you keep the system and how far your process sits from the one the product expects. Seat licenses that looked small at fifty users look different at five hundred. A custom build that looked expensive in year one looks different in year six. Settle where that line falls before you ask anyone for a number.

We build custom systems, and there are two cases where we would tell you to leave that model alone. If a mature product already fits your process, buy it and configure it. Custom earns its cost where a process is yours and not merely familiar. And if the process itself is broken, new software makes it faster and more expensive without making it better, so fix the process first.

If the quote is for SAP

We found no published price for implementing SAP. We would distrust any page that offers one without saying how many projects it came from. What we can tell you is what is driving most SAP quotes right now, and it is a date.

SAP announced in February 2020 that mainstream maintenance for the core applications of SAP Business Suite 7 runs until the end of 2027. That suite includes the SAP ERP 6.0 system many organizations still call ECC. Optional extended maintenance follows until the end of 2030, at a premium of two percentage points on the existing maintenance basis. SAP S/4HANA carries a maintenance commitment until the end of 2040.

So many SAP quotes are migration quotes. They are driven by the same things as any other ERP number in this article. Those are how much custom code the old system carries, how clean the data is, and how many systems connect to it. A timetable set by a maintenance deadline also tempts people to cut the lines that make the number reliable.

Is there a benchmark for the implementation total?

There is none you can rely on. The implementation has no list price anywhere, because it depends on your processes, your data and the systems that stay.

The closest published reference is general, with no ERP figure of its own. Clutch, the review platform, says most software development projects reviewed on its platform cost 10,000 to 49,999 US dollars. The average ran to 132,480 US dollars over about 13 months, roughly 10,209 dollars a month. Clutch’s data skews to smaller projects. An ERP covers several departments, migrated data and integrations, which is a larger scope than most projects in that data. Read the band as context and not as a budget.

Most buyers search for a figure anyway, so we counted what the search returns. On October 9, 2026 we opened the eight pages Google ranked in the US for “ERP implementation cost”. Six could be read and two refused automated access. Five of the six published a dollar range for a full implementation, and none of the five named a source or a method for its own range.

Their company-size bands ran from 15,000 to 10 million US dollars. All six publishers sell ERP software, implementation or referrals to vendors, and none said so in the text. None mentioned the cost of keeping the old system running in parallel.

An earlier read, in July 2026, found the same thing across more pages. We read eleven pages that search engines returned for ERP cost queries and noted what each published and what it credited. The per-user benchmark that appeared most often showed up at four different values. The rule of thumb that expresses implementation as a multiple of license cost appeared as five different multiples. Fewer than half gave a working link to a source, and one page updated in 2024 leaned on analyst research from 2016.

We do not hold that against any one page. A number was wanted and there was none with a method behind it. It is the reason the figures in this article are list prices, peer-reviewed data, surveys with their interests stated, or filings.

Before a benchmark means anything, you need to know how many projects it drew on, their size and industry, and the year. You also need to know what it counted: the license, the license and implementation, or your internal time as well. Without those, use a published benchmark to check the shape of a budget, never to set its size.

That leaves one test you can apply to a quote, which is completeness. The sections below go through what is usually missing.

Data and integration decide whether the number holds

Data migration and integration decide whether an ERP number holds, because they are the two lines whose real size is least knowable when the quote is written. They are on the quote, but as allowances, so the firm number is what is missing.

(opens full size in a new tab)

Migration estimates are usually built from record counts, because record counts are quick to get. Record counts are a poor guide to the cost. The expense comes from a decade of live use. The same customer exists three times with different payment terms. A field meant for one thing has held another since a system change in 2018, and a handful of processes depend on that workaround.

None of that shows in an export. It surfaces when somebody loads the data into a system with real validation, usually long after the number was agreed. The reliable way to price migration is to migrate a sample of the real data during scoping, and not to estimate from the schema.

Integration has the same problem at every system that stays. An ERP is only as useful as the systems that keep talking to it. Each of those boundaries is a place where a fixed price becomes an open one. Six ordinary questions decide what each boundary costs. For manufacturers, the shop floor systems are usually the hardest of those boundaries, which our custom manufacturing software development page covers.

Ask for integration to be priced per boundary, system by named system. A single line called integration cannot be compared between two quotes, and it is a line that can turn a fixed price into an open one.

The same boundary decides the cost of any custom software project. It is one of the main reasons quotes for the same custom build differ so widely.

Seven costs that are on no quote

Seven costs sit outside every vendor quote: your own people’s time, the selection months, data cleanup, parallel running, the dip after go-live, the old system’s overlap and backfill. They are missing because none of it is the vendor’s money to spend. If you build one document before you compare vendors, make it this list, with your own figures against each line.

(opens full size in a new tab)

Your own people come first, for the length of the program. Process owners answer questions, a finance lead makes data decisions, someone from IT handles access and infrastructure, and superusers test what they will later teach. On most programs this is the largest cost outside the quote. It is also the least often written down, because it is paid in salaries that were being paid anyway.

Some of that time was spent before you chose anyone. Writing the requirement, sitting through demos, checking references, negotiating and reviewing contracts are all senior people’s work, and all of it happens before a vendor is engaged.

Then there is getting your data into a state worth moving. Somebody has to decide which customer record is the real one, what happens to ten years of exceptions, and which fields have sat empty since 2019. A vendor can move data. Only your team can decide what it should say.

For a defined window you will run two systems while the new one proves itself. The old system stays up, both are fed, and somebody reconciles them. It is the price of having a way back.

After go-live there is a dip. Experienced people work more slowly on a system they have used for a week than on one they have used for nine years. Planned for, it lasts a few weeks. Ignored, it becomes a hiring conversation.

The old system keeps costing money until it is actually off. Licenses, support contracts and the infrastructure underneath keep running while the new system beds in, often for longer than planned. The overlap is rarely in the original budget.

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

What these lines look like when they go unfunded is on public record, in regulatory filings written by the buyer under a legal duty to be accurate. Revlon told the SEC that an ERP launch had left it unable to fulfill product shipments. It also said it had not maintained effective internal control over financial reporting, and named 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 had it 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 that was missing: data that was wrong, controls that were never designed, people who were not trained. Each of those is a line somebody decided not to fund.

Ask any vendor to state in writing which of your roles they need, when, and for roughly what share of a working week. One who has done this before can answer straight away, and the answer becomes a line in your budget. If you cannot free those people, the timing is wrong. Every cost in this section needs an owner on your side, and no vendor can supply one.

What the system you already run costs

The system you already run costs you something every month, and that figure is the right baseline for an ERP business case. Almost every business case compares against zero instead. The alternative to implementing is to carry on paying for the current arrangement, and that cost is rarely written down anywhere.

It hides in familiar places. Days of every month go on closing the books, with overtime to match. Some people’s real job has become moving data between two systems that do not talk. Reports arrive accurate and too late. Stock, cash or capacity is held as a buffer against numbers that are not quite trusted.

Add the errors that reach a customer or a regulator, and the rework behind each one. Add the licenses and support on the system you already run, which continue either way.

Most of it can be measured inside a fortnight by asking the people who live with it. A business case built on those numbers survives a finance review far better than one built on projected efficiency gains. At approval, finance asks what the spend is being compared with, and this is the answer.

Where to cut, and where the cut comes back

The safe cuts are custom work where the standard process is fine and integrations that turn out not to matter. Most other cuts come back later as a larger bill.

With the missing costs added, the budget is larger than the quote, and every ERP budget gets cut somewhere. What you control is whether the cut is made on purpose, with its consequence understood, or late in a spreadsheet because a number had to come down.

Custom work is the best saving available where the standard process is fine, and it comes with no later bill. The evidence is the Standish Group’s 2015 CHAOS report, drawn from more than 25,000 software projects. Projects that bought an application and changed nothing succeeded 57 percent of the time. Those that bought it and then modified it succeeded 42 percent of the time.

The same report shows that size matters more. Small projects in that data succeeded 61 percent of the time and failed 7 percent. The largest succeeded 6 percent of the time and failed 43 percent.

Standish sells the report, its standing advice is to break big projects into small ones, and the figures are more than a decade old. The direction of both gradients has been reproduced too often to wave away. They support the two decisions that most reduce cost risk: change the product as little as your process allows, and deliver in stages small enough to finish.

Integration to a system that turns out not to matter is a real saving too, as long as you are sure. A boundary cut wrongly becomes permanent manual re-entry.

The other cuts trade a saving now for a larger cost later. Cut discovery and the scope is written from assumptions, so the change requests arrive during the build. Cut data cleanup and the numbers are wrong at go-live, after which people stop trusting the new system. Cut parallel running and you have no way back on the one day you need one. Cut go-live support and your team absorbs the first month of exceptions alone.

Cut testing and you find the exceptions in production, in front of customers. Training looks the most harmless cut of all, because it is a clean line and easy to defer. It is the one Tile Shop ended up describing to its regulator as insufficient end user training for employees to operate the system.

Ask when the money leaves, as well as how much

The payment schedule matters as much as the total, because it decides how much you have spent before anything is proven. Take two programs with the same total. One spends it over eighteen months before anything works. The other spends it in stages that each go live. The board approves the total, and the business lives with the schedule.

A single switchover date concentrates the spend and the risk at the end. Everything is paid for before anything is proven, and if the date moves, the cost of waiting is added on top. Delivering capability by capability spends less before the first proof, and each stage has to work before the next is paid for. It is the staged approach we use for 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 certifies. A milestone tied to a document proves a document was delivered. A milestone tied to a capability running on real data with real users proves the capability works.

Expect the extra invoices later than most plans assume. Change requests cluster around user acceptance testing, because it is the first time the people who will operate the system see it. The scope was agreed by functional managers. The testers are end users looking for the workflow they have today. Keep contingency for that moment, because a fixed price with no contingency left turns into a negotiation.

Why an average cannot predict your ERP implementation cost

An average cannot predict your ERP implementation cost because most projects land close to their estimate and a few overrun by many times. That matters when you size the contingency, the one line you add to the budget yourself.

One dataset is large enough to show the pattern. Bent Flyvbjerg and colleagues collected estimated and actual costs for 4,677 IT projects, 1,612 of them ERP, and published the analysis in the Journal of Management Information Systems in 2022.

The result matches neither the vendor pages nor the horror stories. The median ERP project in that sample finished at 0.9 times its estimate, slightly under budget. The mean was 1.3. The authors report that overruns and underruns were about equally frequent.

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

So the typical ERP project lands roughly where it was estimated, and a few are catastrophic. An average describes neither, and no benchmark can tell you what yours will cost. The useful thing to work out is what would put you in the tail.

Two caveats apply. The projects completed between 2002 and 2014. The study also compares implementation estimates with implementation actuals and leaves out maintenance and operations. It tells you how well this kind of work is estimated, and nothing about what an ERP costs to own.

The failure rates you will be shown

The ERP failure rates in circulation are much weaker evidence than that study. In 2019 two researchers at Trinity Business School traced the rates the field repeats, and published what they found.

The most quoted claim is that around ninety percent of ERP implementations fail or run late. It traces to a personal estimate by the chairman of the Standish Group, quoted in a magazine in 1998. The often cited fifty-one percent came from a 2001 survey in which only thirty-six percent of 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 reported was that thirty-three percent of interviewees rated their initiative positively, and the failure figure is the citing author’s inference. Two more widely repeated ranges are, in the researchers’ words, based on their authors’ guesstimates.

Most of these statistics also define failure as missing a budget or a date, which treats the original estimate as a fact. The largest study of IT cost overruns describes budgets as the outcome of organizational negotiation, usually presented as the most likely case and usually carrying little contingency.

What the projects that went over budget blamed

They blamed technology they had not planned to buy and scope that grew, ahead of technical, organizational, staffing and data problems. The source is Panorama Consulting Group, which surveys ERP projects every year and publishes the reasons organizations give for going over budget.

In the 2026 edition, the most common reason was having to buy additional technology to meet the project’s goals. It was named by 54.9 percent, up from 32.6 percent three editions earlier. Scope expansion followed at 51.0 percent, then technical issues at 43.1, organizational issues at 39.2, understated staffing at 35.3, understated consulting fees at 31.4 and data issues at 29.4.

The reasons for running late are ordered differently. Among projects that ran late, organizational issues led at 57.9 percent and scope expansion at 55.3. In the previous edition, data issues were the largest single cause of delay, at 63.6 percent. Data problems cost you time before they cost you money, which is why they surface after the budget is agreed.

Weigh that with care. Panorama sells ERP selection, change management and project recovery. Its samples are small, self-selected from its own audience, and lean to mid-market organizations. Trust the ranking of causes, which is stable across editions, more than the exact percentages.

Set the ranking beside the quote and some causes are lines you have already read. Understated staffing is your own people’s time, and data issues are the migration line. Under the rest we see one mechanism: data migration and integration are estimated before anyone can know their size, and the real size arrives mid-build.

What to get in writing before you compare totals

Get ten things in writing, covering integration, migration, change terms, people, support, renewal, exit and ownership. Ask for them before you put totals side by side. Without them you are comparing documents that describe different projects.

1. Integration priced per boundary, named system by named system, never as one line.
2. Data migration priced against a sample of your real data, with a stated position on what happens if the rest is worse.
3. The definition of a defect, the definition of a change request, and who decides which is which.
4. The rate for change requests, and how quickly a change is priced once raised.
5. Named people, their roles, 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 excludes.
8. Renewal terms and any cap on increases. An introductory discount that expires is a decision you make 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 access to your own database is included.
10. What you own at the end: the code, the configuration, the data model and the documentation.

A vendor who answers all ten readily is showing you how their projects run. One who cannot answer half of them before contract is usually not being evasive. They have not done the work yet, and their number reflects that.

The choice between fixed price and time and materials follows from the same list. A fixed price is worth having for work whose scope is known, which after proper discovery is most of the build. It is worth much less on migration and integration, where a fixed price built on unstated assumptions just moves the argument to a change request.

A structure that works is to buy discovery on its own and fix the price for what discovery defined. Then map the integration boundaries, migrate a sample of the real data, and price both per boundary against what was found. It is slower at proposal stage and faster everywhere after.

ERP quotes that do not line up, or a business case that compares against zero, are both things we can read with you. Send us the brief and the quotes. We sign an NDA before the first call. The call is 30 minutes with the people who would build the system, and they will mark which lines on each quote are commitments and which are assumptions.