How to Build the Business Case for an ERP
How to work out what your manual process costs, which savings are credible, which costs you must include, and how to present a payback figure that survives scrutiny.
What to put in front of whoever signsFIG.01
Short answer
A credible ERP business case measures four things: staff hours lost to re-entry and reconciliation, the cost of errors you can actually name, working capital tied up in excess stock, and sales lost to slow response. Set those against the full cost — build, migration, training, the productivity dip and annual running cost — and present a payback period in months, using your own figures rather than vendor averages.
Key takeaways
- Use your own numbers. A business case built on published industry percentages is the first thing a sceptical finance person dismisses.
- Count reconciliation hours, not data entry hours. That is where manual systems actually cost money.
- Include the productivity dip during rollout. Leaving it out is what makes a case look naive.
- Working capital tied up in excess stock is usually the largest single number, and the one most often left out.
- Promise the operational changes confidently and the financial ones conservatively.
At some point somebody has to sign. Whether that is you, a board or a family shareholder, the conversation goes better with four or five defensible numbers than with a description of how frustrating the current situation is.
This is how to build that case with figures you can source from your own business this week.
Who you are actually writing for
The person approving this is not asking whether the software is good. They are asking three things: what does it cost in total, when does the money come back, and what happens if it does not work.
A case that answers those three plainly, including the third, is more persuasive than one that only lists benefits. Acknowledged risk reads as competence.
The four places the money actually is
1. Hours lost to re-entry and reconciliation
Not data entry. Reconciliation — the time spent establishing which of two records is correct. Pick your three busiest workflows, ask the people running them how long they spend each week checking one record against another, and multiply by your loaded salary cost.
Be conservative. If somebody says two hours a day, use one. A case that survives someone halving your assumptions is a case that gets approved.
2. Errors you can name
Go back through the last three months and find the specific incidents: the wrong quantity that went out and came back, the invoice raised at an old price, the order that was never dispatched. Use only ones you can point to. Three named incidents with real costs are worth more than any estimated error rate.
3. Working capital sitting in stock
This is usually the largest number and the one most often missing. When nobody trusts the stock figure, purchasing buys a safety margin on top of a safety margin. Compare what you hold against what you sold over the same period. The excess is cash sitting in a warehouse, and improving stock accuracy releases a good portion of it.
4. Sales lost to slow response
The hardest to evidence, so keep it modest. Count the quotations from last quarter that went out more than two days after the enquiry, and the enquiries nobody answered. Do not claim you would have won all of them. Claim a fraction you would defend out loud.
The costs you must include
Leaving any of these out is what makes a business case collapse under questioning.
| Cost | Often forgotten? | Notes |
|---|---|---|
| Build or licence | No | The number everybody focuses on |
| Data migration and cleanup | Yes | Depends on how messy your current records are |
| Integration with existing tools | Sometimes | Accounting software, marketplaces, couriers |
| Training and documentation | Yes | Including the second round three months later |
| Productivity dip during rollout | Almost always | Assume reduced output for several weeks |
| Internal time | Yes | Your team's hours in mapping, testing and training |
| Annual running cost | Sometimes | Hosting, support, changes as the business changes |
The two that matter most for credibility are the productivity dip and internal time, because they are the ones an experienced approver will ask about. Raising them yourself is far better than being asked. What custom software costs after launch covers the running side in more detail.
Putting it together
Building the business case
Establish the annual cost of the present arrangement
Add the four benefit categories as annual figures, using conservative inputs from your own business. This is the number the whole case rests on, so every line must be traceable to something real.
Establish the total first-year cost
Every row of the table above, not just the quotation. Add a contingency and say what it is for rather than hiding it inside another line.
Establish the ongoing annual cost
Year two onwards: running, support and change. This is what turns a one-off number into a decision about the next few years.
Calculate payback in months
First-year cost divided by monthly benefit. Present it as a range, not a single figure — the honest answer is always a range.
Halve the benefits and show it again
Show the payback if you achieve only half of what you projected. If the case still works, you have answered the hardest question before it is asked.
Name what happens if it goes badly
Which phase you would stop at, what you would still have, and what would be written off. Approvers rarely expect certainty; they expect you to have thought about it.
Numbers not to use
- Vendor averages and industry percentages. "Companies typically see a 20% improvement" invites the reply that you are not a typical company, and you will lose that exchange.
- Anything you cannot trace to a document or a person. If you cannot say where a figure came from, remove it. One unsupported number puts every other number in doubt.
- Headcount reduction, unless you genuinely mean it. Most businesses redeploy rather than cut. Promising savings you will not take is how a successful project gets recorded as a failure.
- Benefits arriving in month one. Response time and stock visibility change early; reliable reporting does not. Phasing the benefits makes the case more credible, not less.
Phase the spend so the first stage funds the second
The strongest version of this case is not a single large request. It is a first phase, sized around the workflow with the most re-entry, with a defined measurement at the end and the second phase conditional on that result.
That structure is easier to approve, and it protects you: if the first phase disappoints, you stop having spent a fraction, with one workflow improved and something learned. ERP implementation roadmap sets out how those phases are normally sequenced, and ERP modules explained covers which part to put in the first phase.
What to promise
| Claim | How confident to be |
|---|---|
| Everyone sees the same order status | Certain — this follows directly from one record |
| Faster customer response | Confident — visible in the first month |
| Fewer errors from copying | Confident — that class of error disappears |
| Better stock accuracy | Likely, if returns and adjustments are actually entered |
| Lower stock holding | Likely over a few months, once accuracy is trusted |
| Higher sales | Possible — do not build the case on it |
| Lower headcount | Only if you actually intend to |
The first three rows are enough to justify most projects on their own. Everything below them strengthens the case; nothing below them should be load-bearing.
If you want the numbers checked
We are asked to sanity-check these cases regularly, including ones where our answer is that the project should wait. If you have drafted the figures and want them tested before they go to whoever signs, send us what you have — it is a short conversation and considerably cheaper than discovering the gap afterwards.
Frequently asked questions
How do I calculate ROI on an ERP?
Add the annual cost of your present arrangement — reconciliation hours, named error costs, excess stock and quantifiable lost sales — then divide the full first-year project cost by the monthly benefit to get payback in months. Use your own measured figures, present the result as a range, and show the same calculation with the benefits halved.
What is a realistic payback period for an ERP?
It depends entirely on how much manual reconciliation you are doing today and how much capital is tied up in stock, so any general figure is guesswork. The useful exercise is calculating it from your own numbers and then testing whether the case still holds if you achieve only half of what you projected.
Our management wants proof before spending anything. What can we show them?
Measure one workflow properly. Take your busiest process, count the re-entries and reconciliations for a fortnight, and price them at your own salary cost. A single measured workflow is more persuasive than a full projection, and it is also the natural scope for a first phase.
Should the business case include the cost of doing nothing?
Yes, and it is usually the strongest section. Staying manual is not a zero-cost option — it has an annual price you can calculate from the same four categories. Framing the decision as a choice between two costs rather than between spending and not spending changes the conversation considerably.
What if we cannot get accurate figures for the current process?
That difficulty is itself part of the case, but do not let it stop you. Measure a two-week sample of one workflow rather than attempting to estimate the whole business, use conservative inputs, and state your assumptions openly. An approver will accept a clearly labelled assumption far more readily than a confident number with no source.
/Services in this article
/ERP & CRM Systems by country
Keep reading
All articlesManual Systems vs ERP: What Actually Changes in a Working Day
A side-by-side look at five everyday workflows — sales orders, stock, invoicing, month-end and customer queries — run manually and run on a system, including what an ERP does not fix.
ERP Software in Pakistan: A Practical Buyer's Guide
How to evaluate ERP options for a Pakistani business — what to insist on, what to ignore in a demo, and how to avoid buying a system your team will not use.