Calculating ERP ROI Before You Sign: A Worked Example

"It'll pay for itself" is not a business case. If you're taking an ERP proposal to a CFO or a board, you need three numbers: what the system will cost in total, what it will save or earn each year, and how long you're planning to run it. From those three inputs you can calculate a payback period and an ROI percentage that stand up to scrutiny.

The three inputs

Take a mid-market distributor evaluating a new ERP platform. The finance and operations teams have worked through the business case together and landed on three defensible figures:

• Total investment: $650,000 — licence, implementation, training, and first-year maintenance, all in.
• Annual benefit: $150,000 — a conservative sum of specific, itemized gains: 4 fewer hours of manual order entry per day company-wide, a 1.5% reduction in inventory carrying cost from better demand planning, and elimination of a part-time reconciliation role in finance.
• Horizon: 5 years — the period over which the company expects to run this system before the next major platform decision.

Running the numbers

The math is simple once the inputs are defensible:

Total benefit over 5 years: $150,000 × 5 = $750,000
Net benefit: $750,000 − $650,000 = $100,000
ROI: $100,000 ÷ $650,000 × 100 = 15.4%
Payback period: $650,000 ÷ $150,000 × 12 = 52 months (about 4 years, 4 months)

That's a real answer, and it's a modest one — a 15.4% return over five years with payback in year four is a project that needs a genuine reason to proceed beyond "the old system is annoying." It might be that reason exists (an unsupported legacy platform, a compliance deadline, a competitor pulling ahead on fulfillment speed) — but the ROI math alone doesn't sell this project on cost savings. You can run the same calculation with your own figures using the ERP ROI calculator.

Where the annual benefit number actually comes from

The credibility of an ROI case lives entirely in how the annual benefit figure was built. "Improved efficiency" is not a number anyone can defend in a budget meeting. Break it into line items that can each be measured before and after go-live:

• Labor hours saved on specific manual tasks (order entry, reconciliation, report building), multiplied by a fully-loaded hourly rate
• Reduced inventory carrying cost from better demand planning and fewer stockouts/overstocks
• Faster financial close, quantified as staff hours freed up or, for a public or PE-backed company, the value of earlier visibility into results
• Reduced error rates — fewer pricing mistakes, shipping errors, or duplicate payments — each with a rough cost per incident and a frequency
• Headcount avoidance: growth the company can absorb without adding staff, valued at the salary that wasn't hired

Sum the defensible items only. Leave out soft benefits like "better visibility" or "improved morale" unless you can put a number on them — they may be real, but they don't belong in a payback calculation a CFO will hold you to.

Why total investment needs to be the full figure, not the licence price

Using just the licence cost as "total investment" is the single most common way ERP ROI calculations get inflated. Use the full total cost of ownership figure — licence, implementation, training, and at least the first year of maintenance — as your investment number. A $650,000 all-in investment producing $100,000 of net benefit over five years is a very different story than a $180,000 licence fee producing the same $100,000, and only one of those stories is honest.

Sensitivity: what happens if benefits come in lower

Before presenting a single number, run the calculation twice more: once assuming benefits land at 70% of your estimate, and once at 130%. If the 70% case still shows a payback period the business can live with, you have a resilient case. If it turns negative, you've found the assumption the whole project hinges on — usually the labor-savings line — and you know exactly what to validate more carefully before committing budget.

What happens when the numbers don't clear the bar

Not every ERP business case should proceed just because someone built a model. If your payback period comes out at 6+ years and your company typically re-evaluates major software platforms every 4-5 years, the honest conclusion is that the project doesn't pay for itself inside its own useful life — and that's a legitimate reason to either shrink the investment (a phased rollout, fewer modules at launch), find additional defensible benefit lines you missed on the first pass, or table the decision until a forcing function (end of vendor support, a compliance deadline) changes the calculus. Presenting a marginal or negative ROI case honestly, with a recommendation attached, is more useful to a CFO than presenting only the version of the numbers that clears an internal bar.

A second worked example: when the case is stronger

Compare the mid-market distributor above to a services firm facing a forced migration — its current platform's vendor announced end-of-life support in 18 months, and staying on an unsupported system carries real security and continuity risk that has its own (harder to quantify but real) cost. Here, total investment is $420,000, annual benefit is a more conservative $95,000 (this company was more cautious in its estimates), and the horizon is 4 years to align with typical contract terms:

Total benefit: $95,000 × 4 = $380,000
Net benefit: $380,000 − $420,000 = −$40,000
ROI: −$40,000 ÷ $420,000 × 100 = −9.5%

This case shows a negative ROI on cost savings alone — and that's fine, because the real driver isn't cost savings, it's risk avoidance from an unsupported legacy platform. The honest way to present this case is not to inflate the annual benefit number until the ROI looks positive, but to present the negative cost-savings ROI alongside the qualitative (and where possible, quantified) cost of the alternative: continuing to run unsupported software, the security exposure that creates, and the eventual forced migration that will happen anyway, likely under worse time pressure. A CFO can approve a negative-ROI project when the alternative's risk is made explicit — they generally can't evaluate a case that pretends the ROI is positive when it isn't.

Keeping the model honest after go-live

Revisit the actual benefit realized 12 months after go-live against what was modeled. Most companies never do this, which means the same overly optimistic assumptions get reused uncritically for the next major software decision. A post-implementation review that says "we modeled $150,000 in annual benefit and captured $110,000" is uncomfortable to present, but it makes every future business case in the organization more credible, including yours.

Frequently asked questions

What ROI percentage is considered "good" for an ERP project?

There's no universal threshold — a 15% five-year ROI might be a clear yes for a company facing a forced platform migration and a clear no for one with abundant, cheaper alternative uses for the same capital. Compare the ROI to your company's typical hurdle rate for capital projects, not to a generic industry benchmark.

Should annual benefit be measured in year one or held constant across the horizon?

Most realistic models phase benefit in — minimal or even negative productivity in the first few months post-go-live as staff adapt, ramping to the full modeled benefit by month 9-12. Using the full annual figure starting in month one, as the simplified worked examples in this guide do, is a common simplification for a first-pass business case, but a more precise model should discount year-one benefit to account for the adoption curve.

Does ROI calculation change for a cloud subscription versus a perpetual licence?

The formula is identical — total benefit minus total investment, divided by total investment — but "total investment" for a subscription should include the full multi-year subscription cost across your chosen horizon, not just the first year's fee, the same way the TCO calculator treats multi-year maintenance for an on-premises system.