80 percent automation is not yet 80 percent savings

Matthias Terzer has written down how he decides whether an AI project is worth it. Three questions, in this order: Is it feasible at all? Does it solve a real problem for the customer? How high is the automation rate, and does it justify the effort?

The order is the best part. Whoever checks feasibility first is spared the projects that fail in month four on an endpoint that does not exist. And his expense-report example — a process that costs the whole company one hour a week is not an automation case, however elegant the solution would be — deserves a place above every desk.

On the third question I would count one small thing differently.

His rule of thumb reads: “An AI project really makes sense when it automates at least 80 percent of a process, and does so with high precision.” He qualifies it himself right away — 40 percent on a large process can be worth more than 80 on a small one. But that is exactly the point I would push further: the automation rate is a statement about the machine. The savings are a statement about the person who is still sitting at the desk afterwards.

Two mailrooms, both 80 percent automated.

In the first, the system delivers values without provenance. The clerk does not know which of the numbers belong to the safe 80 percent and which to the uncertain 20. So he reviews everything. Automation rate 80 percent, savings zero. Strictly speaking even negative, because checking someone else’s results is slower than typing your own.

In the second, the system says for every value where it came from — which page, which position, which confidence. Now the 20 percent turn into a work list. The rest passes through, and the human handles what is actually unclear. The same number on paper, a completely different month-end close.

The difference is not a question of the model. Both systems can use the same model. It arises before and after: in cleanly separating and classifying the intake, and in whether every extracted value points back to its source position in the original document.

In our production environments, header-field recognition is above 96 percent, and at a German logistics group 96 percent of freight invoices pass correctly on the first run. The number that matters more to the customer is not the 96, though. It is the time spent on the remaining four percent — and that is only small because the system can say which four percent they are.

So I would add a fourth question to Matthias’ three, one that comes after the third:

What does the rest cost? That is: how many cases remain, how long does one take, and — the question most often forgotten — does someone still have to look at the automated cases anyway? If yes, the automation rate is a figure for the data sheet, not for the calculation.

This can be quantified before the project, without a pilot: documents per month times minutes per document times fully loaded hourly cost, once for today and once for the expected rework. Anyone who puts zero minutes for the automated cases should be able to justify it.

And because the time horizon is longer than most calculations assume: a document from 2026 must be retained in Germany until the end of 2034. Whoever has to explain in 2032 how an amount came about needs the provenance of the value — not the model that produced it. Why eight years of retention and fourteen months of model lifetime do not fit together is written up separately (in German).

On the substance we agree, and his closing sentence stands unchanged: a good AI project is not an end in itself but an investment that has to pay off in real hours that real people no longer spend. I would only insist on actually counting those hours — instead of substituting the automation rate for them.

How the fourth question is answered in practice — with provenance for every value and a work list instead of a full review — is on the page for automated document verification. If you want to run the calculation for your own mailroom, you can do it in an intro call with real documents.