How to Build an AI Business Case Your CFO Won't Kill

CFOs kill AI proposals for the same reason they kill most proposals — the math didn't hold up under a second look. This post is a working template for building an AI business case that survives the CFO's questions the first time, instead of the third.

What CFOs actually want to see

Every CFO evaluation of an AI project answers four questions:

1. What's the baseline cost of the current process, in dollars per year?
2. What will the new process cost — build, run, and support — over the same period?
3. What are the savings, and how confident are they?
4. When do we hit payback, and what could delay it?

Everything else is context. If your business case answers those four questions with numbers and defensible sources, you're 80% of the way to approval. If it doesn't, no amount of vision slides will save it.

Step 1: baseline the current cost

Before you argue for savings, measure the baseline. Take the specific workflow you're proposing to automate and count what it currently costs, in three buckets:

• Labor — hours per week × loaded hourly rate × 52
• Tooling — any software the current workflow depends on
• Failure cost — errors, escalations, rework, refunds, missed deadlines

A common miss: only counting labor. Labor is the biggest component but failure cost is often the argument that swings a CFO. If the current process has a 3% error rate on customer-facing outputs and each error costs $200 to fix, that's real money nobody put on the P&L.

Baseline example:

• Support triage: 3 FTEs × $60,000 loaded = $180,000/year
• Tool costs: $6,000/year in helpdesk seats
• Escalation cost: 500 mis-routed tickets × $50 average recovery = $25,000/year
• Baseline: $211,000/year

Step 2: model the new process end to end

The CFO's second question is what the new process costs. Not just the build — the total ongoing cost, honestly stated.

Build costs

The one-time investment. Agency fees or internal engineering time, plus any integration work. For a first internal AI automation, this is usually in the $10K to $50K range for a scoped project.

Ongoing model and infrastructure costs

The recurring number. Model API fees at production volume, plus hosting, monitoring tools, and any vendor licenses. Estimate at production usage, not the pilot volume.

Support and adoption costs

Often forgotten. The internal team hours to maintain the workflow, respond to model failures, and support the operators using it. A useful rule of thumb: 20% of the build cost annually for the first year, dropping to 10% in year two.

Residual labor

The people who still need to review, escalate, or manage the automation. A "60% automated" workflow still has 40% labor cost. Model this explicitly.

Example continuing from above:

• Build: $35,000 (one time)
• Ongoing model + infra: $9,000/year
• Support: $7,000/year
• Residual labor (40% of 3 FTEs): $72,000/year
• Year 1 total: $123,000. Year 2 onward: $88,000

Step 3: compute savings and confidence

Savings is baseline minus new state:

• Year 1: $211,000 − $123,000 = $88,000
• Year 2+: $211,000 − $88,000 = $123,000/year

Now the CFO question: how confident is that number? A useful practice is a three-scenario view — base case, low case, high case — rather than a single point estimate.

Low case: automation only handles 40% of workflows instead of 60%, and model costs are 50% higher.

High case: automation handles 75% of workflows, model costs come in as estimated.

Presenting a range with an explicit assumption behind each end of it earns more trust than presenting a single number with false precision. CFOs read ranges as maturity.

Step 4: payback and sensitivity

Payback is when cumulative savings exceed cumulative investment. In our worked example:

• Investment year 1: $35,000 (build) — no ongoing until live
• Savings year 1 (assuming live by month 3): ~$66,000
• Payback: month 6 of year 1

A CFO will always follow with: what would delay payback? Answer preemptively:

• Build slippage — every month of delay is a month of missed savings
• Adoption gap — if the workflow team doesn't use the tool, savings never materialise
• Model cost overrun — if usage triples over estimate, ongoing costs rise proportionally

Each of these should have a mitigation. Not "we'll monitor closely" — a specific action. E.g., "The rollout plan includes weekly adoption reviews for the first eight weeks, with a fallback to the current process if usage stays below 40%."

Step 5: risk-adjusted return

For projects above $50K, CFOs will often want a risk-adjusted number, not just the base case. A simple approach: probability-weight the three scenarios.

• 30% chance of low case ($60K/year savings)
• 50% chance of base case ($123K/year savings)
• 20% chance of high case ($175K/year savings)
• Risk-adjusted year 2 savings: 0.3(60) + 0.5(123) + 0.2(175) = $114,500

This kind of number reads as considered instead of optimistic. It's the number CFOs quote back to you when they're arguing for the project internally.

The one-page format that clears review

The business case doesn't need to be long. What tends to work:

1. The plan in one paragraph
2. Baseline cost table
3. New state cost table (build + ongoing)
4. Savings and confidence range
5. Payback timeline with delay risks
6. Risk-adjusted 3-year view
7. What's being deprioritised to fund this

Two pages, ideally. Longer than three and the CFO reads it in slower sittings, which usually means the decision moves to the next meeting.

Common ways business cases fall apart

Overstating savings

The biggest single killer. A 100% automation claim gets discounted to 40% by the CFO's mental model. Present realistic assumptions and you win the credibility fight in the first paragraph.

Understating ongoing costs

The build cost is easy to estimate; the ongoing model spend and support time are the ones that get forgotten. When those show up in year two, the CFO remembers the original case and stops trusting future ones.

Missing residual labor

The mistake of assuming zero people needed after automation. Even a mostly-automated workflow needs review, escalation handling, and occasional intervention. Model 30-40% residual labor as a default.

No baseline measurement

"We think it costs about $200K a year" is not a business case. It's a story. Measure the actual current cost — even a rough count of hours per week × loaded rate — and the argument becomes real.

Payback tied to unreliable savings

If the savings math relies on revenue enabled instead of hours saved, the payback timeline gets pushed out and the CFO discounts it heavily. Lead with hours-saved savings when possible; treat revenue upside as a bonus, not the base case.

Working with an external partner on the business case

A common pattern: the CFO trusts the numbers more when they came from an outside diagnostic instead of an internal advocate. Not because insiders are wrong, but because the diagnostic team has to defend the numbers against the CFO's questions in real time.

This is one of the underrated outputs of an AI Audit. The prioritised action list from the audit is essentially a portfolio of business cases, each with baseline, new state, savings, and payback. The CFO gets what they want without three rounds of internal edits.

Frequently asked questions

What's a healthy payback period for an internal AI project?
Under 12 months is a good target. Six to nine is common for well-scoped first automations. Anything over 18 months tends to get parked because the future value is discounted too heavily.

How do we handle uncertainty in the savings estimate?
Present a range with explicit assumptions on each end. CFOs trust ranges more than point estimates. Also include a probability-weighted view for projects above $50K.

Should we include soft benefits in the business case?
Yes, but separately. Hard savings should stand on their own. Soft benefits (morale, brand, retention) belong in a supporting section, not the payback math.

How much detail should the business case include?
Two pages of substance. Enough to be defensible under CFO questioning, short enough to be read in one sitting. Long business cases signal that the analyst hasn't decided what matters yet.

Where this leads

A strong business case is the middle of the funnel between an AI opportunity and an approved project. The scoring exercise (how to prioritise AI opportunities) is the input; the business case is the output; the board approval (how boards evaluate AI strategy proposals) is the destination.

Working with us

The AI Audit produces business cases in the exact format above — baseline, new state, savings range, payback, and risk-adjusted view. Two weeks, five deliverables, fixed price.