The buying workbook

ERP business case: separate cash savings from capacity

Build an ERP business case using documented baseline work, measurable outcomes, explicit benefit owners, and a transparent distinction between cash and capacity.

Updated · 5 min read

Keep benefit types distinct: CASH, CAPACITY, CONTROL.

An ERP business case should connect a documented operating problem to a measurable outcome and an accountable benefit owner. Separate cash savings from staff capacity, risk reduction, and service improvement. Do not claim a guaranteed return from an assumed percentage improvement or count the same benefit under several names.

Measure the baseline before forecasting improvement

Choose a process with a clear start, finish, and unit of work. For invoice handling, record volume, elapsed time, staff effort, exception rates, and rework. Use a representative period and identify unusual events. If the baseline is estimated from interviews, label it estimated and explain the method. A number becomes more useful when its limitations are visible, not when it is reported with extra decimal places.

Describe what the ERP change is expected to alter. Automated entry may reduce keystrokes without eliminating review or exception work. Better stock visibility may help purchasing decisions while requiring improved master data and process discipline. Connect the outcome to configuration, training, ownership, and adoption rather than attributing every improvement to software alone.

Classify benefits without inflating them

Benefit typeExampleEvidence needed
CashA service contract can be retiredCancelable agreement and timing
CapacityFewer hours spent rekeyingBaseline, test, and new work allocation
ServiceFaster status responseAgreed measure and owner
ControlBetter approval evidenceTested workflow and audit trail
Decision qualityMore usable inventory informationData quality and operating use

A capacity benefit is valuable even if it does not reduce payroll. Explain how the released time will be used or what extra workload it can absorb. Do not convert it into a cash reduction unless there is a credible spending decision behind the claim. Likewise, retiring an old application saves cash only after its contract, archive, and dependent interfaces can actually be closed.

Work through an illustrative time saving

Suppose a fictional team processes 1,200 transactions monthly and expects to save two minutes of manual work per transaction. The modeled release is 2,400 minutes, or 40 hours monthly. At an illustrative internal value of $35 per hour, that is $1,400 monthly of capacity value. It is not automatically $1,400 less payroll spending, and neither the time saving nor hourly value is an industry benchmark.

Test the expectation with representative transactions and include exceptions. If only 75% of transactions follow the automated path, the simple modeled release becomes 30 hours before considering any new administration. Record whether the remaining work shifts to another department. A benefit that removes entry work but adds equivalent reconciliation effort elsewhere should not be treated as a net saving.

Compare benefits against full cost and timing

Use the same scope and horizon as the cost ledger. Implementation, migration, training, parallel operations, recurring support, and internal capacity all affect the case. Benefits may begin after stabilization rather than on the subscription start date. Create a ramp based on operational milestones and evidence; do not assume full benefits from the first month because that improves the spreadsheet result.

If finance asks for payback or net present value, have it define the appropriate cash-flow method. Exclude noncash capacity from a cash-only calculation or show it separately. A simple payback figure can conceal a large initial funding need and benefits that depend on unproven adoption. Present the underlying schedule and sensitivity to the assumptions that matter most.

Assign owners and verify after launch

Each material benefit needs an owner, baseline, target, measurement method, dependencies, and review date. The owner should have authority over the process, not merely enthusiasm for the project. If the outcome depends on policy changes, supplier behavior, or customer adoption, state those dependencies. The project can deliver a capability while the business still has work to do to realize value.

After launch, compare actual outcomes with the baseline using consistent definitions. Investigate differences and distinguish software defects from process adoption or data quality issues. Keep unfavorable results in the record. A useful business case becomes a management tool, not a sales document that is abandoned once funding is approved. Have finance validate material monetary claims and avoid presenting illustrative arithmetic as a promise of return.

Approval worksheet

Before the funding decision, ask each benefit owner to explain how the claimed improvement will be measured and what action makes it possible. If the answer depends on a future policy change, staffing decision, or integration that is outside scope, identify that dependency explicitly. The sponsor should see which benefits are supported by tested capability and which are still hypotheses.

Create a post-launch review schedule linked to the first relevant operating cycles. Compare consistent measures and retain the baseline data. If the benefit does not appear, investigate adoption, data quality, process design, and new workload before blaming or crediting the software alone. Update the business case with actual outcomes and explain material differences. This closes the loop between the original purchasing rationale and operational management, while avoiding the temptation to redefine a metric after launch simply to make the result look successful.

FAQ

Is staff time a legitimate benefit?

Yes, when the baseline and expected change are credible. Show it as capacity unless a specific spending reduction or avoided hire supports a cash claim. Explain the intended use of released time.

Can better controls be assigned a dollar value?

Only with a defensible method and appropriate review. Avoid inventing a probability of failure or a loss amount to force a monetary result. Describe the control improvement and required evidence directly.

What if the project has no quick payback?

The organization may still need it for supportability or required capabilities. State that rationale openly, compare feasible alternatives, and avoid inflating benefits to meet an arbitrary financial threshold.

Sources

Continue the workbook

Use the ERP total cost calculator for your own scenario, the quote readiness checklist to track evidence, and the cost structure comparison to review purchasing models.

Related guides