Most business cases fail for one of two reasons. Either the financial model is missing, so the reader has nothing to evaluate except adjectives, or the model is there but so optimistic that a finance partner can dismantle it in three questions. A good template fixes both. It forces the sections a decision-maker needs, and it makes the arithmetic explicit enough that the assumptions can be argued with directly, which is the point.
Key takeaways
- A business case has eight sections. Everything else is appendix material.
- The financial model is the case. Four numbers matter to a US corporate approver: NPV at the company hurdle rate, ROI, payback period, and IRR.
- Count the run cost. Cases that omit years 2 to 4 of support and licensing are the ones that get audited later.
- Every benefit line needs a named owner who will be held to it. An unowned benefit is a wish, and reviewers know it.
- Run the sensitivity test before the meeting: benefits at 70 percent, costs at 130 percent. If it still clears the hurdle rate, the case is robust. If it does not, say so first, before someone else does.
Download the business case financial model
business-case-financial-model.xlsx is the cost and benefit model from this article with the formulas live: net and cumulative cash flow, discounted cash flow, and NPV, ROI, payback, and IRR calculating themselves off an editable discount rate. Open it in Excel or upload it to Google Sheets. A plain CSV version is there too.
What is in the file: cost lines across year 0 to year 4 (licenses, implementation, services, training, run and support), benefit lines (labor saved, cost avoidance, error reduction, revenue uplift), net and cumulative cash flow, discounted cash flow, and the NPV, ROI, payback, and IRR formulas already written.
What should a business case include?
A business case should include eight sections: an executive summary, the problem or opportunity, the options considered, the recommended option, the costs, the benefits, the risks, and the delivery outline with a decision request. Anything else belongs in an appendix. The order matters, because approvers read the first page and skim the rest.
| Section | What goes in it | Length |
|---|---|---|
| 1. Executive summary | The ask, the cost, the return, the recommendation. Written last, read first. | Half a page |
| 2. Problem or opportunity | What is happening today, quantified. The cost of doing nothing. | Half a page |
| 3. Options considered | At least three, including do nothing. A case with one option is a purchase order in a costume. | 1 page |
| 4. Recommended option | Which one, and the reasoning that eliminated the others | Half a page |
| 5. Costs | Build and run, years 0 to 4, including internal hours at a loaded rate | Table |
| 6. Benefits | Each line quantified, with a named owner and a measurement method | Table |
| 7. Risks and assumptions | The three that would sink it, with a mitigation each. Name the assumptions your numbers rest on. | Half a page |
| 8. Delivery outline and the ask | Timeline, team, gates, and the specific decision you want made | Half a page |
Swipe to see more →
This template is the artifact. If you want the argument behind it, how to build the case, how to get it through governance, and how to survive the questions, our guide to the project business case covers the process end to end.
The financial model, line by line
The model has two halves and one honest habit. Costs first, because it is harder to inflate a cost line than a benefit line and a reader who trusts your costs will read your benefits more generously.
Costs
Five lines cover almost every technology or process business case: software licenses, implementation (internal hours at a fully loaded rate, not salary), vendor or integration services, training and change management, and run and support from year 1 onward. The most commonly omitted line is the last one. A platform that costs $340,000 to build and $95,000 a year to run is a $720,000 decision over four years, and a case that shows only the build cost is not wrong so much as misleading.
Use a loaded rate for internal hours: salary plus benefits, taxes, and overhead, typically 1.25 to 1.4 times base salary in US companies. Ask finance for the rate they use rather than inventing one, because using the wrong loaded rate is the fastest way to have the whole model dismissed. And when the case rests on retiring an existing system, get the real current spend from the finance or billing data rather than from memory. The number people quote from memory is almost always the license, and almost never the license plus the infrastructure plus the two contractors who keep it alive.
Benefits
Four categories, in descending order of how much a CFO will believe them: hard cost savings (a contract you will cancel), cost avoidance (a cost you will not incur), productivity or error reduction (hours saved, converted at a loaded rate), and revenue uplift. Revenue uplift is the line that gets attacked, every time, so state its assumption in one sentence directly under it and be ready to defend that sentence rather than the number.
Each benefit line needs a named owner: the person who agrees the benefit is real and will be measured against it. This one rule changes the numbers more than any modeling technique, because a benefit nobody will sign for tends to shrink to its honest size the moment you go looking for a signature. It also sets up the benefits realization tracking after approval, which is the only reason anyone believes the next business case you write.
The four output numbers
| Number | Formula | What approvers do with it |
|---|---|---|
| NPV | Sum of net cash flow per year, discounted at the hurdle rate | The primary test. Positive NPV clears the bar; negative does not, whatever the story says |
| ROI | (Total benefit minus total cost) divided by total cost | The headline number for the executive summary. Easy to compare, easy to game |
| Payback period | The year cumulative cash flow first turns positive | The risk proxy. Under 24 months is comfortable in most US corporates |
| IRR | The discount rate at which NPV equals zero | How finance ranks this against other uses of the same money |
Swipe to see more →
Use your company's actual hurdle rate for the discount rate. If nobody can tell you what it is, 8 to 12 percent is the common band in US corporates, and saying "we used 10 percent because finance could not give us a rate" is far better than quietly using a rate that flatters the case.
A worked example
A finance operations platform, four-year horizon, 10 percent discount rate. The numbers are illustrative, but the shape is one you will recognize.
| Year 0 | Year 1 | Year 2 | Year 3 | Year 4 | Total | |
|---|---|---|---|---|---|---|
| Total cost | $355,000 | $125,000 | $120,000 | $120,000 | $120,000 | $840,000 |
| Total benefit | $0 | $245,000 | $360,000 | $390,000 | $390,000 | $1,385,000 |
| Net cash flow | -$355,000 | $120,000 | $240,000 | $270,000 | $270,000 | $545,000 |
| Cumulative | -$355,000 | -$235,000 | $5,000 | $275,000 | $545,000 |
Swipe to see more →
Read it the way an approver does. ROI is 65 percent over four years. Payback lands early in year 2, which is comfortable. NPV at 10 percent is roughly $360,000, positive, so the case clears. Now the sensitivity test: cut benefits to 70 percent and raise costs to 130 percent, and net cash flow over four years falls to about $77,000 with payback slipping into year 3. Still positive, still fundable, and now you can say so out loud in the meeting before anyone asks. A case that survives its own stress test is worth more than a case with better headline numbers and no stress test at all.
How long should a business case be?
Five to ten pages for a significant investment, with the financial model as an attached spreadsheet. Anything shorter usually skips the options analysis; anything longer stops being read. For smaller work, most PMOs run a one-page lightweight version at the first gate and a full case only once the idea has survived intake, which keeps the organization from spending three weeks of analysis on an idea that dies in twenty minutes.
Scale the effort to the decision. A $50,000 project does not deserve a $15,000 business case. Set a threshold in your portfolio governance rules: above this amount, a full case with a model; below it, a one-pager with a cost and a sponsor. Publishing the threshold saves more time than any template ever will.
How wrong can the numbers be before the case stops working?
Run every business case at three levels and publish the switching value: the point at which the main benefit assumption stops clearing your hurdle rate. A case that survives a 30 percent benefit shortfall is a different proposition from one that fails at 5 percent, and the board cannot tell those apart from a single net present value figure.
The switching value is the most useful line in a business case and the one most templates leave out. Instead of arguing about whether the forecast is right, you calculate how far it can fall before the decision changes, then ask whether anyone believes it could fall that far. That reframes an unwinnable argument about a number nobody can know into a judgment call the room is actually qualified to make.
| Scenario | How to set it | What the board reads from it |
|---|---|---|
| Downside | Benefits at 70 percent of forecast, costs at 130 percent, benefits starting one quarter late | Whether the case still stands when the usual things go wrong |
| Expected | The forecast as submitted | The case as the sponsor believes it |
| Upside | Benefits at 120 percent, delivered on the planned date | What is being given up if the project is deferred |
| Switching value | Solve for the benefit level at which net present value reaches zero | The single number that says how much room for error the case has |
Swipe to see more →
Two practical rules keep this honest. Vary one driver at a time so you can see which assumption the case actually rests on, then vary the top two together for the downside case, because in practice benefits arriving late and costs running over tend to happen to the same project. And state the delay separately: for most cases, a benefit stream starting two quarters late damages the return more than a 10 percent cost overrun, which is not obvious until you model it.
The assumption register that turns a forecast into a commitment
Every benefit figure in a business case rests on assumptions, and the ones that go unwritten are the ones that fail. Adding a short register to the template costs a page and changes the conversation after approval, because when an assumption turns out to be wrong there is a record of who expected to check it and by when, rather than a search for who should have known.
| Field | What goes in it |
|---|---|
| Assumption | Stated as a testable claim, not a hope. "Call volume falls by 20 percent within two quarters of launch." |
| Drives which number | The specific benefit or cost line that changes if this is wrong |
| Confidence | High, medium or low, with one line on the basis: a measured pilot, a vendor claim, or an estimate |
| Owner | A named person, not a team |
| How it will be validated | The evidence that will settle it, and the date |
| If it is false | The effect on the case, and whether that alone would have changed the decision |
Swipe to see more →
The last field is the one that earns the register its place. If a single assumption being wrong would have flipped the decision, the board should know that at approval rather than at the first benefits review, and it is usually worth spending two weeks validating that assumption before committing the funding rather than after.
Who approves what, and at which threshold
A business case template is only as useful as the approval path it feeds. Most organizations set thresholds by investment size, and writing them into the template header saves the author from guessing which forum they are writing for, which in turn stops the common waste of a fifty page document produced for a decision a delegated authority could have taken in a week.
Set your own bands against your actual spend profile rather than copying figures from elsewhere. A useful calibration is that the lowest band should cover the majority of requests by count and a small minority of spend, and the top band should be rare enough that the board treats each one as a genuine event. If most of your requests land in the top band, the thresholds are too low and the board is being used as a queue.
| Band | Typical approver | Case format | What the approver is checking |
|---|---|---|---|
| Small, routine | Department or PMO lead under delegated authority | One page, benefits and cost only | That it fits an agreed plan and budget already exists |
| Medium | Portfolio board or investment committee | Short form: options, costs, benefits, risks | Priority against other requests, and capacity to deliver |
| Large or cross-functional | Executive committee, with finance review first | Full case with financial model and sensitivity | Strategic fit, funding source, and whether the benefits are defensible |
| Any size, mandatory or regulatory | Fast-tracked, but still recorded | Short form plus the specific obligation cited | That the obligation is real and named, not asserted |
Swipe to see more →
That last row prevents a common failure. When "mandatory" carries no evidence requirement, the share of requests claiming it climbs every year until the category is meaningless. Requiring a named regulation, clause, contract or audit finding on the form is a one line change that reliably shrinks the category.
Why business cases get rejected
Cases are rarely turned down because the arithmetic is wrong. They are turned down because the reader cannot tell what is being asked for, cannot see who is accountable for the return, or does not believe the organization can deliver it alongside everything else already committed.
| Reason | What the board actually says | The fix in the template |
|---|---|---|
| Benefits nobody will own | "Who is signing up to deliver this saving?" | A named benefits owner who agrees before submission, not the project manager |
| No credible alternative considered | "Was anything else looked at?" | Options section including do nothing and a cheaper partial option, each costed |
| Costs stop at go-live | "What does it cost to run once it is built?" | Whole life costs: licenses, support, and the internal effort to operate it |
| Soft benefits presented as cash | "Does this actually reduce headcount or budget?" | Separate cashable from non-cashable benefits and never total them together |
| No capacity to deliver it | "Who would build this, and what stops instead?" | The skills required and the named trade-off if approved |
| Written for the author, not the reader | Silence, then deferral | A one page summary carrying the ask, the return, and the risk |
Swipe to see more →
Deferral is the outcome to design against, because it costs everyone a cycle and teaches nobody anything. If a case comes back for more information twice, the problem is almost never the information. It is that the decision the board is being asked to take was never stated plainly on the first page. If it helps to see the difference, these five filled-in cases across different types of project show what a first page looks like when a committee can act on it straight away.
What happens to the case after approval
An approved business case should not be filed. It becomes the baseline the project is measured against, and three of its parts have a job to do afterwards: the benefits become the benefits register, the assumptions become items on the risk log with owners and dates, and the cost profile becomes the budget the finance system tracks against.
Set the first benefits review date at approval, in the same meeting, and put it in the minutes. Benefits reviews that are scheduled later are scheduled never, because by the time anyone remembers, the sponsor has moved on and the baseline has been overwritten. Reviewing the forecast against the outcome is also the only way an organization ever improves at forecasting: if nobody checks, every future case is written with the same optimism as the last one, and the board learns to discount all of them equally, which punishes the honest authors most.
Frequently asked questions
What is a business case template?
A business case template is a pre-structured document and financial model that captures the eight things an approver needs: the summary, the problem, the options, the recommendation, the costs, the benefits, the risks, and the delivery plan with a specific decision request. The financial half calculates NPV, ROI, payback, and IRR from the cost and benefit lines.
What sections does a business case template need?
An executive summary, a quantified problem statement, at least three options including do nothing, the recommended option with reasoning, a full cost table covering build and run, a benefit table with a named owner per line, the top risks and the assumptions the numbers rest on, and a delivery outline ending in the ask.
How do you write a business case in Excel?
Put costs and benefits in rows and years in columns, calculate net cash flow per year, then cumulative cash flow, then discounted cash flow using the company hurdle rate. NPV is the sum of the discounted flows, ROI is total benefit minus total cost divided by total cost, payback is the year cumulative flow turns positive, and IRR uses Excel's IRR function on the net cash flow row.
What is a business case financial model?
It is the spreadsheet that turns the argument into four comparable numbers. It lists every cost line across the full horizon including run and support, every benefit line with its owner, and it derives NPV, ROI, payback period, and IRR so the investment can be ranked against other uses of the same money.
What is an example of a business case?
A finance operations platform costing $355,000 to build and about $120,000 a year to run, delivering $1.39 million in labor savings, cost avoidance, and error reduction over four years. ROI 65 percent, payback early in year 2, NPV positive at a 10 percent discount rate, and still positive under a stress test of 70 percent benefits and 130 percent costs.
Who writes the business case?
The sponsor owns it; a business analyst, project manager, or PMO analyst usually writes it. The distinction matters at approval: the person who presents the case is the person who will be held to the benefits, and if the sponsor cannot defend the benefit lines without turning to the author, the board has learned something useful about the case.
What is the difference between a business case and a feasibility study?
A feasibility study asks whether an option can be done. A business case asks whether it should be, given the alternatives and the return. Feasibility work usually feeds the options section of the business case, and when a case is rejected for reasons of cost or priority rather than practicality, feasibility was never the issue.