How to Calculate the Return on an AI Process

"Will this pay for itself?" is a reasonable question and it deserves a real answer rather than a case study from a company that looks nothing like yours. The calculation is not difficult, but it has to include the terms people usually leave out.

The naive version

The calculation most people start with looks like this:

Forty invoices per day, six minutes each, equals four hours daily. Automate it and save four hours a day.

This is wrong in both directions, which is why it is a poor basis for a decision.

What it overstates

You will not eliminate the work, you will change it. If review takes ninety seconds per document instead of six minutes handling it, you have saved four and a half minutes, not six. Genuine full automation without review exists, but it is rarer than vendors imply and appropriate for a narrower set of processes.

Not everything will be handled. A realistic system handles the straightforward majority and escalates the rest. If eighty percent goes through automatically, your saving applies to eighty percent — and the remaining twenty percent are usually the slow, complicated cases, so the average time of what remains goes up.

Saved minutes are not saved money. Freeing four hours across five people does not reduce your payroll. It converts to value only if those hours go to something worthwhile, or if they absorb growth you would otherwise have hired for. That may well be true — but say so explicitly rather than counting phantom salary.

What it understates

Waiting time often dwarfs handling time. Six minutes of work may sit in a queue for two days. If automation removes the queue, the business effect — faster invoicing, faster response, faster cash — can exceed the labour saving considerably. This is frequently the larger number and it is almost always omitted.

Error costs are real. If manual handling produces occasional mistakes with a known cost, consistent handling has value beyond time.

Capacity has option value. A process that no longer breaks when volume doubles is worth something even in a month where volume does not double.

The costs people forget

  • Build cost — the obvious one, and the one people plan for.
  • Ongoing running cost — usage-based charges that scale with volume.
  • Review labour — the new job you have created.
  • Maintenance — processes change, source systems change, and the integration must follow. Budget for this annually rather than pretending it is finished at handover.
  • Your own time during the project — specification, testing and correction all consume the time of the people who know the process. This is a real cost and it lands on your best people.

A more honest formula

Annual benefit equals (volume × share handled automatically × time saved per item × realistic hourly value) plus any measurable effect from faster turnaround or fewer errors. Annual cost equals running cost plus review labour plus maintenance. Compare that against the build cost to get a payback period.

If the payback period comes out beyond about eighteen months on assumptions you had to stretch, treat that as the project telling you something. There is usually a better candidate elsewhere in the company.

The decision this actually informs

The point of the exercise is not to produce a number for a slide. It is to find out which of your candidate processes is clearly the strongest — and to notice, before committing, when none of them are.

All Articles
Let’s Talk

about the process
AI should run.