# How to write an AI business case that finance will approve.

> In this field note, veridive sets out a one-page AI business case template that finance can check. It prices the whole workflow against a measured baseline, including running costs, review time and the expected cost of errors, writes down every assumption, tests the one that would change the decision, and agrees stop criteria before the pilot starts.

A credible AI business case prices the whole workflow, including running costs, review time and errors, against a measured baseline. It writes down the assumptions finance can check, and names the point at which you stop.

## Key takeaways

- Price the whole workflow, not the model: build and running costs, review time and the expected cost of errors.
- Compare every option with a measured baseline, including the current error rate, never with zero.
- Write each assumption down with its source, and find the single one that would change the decision.
- Agree stop and continue criteria before the pilot starts, and revisit the case at every gate.

Finance sends the AI proposal back with three questions. What does it cost to run, not just to build? Compared with what? And what happens if it doesn’t work?

A proposal built on a vendor’s headline and a price per token can’t answer any of them. A case finance will approve prices the whole workflow against a measured baseline, writes down the assumptions so they can be checked, and names the point at which you stop. It fits on one page.

## What does finance need to see?

- **A baseline, measured.** Volume, time per case, error rate and cost per case as the work runs now, not as someone remembers it.
- **The whole cost.** Building, running and reviewing, not only licenses or tokens.
- **Benefits in their terms.** Which budget line moves, and which benefits are capacity rather than cash.
- **Assumptions they can check.** Every number traced to a source, or labeled as an estimate.
- **The downside.** What you will have spent by the time you know it doesn’t work, and who decides to stop.

## Which costs belong in the case?

**Cost to build** is the one-off part: discovery, the pilot, integration with the systems the workflow touches, security and data-protection review, training and the evaluation set. Count internal time, especially the experts who write the reference answers; it is the line most often missing. [What drives build costs](https://veridive.com/insights/ai-implementation-cost/) is a subject of its own.

**Cost to run** recurs every month: model usage, infrastructure, monitoring, support, and upkeep such as maintaining prompts and re-testing after model updates. It also includes the minutes people spend reviewing each case, often the largest line of all.

**Cost of change** is easy to forget: running old and new side by side during the pilot, training new starters and retiring the old path. Ask finance how they want one-off and recurring costs presented, and follow their format.

## How do you estimate benefits without inventing numbers?

Start from measurements of the current process. Volume comes from your systems. Time per case comes from a short time study: sit with the team for a morning and time real cases. Error rates come from rework logs, credit notes and complaints.

Estimate the change as a range, and test it early. Running a candidate design on a few dozen past cases before the pilot gives you a range from your own work instead of a vendor’s average.

Then separate capacity from cash. Hours freed become money only when a budget line moves, such as overtime, temporary staff or a hire you no longer need; otherwise say what the time is for and count it as capacity. [Measuring ROI after launch](https://veridive.com/insights/how-to-measure-ai-roi/) covers that distinction in depth. List benefits nobody prices, such as consistency across teams, in words rather than numbers.

## How do you show risk and the cost of errors?

Price each kind of error with the workflow owner and finance: rework, direct loss, customer impact, compliance exposure. Rough ranges are enough, and the note on [the cost of a token vs. the cost of a mistake](https://veridive.com/insights/cost-of-a-token-vs-cost-of-a-mistake/) shows the arithmetic.

Show the expected cost of errors on both sides, because the current process is not error-free. Name the errors that are unacceptable at any rate, and the control that prevents each one, usually an approval point, instead of pricing them. And state the downside plainly: the fixed cost of a pilot that fails its criteria.

Price the option of doing nothing too. The backlog that grows, the overtime at every peak and the growth the team can’t absorb are real costs, and leaving them out makes every alternative look expensive.

> A business case without stop criteria is a request for money, not a plan.

## Which assumptions must be written down?

At least these: volume, time per case now, review time with the system, error rates before and after, cost per error, running cost per task, the share of cases that will actually go through the system, build cost and ramp-up time. Give each a source (measured, estimated or vendor-quoted) and the pilot measurement that will confirm it. One line might read: “Review time with the system: 4 minutes a claim. Source: 30 past claims run through a prototype. Confirmed by: timing live claims during the pilot.”

Then move one assumption at a time and watch the result. Usually one dominates. That is the assumption the pilot should measure first, and the one the stop criteria are written around.

## What does a one-page business case look like?

| Section | What goes in it | Where the numbers come from |
|---|---|---|
| Workflow | Who does what, for which cases | The owner |
| Baseline | Volume, time per case, error rate, cost per case | Systems and a time study |
| Options compared | Do nothing, fix the process, buy, build | A test on the same real cases |
| Cost to build | One-off costs, internal time included | Plans and quotes |
| Cost to run | Monthly, at real volume, review included | Pilot measurements |
| Expected cost of errors | Error rate times cost per error, before and after | Evaluation set and finance |
| Benefits | Cost removed, capacity freed and its use | Baseline and pilot |
| Assumptions | Each with its source and sensitivity | All of the above |
| Stop criteria | Thresholds to continue, stop or pause | Agreed before the pilot |

Take an illustrative warranty-claims desk. The numbers are invented to show the arithmetic, in made-up units; they are not prices or benchmarks. A minute of staff time costs 1 unit, and a wrong decision costs 60 units to put right.

| Per claim | Now | With the system |
|---|---|---|
| Staff time | 12 | 4 (review) |
| Running cost | 0 | 1 |
| Expected cost of errors | 2.4 (4 in 100) | 1.2 (2 in 100) |
| Total | 14.4 | 6.2 |

At 1,000 claims a month the difference is 8,200 units, so a build cost of 60,000 units pays back in a little over seven months. Staff time counts as money here only because the owner has committed the freed time to absorbing growth that would otherwise need temporary staff.

Now test the sensitivity. If running costs double, payback stretches to a little over eight months; if errors don’t fall at all, to about eight and a half. If review takes 9 minutes instead of 4, it stretches to almost nineteen. Finance wants payback within twelve months, which holds only while review stays under about seven minutes a claim. Review time decides this case.

## When should the case be revisited?

At every gate: after discovery, when estimates become a measured baseline; after the pilot, when assumptions become measurements; and after the first quarter live. Revisit it also when an input moves, such as volume, prices, error costs or the model underneath.

The stop and continue criteria go into the case before the pilot starts. In the claims example they might read:

- **Continue** if review time is at or below seven minutes, no unacceptable error appears on the evaluation set, and running cost stays under 1.5 units a claim.
- **Stop** if review time stays above nine minutes after two rounds of changes.
- **Pause** if data access isn’t in place by the end of the second week.

A pilot stopped by its own criteria is not a failure. It is the cost of learning, capped in advance. Keep the approved version of the case, too: comparing it with what was measured is how finance learns to trust the next one.

## Baseline before benefits

Fill in the baseline row first; if you can’t, that is your first piece of work. A [Discovery Sprint](https://veridive.com/services/ai-strategy/) of about two weeks measures the baseline and writes the pilot plan and acceptance criteria this page needs. The first steps, from an Executive Build Day to a pilot, have a fixed scope and price (see [the ways in](https://veridive.com/services/#ways-in)), so the cost of learning is known before it starts.

## Frequently asked questions

### What should an AI business case include?

One page that finance can check: the workflow and its measured baseline, the options compared, the cost to build, the cost to run including review time, the expected cost of errors, the benefits, every assumption with its source, and the criteria for stopping or continuing after the pilot. Any number that can’t be traced to a measurement is labeled as an assumption.

### How do you estimate AI benefits before a pilot?

Start from what you can measure now: volume, time per case, error rate and what errors cost. Estimate the system’s effect as a range, test it on a sample of real past cases where you can, and label it as an assumption the pilot will measure. Don’t use vendor averages or public benchmarks as your benefit.