SAP business case template: get approval without delay

An SAP business case gets approved when the decision-makers can see the problem, the cost, the return and the risk on one page, in their own terms. Use the seven-section structure below, include every cost for at least five years, keep the benefit assumptions conservative, and write separate passages for the CFO, IT and the business. Most cases that stall fail on presentation, not on the idea.

I have seen approvals drag on for weeks, sometimes months, even when the idea was solid. I remember an S/4HANA migration where the first pitch failed. The proposal was packed with system architecture diagrams and had almost nothing on operational gains. We reworked it so the opening focused on cutting shipping delays, reducing inventory costs and how the team would deliver. The CFO approved it in one meeting.

One more point before the template. Your implementation partner should not write your business case. Their incentive is to start the programme. Yours is to finish it. That is how $40 million programmes quietly become $90 million ones.

The executive summary decides it

Keep it to one page. Executives may read nothing else.

Start with the problem, in numbers. State the proposal in one or two sentences with no technical detail. Then give the main benefits with figures, a simple timeline, the total investment and the key risks with their mitigations.

In one of the companies I previously supported, the summary opened with terms like "technical objects" and "Embedded HANA". The CFO put it down after the first paragraph. We rewrote it to start with "$2.5 million in annual cost savings through inventory reduction" and "40% faster order processing". The same CFO read the whole page and approved the project that week.

When the summary is done, give it to someone outside the project. If they can explain it back to you, it works.

Write for three readers

One version for everyone does not work. I have watched strong proposals die because they were written for the wrong audience.

CFO and boardITBusiness users

What they look forCFO and boardNumbers they can repeat without notesITIntegration scope mapped against current systemsBusiness usersA task-by-task picture of their week

Give themCFO and boardAnnual savings and payback, with risks stated plainlyITThe support model after go-liveBusiness usersBefore and after, with an honest training time

What wins them overCFO and boardCandour over optimismITEvidence you know where similar projects went wrongBusiness usersHonesty about every extra click

The CFO and the board want numbers they can repeat without notes: "$2 million annual savings, 18-month payback." They want the risks stated plainly. Candour beats optimism with this audience.

IT wants the integration scope mapped against the current systems, the support model after go-live, and evidence that you know where similar projects went wrong.

Business users want a task-by-task picture of their week before and after, and an honest number for training time. A small extra click, repeated thousands of times a week, becomes a real problem.

I once had a CFO reject a business case mid-meeting because it answered none of her questions. We rebuilt it in three sections, one per audience, and anchored each to measurable KPIs. The technical plan never changed. Only the way it was told did.

These are the seven sections I use, in this order. I remember a manufacturing company whose CFO found the cost details buried on page 23 while the CIO could not find the technical risks at all. Approval slipped six months. With a structured version, approval took two weeks, and the content had barely changed.

Section	What it must contain
Executive summary	Problem in numbers, proposal, benefits, total investment, timeline, top risks
Current situation	Pain points, their cost today, and the cost of doing nothing
Proposed approach	Scope, modules, deployment model (RISE, GROW or on-premise), main integrations
Financial case	Five-year costs and benefits, ROI, payback, NPV for larger programmes
Implementation plan	Phases, milestones, team, dependencies
Risks	Specific risks with owners and mitigations
Governance	Sponsor, steering committee, change control, extension approval rules

Keep architecture diagrams and configuration detail in an appendix.

The costs a finance director will look for

Incomplete costs kill more business cases than weak benefits. Include all of these:

1. Software: licence plus annual support for on-premise, or the subscription for RISE and GROW.
2. Implementation partner fees.
3. Infrastructure, if you run it yourself; under RISE, SAP runs it inside the subscription.
4. Internal staff time. This is the line most often missing.
5. Training and change management.
6. Data migration and cleansing.
7. Recurring support. On-premise SAP Enterprise Support has long been about 22 percent of the licence value per year. For RISE and GROW, show the subscription for every year of the term.
8. Hypercare after go-live.

Item 7 is the first thing many finance directors check. If years two to five are missing, credibility drops immediately. My SAP implementation cost guide has typical ranges for each line, and my contract review guide for CFOs covers the partner side.

ROI, payback and benefits the CFO will believe

ROI is net benefit divided by total investment. $3.5 million of five-year benefits against $2 million of cost is a net benefit of $1.5 million, or 75 percent.

Payback is the investment divided by the annual net cash benefit. A $1.2 million project returning $400,000 a year pays back in three years.

NPV discounts future cash flows to today's value. If the board asks for it, bring your finance team into the room.

Quantify benefits with the working shown:

• Inventory: $10 million of stock, reduced by 15 percent, at a 20 percent carrying cost, saves $300,000 a year.
• Process time: a 45-minute task run 200 times a day, cut to 15 minutes, at $30 an hour, saves about $750,000 a year over 250 working days.

Show a ramp-up. Benefits in the first year after go-live are usually lower than at steady state. Keep the benefits you cannot quantify on a separate list, so they do not dilute the ones you can.

Be conservative. I have seen businesses win approval for difficult SAP projects by being brutally honest about costs and conservative about benefits. A manufacturing client first showed a 30 percent ROI for its S/4HANA project. When challenged, it revised the case to a more realistic 18 percent. The CFO appreciated the candour and approved it.

Subscription replaces licence and support. RISE and GROW are subscriptions, so year one costs less than an on-premise licence purchase. The five-year total depends on users, scope and term. Show years one, three and five side by side.

The accounting changes, not just the cash. Under IFRS, a cloud contract often gives you access to software rather than a software asset you control. In that case, the IFRS Interpretations Committee's 2021 agenda decision means configuration and customisation costs are usually expensed as the services are received, not capitalised. That can move a large part of the programme cost from the balance sheet into the income statement. Agree the treatment of your RISE or GROW contract with your auditors before the financial case goes to the board.

Clean core changes the long-term cost. Extensions built on released interfaces cost more to design but survive upgrades. Modifications are cheaper today and expensive at every upgrade after. A five-year model should show that difference, especially on Private Edition, where the core can still be modified.

AI belongs in the case only with workflow-level assumptions. Joule and other AI features can save time in specific tasks. Tie every AI benefit to a named workflow, a user count and an adoption rate you can defend. CFOs see "AI will transform the business" pitches every week and discount them heavily.

Leaving out the cost of doing nothing. If the current system causes $500,000 a year in rework, that belongs in the case. Sometimes it is larger than the SAP investment.

Ignoring disruption. Training time, cutover downtime and a slow first month after go-live all reduce the return.

Vague risks. "Data issues" is not a risk. "Master data mismatch causing invoice rejections in the first 30 days" is.

A single go-live date with no detail. Delays usually start in the handoffs: requirements to configuration, testing to sign-off, training to readiness. Show them.

Ignoring the size of the company. In one project I worked on, a small distributor copied a large corporation's governance process. Weekly steering meetings turned into hours of lost productivity until the process was trimmed. For under 200 staff, 8 to 10 pages is enough. Enterprises expect full financial modelling and a detailed governance section.

I worked with a manufacturing team that spent six months getting approval. They revised the case four times, because each version answered a different approver and ignored the others. Writing for all three readers from the start would have saved most of that time. Once approved, the next document is the project charter.

What should an SAP business case include?

Seven sections: an executive summary, the current situation and the cost of doing nothing, the proposed approach and deployment model, a five-year financial case with ROI and payback, an implementation plan, specific risks with owners, and a governance model. Keep technical detail in an appendix.

Why do SAP business cases get rejected?

Usually because benefits are vague or costs are incomplete, especially recurring support or later subscription years. Other common causes: risks glossed over, or a document written for one audience when finance, IT and operations all need convincing.

How do you calculate ROI for an SAP implementation?

Divide the net benefit over the period, usually five years, by the total investment. Include every cost: software or subscription, partner fees, internal time, training, data migration, recurring support and hypercare. Use conservative benefits with a ramp-up after go-live. A realistic 18 percent closes faster than an optimistic 35 percent.

How does RISE with SAP change the business case?

The subscription replaces the licence and annual support, so the case needs a cost view for each year of the term. SAP runs the infrastructure, which removes hardware spend. Under IFRS, configuration costs for a cloud service are usually expensed rather than capitalised, so agree the accounting with your auditors early.

How long should an SAP business case be?

A one-page executive summary, then roughly 15 to 25 pages for a mid-market programme and up to 40 for a large enterprise. Put anything longer in appendices. If the sponsor needs an hour to brief from it, it is too long.

What is the cost of doing nothing in an SAP business case?

What the business keeps losing by staying on the current system: manual workarounds, reconciliation effort, reporting delays, support for ageing systems and decisions made on unreliable data. If you are on ECC, include the cost of extended maintenance after 2027.