How to Build an AI Business Case for Finance

I get nervous when an AI business case begins with “everyone will save time.”

Maybe they will.

But time savings have become the AI version of synergy in an acquisition deck. They appear everywhere, sound financially responsible, and get surprisingly vague when I ask when the cash shows up.

If Finance is going to support an AI investment, I want the business case to survive contact with the P&L.

I start with the ugly workflow

Not the software demo.

Show me the work that is expensive, slow, error-prone or preventing the team from doing something more useful.

Maybe analysts lose two days refreshing reporting. Maybe reconciliations hold up close. Maybe forecast inputs are consolidated by hand. Maybe Finance cannot review enough transactions to spot unusual activity quickly.

Now we have a baseline.

If the problem cannot be described without mentioning the vendor, I am not sure we have found the problem yet.

Saved hours are not automatically saved dollars

This is where AI ROI models can get generous.

An analyst saves ten hours a month. Great.

Did payroll fall? Did we avoid a hire? Did the analyst use those ten hours to produce work the company previously could not get done?

If none of those happened, we created capacity. Capacity can be valuable. It is not the same thing as cash savings.

I separate hard-dollar savings, avoided future cost, capacity, revenue impact and risk reduction because I do not trust a model that quietly converts all five into the same kind of dollar.

My kids use a similar financial method when explaining how much we “saved” on something we had no intention of buying until it was on sale.

Finance should probably use a higher bar.

The hourly-rate multiplication trick needs adult supervision

Take 2,000 theoretical hours saved. Multiply by a fully loaded employee rate. Announce $180,000 of value.

I see versions of this constantly.

Sometimes it is legitimate. Often it is theoretical capacity wearing a cash-savings name tag.

I would rather show $180,000 of capacity and explain exactly how management plans to use it than pretend the money has already appeared.

That makes the case more credible, not less.

The invoice is not the implementation cost

Software price is the easy line.

Integration, data work, security review, internal project time, training, process redesign, governance, support and ongoing monitoring all belong somewhere in the economics.

The 1990s taught us the printer itself was never the expensive part. The cartridge eventually found you.

AI projects have cartridges too.

I put confidence next to the benefits

A contractually eliminated software cost is high confidence.

A future hire we can demonstrably avoid may be reasonably high confidence.

“People will make better decisions” may be completely true and still be difficult to monetize.

I would rather show a range and a confidence level than force every benefit into a beautifully precise fiction.

CFOs are allowed to understand uncertainty. In fact, I recommend it.

The business case should survive after the purchase order

Before approval, I want the post-launch scorecard.

If the project is supposed to shorten close, measure close days and review effort. If it is supposed to automate reporting, measure manual hours and adoption. If it is supposed to improve collections, measure the working-capital result.

Then come back after 90 days and six months.

Did the workflow actually change? Are people using it? Did the expected capacity appear? Did the avoided hire stay avoided? Would we buy the thing again?

That last question has a way of cutting through the transformation vocabulary.