Building the Business Case for Enterprise AI

Finance does not reject AI business cases because they dislike AI. They reject them because the inputs do not survive scrutiny — and the three that fail are always the same three.

The pattern is familiar to anyone who has taken one to a committee. The number is large, the slide is confident, and the first question from the CFO dismantles it. What follows is not a debate about strategy but a debate about arithmetic, which the sponsor loses.

Failure one: understated loaded cost

Most cases compute savings from base salary. Finance computes cost from fully loaded cost, which includes benefits, employer taxes, equipment, software licences, facilities, and allocated overhead. The gap is commonly 30 to 45 percent.

Counterintuitively, this understates your own case — but it is fatal anyway, because it signals that the numbers were not built with finance. Once one input is shown to be wrong, every other input is assumed to be wrong too.

The second error compounds it: dividing annual cost by 2,080 hours. That figure assumes fifty-two weeks at forty hours with nobody ever taking leave. Removing paid time off, holidays, training, and non-project time gives roughly 1,880 — the conventional planning figure. Using the larger number understates hourly cost by about 11 percent and flatters the payback.

Failure two: an automation rate nobody believes

Vendor calculators routinely assume 80 to 95 percent automation. No experienced reviewer accepts that, and its presence discredits everything around it.

The honest framing separates the mechanical portion of a task from the judgment portion. Transcription, first-draft generation, and routine restructuring can be largely absorbed. Review, exception handling, and the decision about whether the output is adequate cannot — and in a governed system they are not supposed to be, because that human gate is what makes the system approvable in the first place.

A defensible share sits between 50 and 70 percent of the mechanical work. That produces a smaller headline number and a case that survives the meeting.

Failure three: benefits that cannot be falsified

"Better decisions", "improved agility", and "faster time to insight" are not benefits a CFO can audit. They cannot be measured before, cannot be measured after, and therefore cannot be claimed.

Reclaimed engineering hours can. So can cycle time on a named process, defect escape rate, and the count of open items in a queue. Anchor the case on one primary benefit that is already instrumented, or that you can instrument before the pilot starts so a baseline exists.

List the softer benefits separately and explicitly as unquantified. That is a credibility signal rather than a weakness — it tells the committee you know the difference.

The benefits worth excluding on purpose

Several real effects should be left out of the arithmetic even though they are genuine, because they are difficult to defend and their presence invites challenge to the whole model.

Defect escape reduction, audit preparation time, faster release cadence, the cost of decisions made on stale data, and the reconciliation overhead of competing spreadsheet definitions are all material. Name them, state that they are excluded, and let the case stand on the floor rather than the ceiling. Reviewers who find an excluded benefit tend to add it back themselves.

What the committee is actually deciding

Beneath the arithmetic, the question is whether this project will still exist in eighteen months. Most enterprise AI spending to date has produced pilots that never reached production, and every committee has funded at least one.

Address that directly. Show that the security review is scheduled at the start rather than the end, that deployment topology is already decided, that a named team will own the system after handover, and that the deliverable includes source and infrastructure code rather than a vendor dependency. Those facts do more for approval than an extra half-million in projected savings.