← Insights
Finance and Investment

Talking about AI in dollars

Count the full cost of a use case and distinguish a promising estimate from a result finance can verify.

OperateIQ·3 min read·July 2026

A model can perform well in testing and still have a weak business case. Accuracy matters, but the funding question is what changes in the business and whether that change is worth the cost.

Start with a measure finance and the business owner already understand: the cost of handling an order, time spent matching invoices, lost sales from stockouts, or margin on a quote. Explain how the proposed system could change that measure and what has to happen for the benefit to be realized.

Be clear about the objective

Cost reduction and revenue growth need different evidence. A cost case should identify which work or expense would fall. A revenue case needs a credible explanation of how a better decision leads to a sale or protects margin.

Assign an owner to the benefit. The technology team may deliver the application, while the operating team is responsible for changing staffing, pricing, or the customer process. The business case should make that dependency visible.

Separate the sources of value

Operating cost. Estimate the work removed, overtime avoided, external spend reduced, or additional volume handled with existing capacity. Time saved is not automatically cash saved. Explain how the business intends to use the released capacity.

Revenue and margin. Identify the connection between the change and the commercial result. Fewer stockouts may preserve sales; better quote information may reduce avoidable discounting. State the assumptions and check them after release.

Risk reduction. Describe the error or incident the control is intended to prevent. Keep uncertain avoided losses separate from directly measured savings.

Reuse. A data connection or shared release process may serve several projects. Show which later projects need it and avoid charging its full cost to each one, or counting the same benefit more than once.

Include the whole cost

The build is only part of the bill. Include data preparation, integration, testing, user training, review work, support, and ongoing infrastructure or model use.

For generative AI, usage costs can vary with the amount of information processed, the model selected, and the number of steps needed to finish a task. Track spending by use case and report a unit the business recognizes, such as cost per completed document review. Include failed attempts and human review in that cost.

A low price per model call means little if the workflow needs many calls and still requires someone to redo the work.

Use early funding to test the uncertain parts

A pilot should answer a question that could change the investment decision. Can the available records support a useful match rate? Will users act on the recommendation? Does the time saved exceed the review effort?

Agree the budget, test criteria, and next decision before the pilot starts. Update the business case with the results, including disappointing ones. A useful pilot can end with a decision to stop.

Report estimates and results separately

Show expected value, measured benefit, spend to date, and forecast cost to complete. Ask finance to review the benefit calculation and identify any part still dependent on adoption or further process changes.

Review shared costs across the program as well as individual projects. A regular funding discussion should make it possible to redirect money while there is still time to use it elsewhere.

Talk through your own project.

Tell us what you are trying to change, what you have tried, and where you could use help.

MORE WRITING →