Why SAP projects go over budget and how to stop it

SAP projects go over budget mostly because companies try to keep the cost low at the start, then get hit in the Explore phase, when fit-to-standard workshops show the real scope. In the programmes I have reviewed, overruns of 40 to 60 percent are common.

Short answer: an SAP budget overruns when it was set before anyone knew the scope, and when the vendor rather than the client controls that scope. Watch the WRICEF count during the Explore phase, own the scope yourself and hold 10 to 20 percent contingency on your side.

Survey averages look calmer. Panorama Consulting's 2026 ERP Report found that more than a quarter of organisations exceeded their ERP budgets, with additional technology needs the leading cause. Survey averages and the programmes that end up in front of an adviser are different populations, so plan for the second.

40-60%

budget overrun I commonly see on the SAP programmes I review

Source: Noel D'Costa, published observation

This article is about the overrun, not the starting number. For cost ranges by company size, where the money goes, day rates and a budget formula, read my guide to how much SAP implementation costs.

Across 21 SAP programmes I have led or rescued, the same causes come back. Most of them are visible before the contract is signed.

1. The budget is set low, then Explore shows the real scope

This is the most common reason I see. Companies try to keep the cost low at the start, often because the business case needs a number the board will approve. Then the Explore phase arrives.

In SAP Activate, Explore is where fit-to-standard workshops test SAP's standard processes against how the business actually works (SAP Learning). Every gap found there becomes a backlog item: a report, an interface, a conversion, an enhancement, a form or a workflow. None of them was in the original price.

The budget was not wrong because someone made a calculation error. It was wrong because it was set before the scope existed. If you can, run a short fit-to-standard assessment before you approve the final number.

2. The vendor controls the scope

The biggest cost mistake I see before signing is allowing the vendor to control the scope. When the system integrator writes the scope, the scope describes what the integrator plans to deliver, not what the business needs.

The gaps surface later as change requests, and every change request is priced by the same vendor. Write the scope yourself, or have someone independent of the implementation write it with you.

3. Scope changes without cost control

One retail chain budgeted $5M and finished at $12.3M. Poor requirements gathering led to constant scope changes. Midway through, it found its inventory processes didn't match SAP standard functionality, and extensive customisation followed.

It had also underestimated data migration from its legacy systems. Aligning processes to standard in design would have been far cheaper.

4. Timelines set by executive pressure

One global manufacturing programme went 143% over budget ($14M against $5.8M planned) and launched 11 months late. The causes: unrealistic timeline pressure from executives, an understaffed internal team, too many modules at once, and a lowest-cost partner without industry expertise.

Cheaper is not automatically better. A client who chose the lowest-cost implementation option ended up spending 30% more fixing issues a more experienced team would have avoided.

5. Part-time internal people

Programmes that assign part-time representatives instead of dedicated process owners lose days on every decision. The understaffed internal team on that global manufacturing programme was one of the reasons it ran 11 months late.

Your best people will be half or more committed to the programme for months. Neither their time nor the slowdown around go-live appears in a vendor quote.

6. Data found late

Data problems discovered in pre-production are the most expensive kind. Profiling should run alongside requirements, not after configuration. Three months of cleanup under live-system pressure is consistently the largest cost-of-delay items on overrun programmes.

I explain how a wrong bill of materials sinks SAP budgets in this video.

The clearest early warning sign is the Explore phase itself. Watch the WRICEF count: reports, interfaces, conversions, enhancements, forms and workflows. If that list keeps growing workshop after workshop, the budget is already behind the scope.

The signs below each point to one of the causes above. Most can be checked in a weekly programme review.

Warning sign	What it usually means	What to do
WRICEF count growing through Explore	Real scope is larger than the priced scope	Re-baseline the budget at the end of Explore, before Realize starts
Gaps closed by "build it" by default	Standard processes are not being challenged	Ask the business owner to justify each gap against standard
Scope documents drafted by the system integrator	The vendor controls what gets priced	Take ownership of scope and review it with someone independent
Change requests reviewed monthly or not priced	Small changes compound unseen	Price every change request and review them weekly
Data profiling not started by the end of Explore	Data issues will surface in testing or cutover	Start profiling now, alongside requirements
Key users still part-time	Decisions slow and rework grows	Backfill their day jobs or move the timeline

Each of these addresses one of the causes above. The stories are from programmes I worked on or reviewed.

1. Own the scope. Write it on the client side, freeze it at the end of Explore and treat every later change as a priced decision, not a workshop note.
2. Adopt standard processes. Every customisation costs twice: to build, then at every upgrade. One manufacturing client saved over $800K by adapting its processes to SAP standards rather than customising. It was painful for some departments, but the financial difference was massive.
3. Phase the rollout. A retail client saved $1.2M by splitting its rollout into three phases over 18 months instead of doing everything at once. Initial investment dropped 40%, and lessons from phase 1 made the later phases faster.
4. Pay for expertise, not a low day rate. A chemical company client switched from a general SAP partner to an industry specialist and spent 20% less overall despite higher hourly rates. Specialists worked faster and made fewer mistakes.
5. Hold contingency on your side. Keep 10 to 20 percent on top of the budget, released only against named risks. Contingency inside the partner's price gets spent on the partner's priorities.
6. Review change requests weekly. Price each one for budget and schedule impact before it is approved, not at month-end.
7. Automate regression testing. Tools such as Tricentis Tosca or SAP's own test automation pay back on any programme that runs more than two test cycles, and every upgrade after go-live is another cycle.

For the commercial side, my SAP licence negotiation checklist and contract cost review for CFOs cover what to push on before you sign.

The subscription model moves spend from capital to operating expense. It does not remove the overrun risk, but it moves where the risk sits.

GROW with SAP runs on S/4HANA Cloud Public Edition, which only allows extensions through released interfaces. That limits how far the WRICEF list can grow, and GROW programmes often take about 6 to 9 months. The trade-off is less freedom to fit SAP to unusual processes.

RISE with SAP runs on S/4HANA Cloud Private Edition, where you can still modify the core. Clean core is a governance decision there, not a technical limit, so the Explore-phase risk is the same as on-premise. RISE programmes typically take 9 to 18 months, and the multi-year subscription term has to be visible in the business case.

AI is a new budget line, not a saving to bank. Some Joule capabilities come with SAP cloud subscriptions, while premium AI capabilities are priced separately. Ask for the productivity assumption behind any partner rate card that claims AI savings.

This matters for how a large programme hits the income statement. Under IFRS and US GAAP, costs of building an asset you control can be capitalised; costs of operating, training and preparing can't. Cloud changes the answer for a big slice of the budget.

Cost element	On-premise licence	Cloud subscription (RISE / GROW)
Licence or subscription fees	Capitalise as intangible asset	Expense over the term (service contract)
Configuration and build services	Capitalise if directly attributable	IFRS: often expensed, unless they create a separate asset you control. US GAAP: capitalise implementation costs and amortise over the hosting term
Internal labour on build	Capitalise if directly attributable	Same split as above
Training and change management	Expense	Expense
Data cleansing	Expense	Expense
Data conversion tools you keep	Capitalise if reusable	Assess case by case
Hypercare and support	Expense	Expense

The IFRS position comes from the IFRS Interpretations Committee's 2021 agenda decision on configuration and customisation costs in cloud computing arrangements. The US GAAP position comes from ASU 2018-15. Under IFRS especially, a RISE business case that assumes on-premise capitalisation can overstate year-one profit materially.

Documentation decides how much you keep. A manufacturing client saved $2.3M in current-year expenses by capitalising properly, because it tracked consultant activities meticulously enough to defend the approach. Another client faced a painful restatement because it couldn't substantiate its capitalisation decisions.

Auditors look hard at large capitalised projects. Agree the policy with them before the programme starts, not at year end.

Most overrun programmes did not have a planning failure. They had an honesty failure at the planning stage. A CFO who approves a realistic plan with proper contingency spends less than one who approves a hopeful plan with none.

Why do SAP implementations go over budget?

Most often because the budget is kept low at the start, then the Explore phase shows the real scope. Fit-to-standard workshops turn gaps into reports, interfaces, conversions, enhancements, forms and workflows that were never priced. Vendor-controlled scope, part-time internal teams and late data work make it worse.

How much do SAP projects typically go over budget?

In the programmes I have reviewed, overruns of 40 to 60 percent are common. Panorama Consulting's 2026 survey found that more than a quarter of organisations exceeded their ERP budgets. Programmes that reach an adviser tend to be the troubled tail of that population.

What are the early warning signs of an SAP budget overrun?

The clearest sign is a WRICEF count that keeps growing through the Explore phase. Others are scope documents drafted by the vendor, change requests that are not priced weekly, data profiling not yet started and key users still working part-time. Re-baseline the budget at the end of Explore if the list has grown.

How do you stop scope creep on an SAP project?

Own the scope on the client side rather than letting the system integrator write it. Freeze it at the end of Explore, challenge every gap against standard SAP and price each change request before approving it. Review change requests weekly, not at month-end.

Does RISE with SAP reduce the risk of going over budget?

Not by itself. RISE runs on Private Edition, where the core can still be modified, so the Explore-phase risk is the same as on-premise. GROW with SAP on Public Edition limits extensions to released interfaces, which narrows how far the scope can grow.

Can you capitalise RISE with SAP implementation costs?

Partly, and it depends on your accounting framework. The subscription itself is normally expensed. Under IFRS, configuration and customisation services in a SaaS arrangement are often expensed too, unless they create a separate asset you control; under US GAAP (ASU 2018-15), implementation costs are capitalised and amortised over the hosting term.