🧮 ERP Business Case Calculator
Every other calculator here adds nominal dollars across the horizon, as if a dollar in year seven were a dollar today. No capital committee does — and the error is not noise, it points one way.
Undiscounting is a bias, not a rounding error
The TCO calculator on this site adds maintenance times years to an up-front cost. The ROI calculator multiplies an annual benefit by the horizon. The cloud-versus-on-premise calculator sets capital plus running cost against a monthly fee over the same period. Each is arithmetic you can check, and each treats money as if it had no time value.
That would be a harmless simplification if it erred in both directions. It does not. Discounting penalises whichever option pays later, so the undiscounted comparison always flatters the one that pays sooner, and always makes payback look earlier than it is. An ERP decision is very often precisely a choice about when to pay — licence against subscription, capital against operating — which is the one question the simplification is worst at.
The second half is the benefit curve. A cash flow that starts at the full promised rate on the day of go-live describes no implementation that has ever happened. Output drops while people learn the system, recovers to where it was, and only then climbs. Put that shape in and the early years carry cost without the benefit that justifies them — which is exactly the period the discount rate weighs most heavily.
None of this makes an ERP programme a bad idea. Plenty clear a hurdle rate comfortably. The point is that a programme which clears it and a programme which does not look identical on an undiscounted sheet, and the sheet is what gets approved.
❓ Frequently Asked Questions
Why does discounting change an ERP decision rather than just trimming it?
Because the error has a direction. Discounting always penalises whichever option pays later, and an ERP decision is usually a choice between paying up front and paying over time — perpetual licence against subscription, on-premise against cloud. Add the two undiscounted and the spread-out stream is credited at face value, so the comparison quietly favours the front-loaded option and moves the year the two cost curves cross. That crossover year is often the single figure the decision turns on, which means the undiscounted answer is not a rougher version of the right answer; it can be the opposite one.
What is wrong with the ROI percentage the other calculator prints?
Nothing, as arithmetic — it is cumulative net benefit over investment, correctly computed. The problem is that it is not a rate, and it gets compared with rates. A programme showing 45% over seven years reads like a good investment, and it is about 5% a year, which sits under the hurdle rate the same company applies to every other use of the same money. Nobody does that conversion because the tool does not offer it, so a cumulative percentage gets carried into a meeting where everything else on the slide is annual. This page prints both figures side by side for exactly that reason.
Why model a dip after go-live? Isn't that pessimistic?
It is the best-documented phenomenon in enterprise software implementation, and leaving it out is not neutral — it is optimistic. People are learning a new system while doing their existing jobs, so output falls before it rises. The ROI calculator's payback formula assumes the full promised benefit runs from the first month, which is the one thing that certainly does not happen. Here the depth of the dip, how long it lasts and how long the climb to full rate takes are all inputs, with no defaults, because yours are not ours. Set all three to zero and this page agrees with the ROI calculator exactly.
The payback period here is later than the other calculator's. Which is right?
They answer different questions, and one of them has a flaw worth knowing about. The ROI calculator divides the whole investment — up front and ongoing, as its own page defines the field — by one year's benefit. That makes the answer depend on the horizon you typed: model the same system over ten years instead of seven and its payback gets a year later, on cash flows that did not change at all. A payback period is a property of the cash flows and cannot depend on how far ahead you chose to look. The figure here is the year the cumulative discounted cash flow actually turns positive.
What discount rate should I use?
Your own, and you almost certainly already have one. Most organisations have a weighted average cost of capital or a hurdle rate that finance applies to capital requests, and using anything else here makes the answer incomparable with every other proposal competing for the same money. If nobody can tell you the number, that is worth discovering before the business case goes in rather than after. This page deliberately ships no default rate, because a default would be a figure we invented standing in for one you can simply ask for.
Does this tell me whether to buy the system?
No, and it should not. It is arithmetic on assumptions you supplied: if the benefit figure is wishful, a discounted wishful number is still wishful. What it does is stop the arithmetic itself from flattering the case, which is a different and smaller claim. Strategic reasons to replace an ERP — a vendor ending support, an acquisition, a regulatory change — do not show up in a cash flow at all, and a negative net present value does not automatically settle those. It just means the financial case is not the reason.