How to build an ERP ROI business case a CFO will approve

Most ERP ROI business cases fail in the same place. Not on the total, and not on the discount rate — on a single line that says something like "productivity improvement: $340,000" with nobody's name against it. A CFO reads that line, understands that no budget will actually shrink and no headcount will actually go, and quietly reclassifies the whole document as advocacy. Everything below is about not writing that line.

ERP ROI business case

A financial appraisal of an ERP investment that sets quantified, owned benefits against the full cost of delivery and ownership, over a stated period, discounted at the organisation's own cost of capital. Its output is three numbers — payback period, return on investment, and net present value — plus the sensitivity that shows how fragile they are.

Benefit categories that survive scrutiny

A benefit survives if you can answer three questions about it: what is the number today, who controls it, and what will visibly change when the benefit lands. Categories that pass:

And the ones that get laughed out of the room, every time:

• "Improved productivity" with no hours behind it. If you cannot say whose week gets shorter, it is not a benefit.
• "Better decision making." Real, unquantifiable, and instantly fatal to the credibility of the lines around it. Put it in a separate qualitative section and claim nothing for it.
• Revenue growth attributed to the ERP. Sales grow for many reasons. Claiming a percentage of revenue invites the finance team to audit your attribution, and they will win.
• Full-time-equivalent savings with no reduction in anyone's plan. If forty recovered hours a week is one FTE and no one leaves, the benefit is capacity, not cost. Say capacity, and value it at zero unless a specific hire is cancelled.
• Risk avoidance with an invented probability. "A 15% chance of a $2M compliance failure" is a number you made up multiplied by a number you made up.

A worked example

A distributor with $42M of credit sales and $6.4M of average inventory. These are illustrative figures to show the shape of the model — your own baseline measurements and your own vendor quote go in their place. Steady-state annual benefits:

Costs: $410,000 of one-off implementation in year 0 — external services, migration, integrations, internal time and contingency — plus $96,000 a year of subscription and support. The ERP implementation cost estimator breaks the one-off figure into the lines a systems integrator will quote, and what does an ERP implementation cost explains which of them usually overrun.

Now the ramp. Benefits do not arrive on go-live day. A 40% / 85% / 100% realisation curve across the first three years is a defensible assumption and, more importantly, it is an assumption you have stated.

Read those last two together, because that pair is the whole reason to do this properly. On a three-year window this project has a negative net present value. On a five-year window it returns $228,400. Both are true. If you present the five-year number without volunteering the three-year one, and your CFO's default appraisal window is three years, you have lost the room and you will not get it back.

Payback and NPV mechanics

Payback is where cumulative net cash flow crosses zero. At the start of year 3 the cumulative position is −$200,625 and year 3 generates $225,100, so the crossover happens 200,625 ÷ 225,100 = 0.89 of the way through, which is 10.7 months into year 3 — month 35.

NPV = Σ (net cash flow in year n ÷ (1 + r)^n) − initial investment

Year 1:  32,440 ÷ 1.100   =  29,491
Year 2: 176,935 ÷ 1.210   = 146,227
Year 3: 225,100 ÷ 1.331   = 169,121
Year 4: 225,100 ÷ 1.4641  = 153,746
Year 5: 225,100 ÷ 1.61051 = 139,769
                            -------
Present value of flows      638,354
Less initial investment    (410,000)
NPV at 10%                  228,354

Two mechanics that get fudged. Use the organisation's own discount rate — ask the finance team for the hurdle rate they apply to capital projects, and use that even when it hurts. Do not discount the one-time cash release into the NPV as if it were profit. Releasing $972,000 of working capital is genuinely valuable, but it is a balance-sheet movement; the profit-and-loss benefit is only the carrying and financing cost you no longer pay on it. Double-counting that line is the most common arithmetic error in ERP business cases, and it is the one a CFO spots in ten seconds.

Sensitivity: the part that earns trust

A single point estimate reads as advocacy. A range with a stated break-even reads as analysis. Flex the two inputs that actually matter — how much of the benefit lands, and when.

That 77% figure is the most useful sentence in the document: this case breaks even if we deliver 77% of what we have claimed. It converts an argument about optimism into a monitorable commitment, and it forces you to look hard at which lines carry the case. Here, the analyst hire and the inventory carrying saving are 65% of the benefit stack between them — so those two are what the steering committee should track, not the reporting hours everyone finds easiest to talk about.

Building the ERP ROI business case, step by step

1. 01

   Write the decision you are asking for, in one sentence

   "Approve $410,000 of capital and $96,000 of annual operating cost to replace the current system, starting in Q1." If the first page does not contain that sentence, the reader spends the whole document guessing at scope.

2. 02

   Measure the baseline instead of estimating it

   Two weeks of actual time logs for the reporting hours. The real credit-memo count from the system. Actual average inventory from twelve month-end balances. A baseline you measured survives challenge; a baseline you estimated becomes the whole discussion.

3. 03

   Build the benefit stack line by line, by category

   One line per mechanism, each with its own arithmetic shown. Never aggregate two mechanisms into one line — aggregation is where unquantifiable benefits hide, and reviewers know it.

4. 04

   Put a name against every line and get them to sign it

   Walk the inventory line to the supply chain manager and ask them to accept an 8% reduction target. If they will not, either the number is wrong or the mechanism is missing. Both are better discovered now. An unsigned line comes out of the case.

5. 05

   Apply a recovery percentage below 100% and defend it

   Recovering 60% of reporting hours is credible. Recovering 100% means nobody ever checks a number again. The percentage is where your judgement is visible, so state the reasoning next to it rather than burying it in a footnote.

6. 06

   Cost the project fully, including your own people

   Vendor services, licence or subscription, integrations, data migration, training, infrastructure — and the internal person-months your team will spend. Internal time is real cost and it appears in no vendor proposal. Total cost of ownership across five years belongs here too; the ERP TCO calculator covers the recurring side.

7. 07

   Choose the appraisal window and the discount rate first

   Ask finance for both before you build a single cash flow. Choosing the window after seeing the answer is the one move that ends a business case's credibility permanently, and it is always detected.

8. 08

   Split one-time cash release from recurring P&L benefit

   Inventory and receivables improvements release cash once. The recurring benefit is the carrying or financing cost avoided on that release. Show the cash release as a separate, clearly labelled line and keep it out of the NPV.

9. 09

   Lay out year-by-year cash flows with a realisation ramp

   A 40% / 85% / 100% curve over three years, or your own shape if you can justify it. Show the ramp as an explicit row so a reviewer can argue with the ramp rather than with your integrity.

10. 10

    Compute payback, ROI and NPV, and show the arithmetic

    All three, in that order, with the discount factors visible. A reviewer who can reproduce your NPV in a spreadsheet in two minutes will trust the rest of the document.

11. 11

    Run sensitivity and publish the break-even realisation

    Flex benefit realisation and ramp timing. State the percentage of claimed benefits at which NPV reaches zero. Name the two or three lines that carry the case, because those are what the steering committee will actually govern.

12. 12

    Agree how benefits will be measured, before approval

    For each line: the metric, the current value, the target, the owner, and the review date. Attach it as an appendix and get it signed with the approval. A business case with no measurement plan is a promise nobody will ever be asked to keep — and the reason the next one is harder to get approved.

The reporting-hours line, honestly

Reporting labour is the line most business cases lead with, because it is the easiest to feel. It is also the easiest to overclaim. Count it properly with the reporting time savings calculator — people, hours per week, loaded hourly cost — then halve your instinct about how much of it goes away. The hours spent building a report shrink dramatically when someone can ask the question directly; the hours spent checking whether the answer is right do not, and should not.

That is worth being straight about, because it is the honest limit of any tool in this category, including ours. ERPray shortens the path from question to number — you ask in plain English and get an answer computed live from your own account, with the exact query shown so you can verify the definition rather than trust it. What it does not do is remove the need for someone who knows what the number should look like. Build your case on the hours that genuinely disappear, and on the working capital your own DSO and inventory numbers say is recoverable.