Business Case

A business case is more than a spreadsheet with ROI calculations in it. It is the document that argues for an investment: what is being bought, what it costs, what changes as a result, and why the change is worth the money. In enterprise sales the case is usually written with the vendor and then used internally by the champion, which makes it the only artefact from the sales process that finance will read closely.

This entry defines the term and its parts. If you need the document itself rather than the method, the free business case template for a software purchase gives you the seven fields in Word, Excel and Google Docs, and sets out where a template stops being enough. For the market evidence on why documented cases still stall in committee, see the 2026 research.

Components of an effective business case

Executive summary

One page a busy executive can read in under two minutes. The investment, the return, the risk, and the reason to act now.

Current state

The baseline that the improvement will be measured against: current costs, current volumes, the specific inefficiency being fixed, and what the status quo costs each year it continues.

Proposed solution

What is being bought, described in terms of what it does for the organisation rather than what it does technically. Enough detail to be credible, not enough to invite a specification argument.

Financial analysis

The quantitative heart of the document, usually produced by an ROI model:

• ROI: return on investment as a percentage
• Payback period: how long before the investment has paid for itself
• NPV: net present value of the cash flows, discounted
• TCO: total cost of ownership across the term, including the costs that are easy to forget

Risk assessment

An honest account of what could go wrong. A case with no downside in it reads as marketing, and experienced reviewers discount it accordingly.

Implementation timeline

Milestones from decision to the first measurable benefit, because the buyer has to plan around them, and because value realization is measured against them.

Why business cases fail

1. Written for the vendor's agenda, not the buyer's decision
2. Assumptions borrowed from a benchmark that nobody in the room recognises
3. Built without finance or IT, then presented to both
4. No sensitivity analysis, so one challenged input collapses the whole case
5. Benefits only, no cost of delay, which leaves doing nothing looking free

How these failures play out in live deals, where the champion is enthusiastic but finance will not sign, is covered in Your Best Deals Are Dying in Procurement. Tailoring one case to the CFO, CIO and procurement without contradictions is covered in business case strategies for each buying committee role.

A business case is also not a proposal. A proposal describes what the vendor will do and what it costs. A case describes what changes for the buyer and what the change is worth. The two are often the same file with the same cover, which is part of why finance reads proposals with suspicion. Separating them is usually the first fix: the case should stand up without the vendor's name on the first page, so a champion can circulate it internally without editing the sales language out of it.

A worked example

A team is proposing a £120,000 implementation with £40,000 a year in running costs. The model claims £70,000 of benefit in year one, £110,000 in year two and £130,000 in year three, and discounts at 10%.

The net cash flows are £30,000, £70,000 and £90,000. Three-year ROI is 29%: £310,000 of benefit against £240,000 of total cost. NPV is £32,700, which is positive, so the case passes the first test.

Then payback. Cumulative cash runs at −£120,000 at signature, −£90,000 after year one, −£20,000 after year two, and positive £70,000 after year three. Payback lands at 2.22 years, or 27 months.

If the company requires payback inside 24 months, this case fails by three months despite a positive NPV. That is the useful part of the arithmetic. It tells you the proposal's actual weakness is the ramp, not the return, and the fix is either a payment structure that defers cost or a first-year benefit that arrives sooner. A case that only reports ROI lets that weakness stay hidden until someone else finds it.

How this shows up in a real deal

Two weeks before a committee meeting, a champion asks for "the numbers". What comes back is a thirty-tab spreadsheet with assumptions on tab nineteen and a single headline figure: 240% return. Finance opens tab nineteen, finds a productivity assumption set at 70% of headcount, and the meeting is now about the assumption rather than the investment. The version that gets approved is usually shorter: six lines of inputs, each one traceable to something the buyer already measures, a payback figure, and a candid note that the benefit depends on adoption reaching 60% by month nine. Fewer numbers, each of them defensible.

Reading further

The mechanics of making a case survive finance review are set out in Building CFO-Ready Business Cases, in how to build a CFO-ready business case for SaaS and in more depth in the CFO-proof business case guide. If the current case lives in a spreadsheet, why spreadsheet business cases fail is the honest version of that problem. For how the document fits into the wider practice, start with what value engineering means in B2B sales.