An executive ERP business case compares your current situation with the options in front of you, using a baseline cost, a benefits list that named owners will sign, a three-year cost forecast across low, base and high growth scenarios, and a risk-adjusted contingency. The forecast is a range built from cost categories and scope, never one number.
Our guide to ERP total cost of ownership gives the formulas for comparing licensed and custom systems over three and five years. This guide sits one step earlier: how to turn those formulas into a business case a board can approve, who should write it, how to forecast across growth scenarios, which exceptions to stress-test and what a proof of concept must prove. Where we show numbers, they are labelled illustrative and contain no vendor or Timeline prices.
Key takeaways
- A business case needs a baseline. Without the cost of the current way of working, every option looks like pure spend.
- Count only benefits that a named manager will own in the budget. Everything else is upside, not case.
- Forecast cost by category and by driver (users, entities, sites, transactions, integrations), then run low, base and high growth scenarios.
- Test exception scenarios before approval: an acquisition, a delayed go-live, a vendor price change, a regulation change and poor data quality.
- A proof of concept for cost validates effort assumptions on your hardest processes, not a demo on easy ones.
- A budget range for proposals comes from scope. Brief two or three vendors on the same scope and compare their sizing, then add contingency.
Who should we hire to create the business case, roadmap and delivery plan?
Hire for independence on the business case and for delivery experience on the plan. Use an internal finance lead as owner, a vendor-neutral ERP advisor or experienced implementation lead for options and roadmap, and the shortlisted delivery partners for the delivery plan, so that the person pricing the work is not the person justifying it.
| Task | Best owner | Why |
|---|
| Baseline cost and benefits owners | Internal finance and operations leads | Only they can commit benefits to a budget |
| Options analysis and requirements | Independent advisor or senior internal lead | Neutral on which product or build wins |
| Roadmap and phasing | Advisor with delivery experience | Phasing is a risk judgement, not a spreadsheet |
| Delivery plan and estimate | Shortlisted implementation partners | They carry the delivery risk and must stand behind it |
| Governance and approval | Sponsor and steering group | Decisions need a named accountable executive |
Ask any advisor how they are paid. A consultant who receives referral fees from a vendor, or an implementation partner who writes the case for its own product, has a conflict that should be disclosed. Our guide to ERP consultants and ERP development companies explains the difference between the roles. If you are considering a custom ERP, ask for the build option to be costed in the same format as the packaged options.
What goes into an executive ERP business case?
Six sections, in this order: the problem and baseline, the options, the benefits, the cost forecast, the risks and the roadmap with a decision requested. Keep the document to a dozen pages plus an appendix, because executives approve what they can read in one sitting.
- Problem and baseline. What breaks today, measured: hours spent on manual reconciliation, stock write-offs, late closes, audit findings, lost sales from stock errors. Use your own figures.
- Options. Do nothing (with its real cost), upgrade or extend the current system, replace with a packaged or cloud ERP, build custom, or a phased hybrid.
- Benefits. Split into hard (cost removed from a budget line, revenue protected), soft (time freed that is not redeployed) and risk (control failures avoided). Count only hard benefits in the case.
- Cost forecast. Three years, by category, across scenarios, as below.
- Risks and mitigations. The top ten with owners; see the exception scenarios later.
- Roadmap and decision. Phases, gates and the specific approval you want today.
Which cost categories belong in a three-year forecast?
Include every category, even where the figure is an estimate with a range. Missing categories cause most budget overruns because they are not on any proposal: internal staff time, data migration, integrations, training and exit costs sit outside the vendor's quote.
| Category | Includes | Typical driver |
|---|
| Software | Licences or subscription, add-ons, hosting for custom builds | Users, entities, modules |
| Implementation services | Configuration or build, project management, testing | Scope, customization, number of processes |
| Data migration | Cleansing, mapping, trial loads, reconciliation | Data condition, history window, records |
| Integrations | Build, test, ongoing change | Number of systems and their quality |
| Training and change | Materials, trainers, backfill for staff time | Users, roles, sites |
| Internal staff | Project team time, key users, backfill | Duration, scope |
| Support and upgrades | Support plan, upgrade testing, small changes | Customization and release cadence |
| Contingency | Allowance for unknowns | Maturity of scope |
| Exit | Data export, parallel running, retirement of old system | Contract terms |
How should three-year costs for an executive ERP business case be forecast across growth scenarios?
Forecast by driver, not by percentage uplift: state how many users, entities, sites, transactions and integrations each scenario assumes, then see which cost lines scale. Three scenarios are enough: low (growth stalls), base (plan) and high (growth or acquisition). Show all three beside each other.
Illustrative worked example. Cost units below are not currency and not a quote; they show the method. Base scenario for a mid-sized distributor, with 10 percent contingency on each year's subtotal. The 10 percent is for the arithmetic only; set contingency from how mature your scope is.
| Line | Year 1 | Year 2 | Year 3 | Total |
|---|
| Software or hosting | 100 | 110 | 120 | 330 |
| Implementation services | 300 | 60 | 40 | 400 |
| Data migration and integrations | 80 | 20 | 20 | 120 |
| Training and change | 40 | 15 | 15 | 70 |
| Internal staff | 90 | 35 | 35 | 160 |
| Support and upgrades | 20 | 40 | 40 | 100 |
| Subtotal | 630 | 280 | 270 | 1,180 |
| Contingency (10 percent) | 63 | 28 | 27 | 118 |
| Total | 693 | 308 | 297 | 1,298 |
Now apply the scenario changes to the base lines. In the high scenario an acquisition in Year 2 adds users and entities. In the low scenario the second phase is deferred and user growth stalls.
| Scenario | Change to base (before contingency) | Three-year total |
|---|
| Low: growth stalls, phase 2 deferred | Software -30, implementation -40, migration -10, training -5, internal -10, support -5 = -100; contingency -10 | 1,188 |
| Base | None | 1,298 |
| High: acquisition in Year 2 | Software +100, implementation +70, migration +30, training +20, internal +35, support +25 = +280; contingency +28 | 1,606 |
The range, 1,188 to 1,606, is the figure to take to the committee, together with the drivers behind it. A single total hides the real question: which cost lines grow with the business, and which are fixed?
Which exception scenarios should be tested for total cost of ownership?
Test the events most likely to break the estimate, one at a time, and record the cost of each. A scenario list turns contingency from a guess into a reasoned number and tells the committee which risks deserve mitigation spend before approval.
| Exception | Question to answer | Cost lines it moves |
|---|
| Go-live slips one quarter | What does the old system, the team and the partner cost for that quarter? | Internal staff, implementation, software |
| Acquisition or new entity | Can it be added by configuration, or does it need a project? | Software, implementation, migration |
| User numbers double | How does pricing change at the next band? | Software, training |
| Vendor raises renewal price | What cap does the contract set? | Software |
| Regulation changes (tax, e-invoicing) | Who pays for the change and by when? | Support and upgrades |
| Data quality worse than expected | How many extra trial loads and cleansing hours? | Migration, internal |
| Key integration partner changes its API | Who maintains the interface? | Integrations, support |
| Rollback after go-live | What does re-opening the old system cost? | Exit, internal |
What would a practical proof of concept for total cost of ownership need to validate?
It must validate the assumptions that drive cost, using your real data and hardest processes. A good proof of concept builds two or three difficult processes end to end, loads a realistic data sample, connects one real integration and records the effort actually spent compared with the estimate.
Define success before it starts:
- Effort calibration. Hours to configure or build each process against the estimate. Use the ratio to correct the whole estimate.
- Data effort. How many defects the sample load revealed per thousand records, and how long fixes took.
- Integration effort. The real work to connect one live system, including error handling.
- Performance at scale. Response time and batch duration at the high-scenario volume.
- User effort. How long a trained user takes to complete a typical transaction.
- Support load. Questions and defects raised during the trial.
A proof of concept that shows a polished demo on clean data validates nothing about cost.
What budget range should I prepare when requesting proposals for a mid-sized custom ERP module?
Prepare a range built from scope, not a number borrowed from an article. Write a one-page brief listing the processes, roles, integrations, data to migrate and reports, ask two or three suppliers for a sizing range against the same brief, and add contingency for the gaps they find. Use their spread to judge scope clarity.
A practical sequence:
- List the processes in the module, the number of user roles, screens and reports, the integrations and the data to be loaded.
- Mark each item must have, should have or later, so vendors can size phase 1.
- Ask each supplier for a range and the assumptions behind it, not just a total. See our guide to what drives custom ERP development cost.
- Compare assumptions line by line. A low price that assumes your staff do the migration is not cheaper.
- Add an allowance for the exceptions above and for internal time.
If scope is unclear, budget for a paid or pilot discovery step first and set the main budget after it. Our guide on how to write ERP requirements vendors can price helps with the brief.
When is a full business case the wrong approach?
A three-scenario model is heavy for a small decision. If you are replacing one tool, the spend is small or a legal deadline leaves no alternative, a one-page comparison is enough. A detailed forecast also misleads when requirements are not yet understood, because false precision binds vendors to ungrounded numbers. Fund discovery first and write the case afterwards.
Glossary: baseline, the measured cost and performance of today's process; contingency, an allowance for unknown costs, set by scope maturity; proof of concept, a limited build on real data that tests assumptions.
How Timeline Digital approaches this
A business case is only as firm as the scope behind its cost lines. Timeline Digital, founded in Islamabad in 2013 and delivering remotely, sets schedules from your requirements in the Plan step. We build a free pilot of two to three key modules that your team tests before the final agreement, which can give you real effort data for a proof of concept. The code transfers to you on full payment. See our ERP implementation services.