How to size operational losses before you invest in AI

The short answer

Before you approve any AI project, ask for three numbers: what the problem costs today, what it costs to solve, and the net benefit after running costs. If the first number does not exist, the project cannot prove it worked, no matter how good the technology is.

Why most AI business cases fail the CFO

Most business cases start from the solution and work backwards to a benefit. The benefit is then stated as a percentage of something nobody measured, and finance discounts it to zero.

The fix is to start from the loss. A loss already exists in the books or in the operation, even if nobody has added it up. That makes it verifiable, and verifiable numbers survive a budget review.

Where operational losses hide

In most operations the money leaks in five places:

• Divergences: invoices, freight, contracts or payments that differ from what was agreed.
• Manual review: hours spent checking, reconciling and searching for evidence.
• Slow decisions: approvals and exceptions that wait days while revenue or customers wait too.
• Wrong decisions: payments that should have been blocked, credit that should have been approved, claims paid in error.
• Incidents found late: safety, quality or compliance problems discovered after they cost money.

How to put a number on it

You do not need a perfect model. You need a defensible range. For each source of loss, take a recent period, count the occurrences and multiply by the cost of each one. Hours of review are priced at the loaded cost of the people doing them. Divergences are priced at the amount recovered or lost. Slow decisions are priced at what waiting costs: lost sales, penalties or working capital.

Use the low end of every estimate. A conservative number that finance can check is worth more than an impressive one they cannot.

What it costs to solve

The cost of solving is more than the build. Include the discovery and PoC, the build, the integration with your systems, the running cost of models and infrastructure, and the time your team spends on review and operation. A system that saves a lot but needs a large team to watch it may not pay back.

The net benefit, and when to say no

The net benefit is the loss you expect to remove, minus the full cost of solving, over a period finance agrees with. If the range is thin or negative, the honest answer is not to build, or to start with a smaller, cheaper fix. Saying no to a weak case is how you keep credibility for the strong one.

A worked example

A hypothetical example, not a client case. A distributor reviews freight invoices by hand. In the last quarter the team checked 9,000 invoices and found divergences in 4% of them, recovering an average of R$ 600 each. Three analysts spend most of their week on it.

The loss is not the 360 divergences they found; it is the ones they did not have time to check, plus the analysts' hours. If a sample of unchecked invoices shows the same 4% rate, the uncaptured value is visible in the data the company already has. That is a number finance can verify, and it sets the target for the PoC.

Common objections from finance

"The savings are soft." Then price only what is hard: money recovered, hours redeployed with a name and a cost, penalties avoided with a record. Leave the rest out.

"We already have a team for this." The question is not whether the team exists, but how much of the problem it covers and at what cost per case. A system that lets the same team cover everything is a different business case from one that replaces them.

"The vendor's number is too high." It usually is. Replace it with your own baseline and your own low-end estimate.

What to do next

Pick one process, size it with the method above, and use the result to set the success criteria of a PoC. That turns a technology conversation into a financial decision, which is the conversation the board actually wants to have.