Price the Exceptions

The steering committee slide said 99.25%. That was the share of 4.6 million transactions per period that a betting and gaming operator's reconciliation system matched without a person. It was a good number and a true one. The finance team lead added the other side of it: the remaining 0.75% was still around 34,500 items every period, and clearing them now took her team's whole day.

That remainder is where the economics of automation live. The matched share tells a sponsor the system works. The remainder tells the finance director what the operation costs to run, where the risk sits and whether it will survive next year's growth. Business cases for AI in operations are often built on the first number, while the operation pays for the second.

An automation rate counts cases, not cost

A rate treats every case as equal. A timing difference that clears itself the next morning and a short payment from a payment provider that needs a formal dispute each count as one exception. The first costs nothing. The second costs a senior analyst's afternoon and, if missed, real money. Averaging them hides what a finance director most needs to know.

The exception ledger prices every cause

For every workflow we run, we keep an exception ledger. It is not a queue report. It is a small table, one row per cause, with five columns measured from the case record and never estimated in a workshop. A cause with no measured handling time is marked unknown, not guessed.

• Frequency per period.
• Handling time, from the moment a person opens the case to the moment it closes, excluding waiting.
• Handler cost, because an hour of a controller is not an hour of a clerk.
• Loss when missed, where past cases show it: a duplicate paid, a fee never recovered.
• Where the root cause sits: the system's rules, master data, a counterparty's format, or genuine judgement.

The first four multiply out to a cost per cause per period. In the ledgers we have kept, a handful of causes have carried most of the cost, and they were often not the ones expected at the start.

The ledger is only as good as its cause codes, and the codes need an owner on the finance team, not in engineering. Watch the row called "other". When it becomes one of the largest rows, the taxonomy has stopped describing the work, and splitting it comes before any new rule. The first version of the list also comes from watching people clear the queue, not from the process document. The documented process rarely mentions informal workarounds, such as coding small invoices without a purchase order to a general account and flagging them, and each of those habits is a cause with a cost.

The fifth column decides the fix

Each location of a root cause has one sensible response.

If it sits with a counterparty or in master data, the fix is upstream. A reference shortened in transit between two systems, an invoice without a purchase order number, a customer recorded three times: automating around these builds permanent complexity around something that can be corrected at the source. A request to a counterparty or a master data clean-up is usually the cheapest exception reduction available, and it is easy for an engineering-led project to overlook, because the fix is not code.

If it sits in rules nobody wrote down, such as a fee calculation or a netting convention, it is a candidate for automation, subject to the payback rule.

If it is genuine judgement, such as a dispute or a write-off, it stays with a person, and the investment goes into making that person fast: cases grouped by cause, evidence attached, an owner and an age on every item. We do not automate write-offs or disputes to lift the rate. Small repeating differences are often the first sign of a larger problem, and judging them is what finance is for.

New automation must pay back within a year

Each rule added for a smaller, stranger cause costs more to build, test and maintain than the last, and raises the chance of two rules interacting badly. So every proposed rule gets a price: the engineering, the test cases it adds, a year's maintenance. It is set against the ledger's cost for that cause. A rule that does not pay for itself within the year is not built, and the cause stays with a person.

Rules also have to keep earning their place. Each one logs how often it fires. A rule that has not fired across two closes is reviewed and, unless it guards against a rare but expensive loss, removed. Unused rules are code nobody remembers, waiting to interact with the next change. Retiring rules is how the ledger stays an asset rather than turning into maintenance overhead.

Showing a sponsor this calculation usually changes the debate about chasing a higher rate. The question tends to move from "can we automate this" to "is this cause worth a rule".

The remainder gets harder as the rate rises

Business cases often assume the remaining exceptions look like the old ones, only fewer. In practice they rarely do. Rules remove the frequent, simple causes first, so every point of automation shifts the remainder towards cases that are rare, ambiguous or disputed. Average handling time per exception rises even as the count falls.

We forecast this from the ledger before each new rule goes live: which causes it removes, and what handling time and seniority the remaining causes will need. The forecast usually shows fewer people clearing routine items and more senior time on disputes, counterparty conversations and rule ownership. The easy cases that used to train new staff are gone, so training moves to disagreement reviews and rule changes. That change of role should be planned before the rule goes live, not discovered after.

None of this is new outside finance. Lisanne Bainbridge described it for process control in "Ironies of Automation" (1983): automation takes over the tasks people could do easily and leaves them the tasks nobody could automate, while removing the everyday practice that kept their skills sharp. Her conclusion is the one sponsors least expect: the most successful automated systems, the ones that rarely need a person, may need the greatest investment in training the people who remain. More than forty years later, reconciliation teams meet the same irony at month-end.

Growth adds causes, not only volume

Volume growth is cheap. More of the same transactions pass through the same rules at almost no extra cost. What growth really adds is new causes. A new payment provider brings its own settlement file and fee structure. A new market brings a currency, local tax treatment and a bank that formats references its own way. An acquisition brings a second chart of accounts. Each is a new row in the ledger, and each starts in the expensive state: unautomated, unfamiliar, handled by whoever is most senior.

This is why an operation that looks comfortable can struggle after an expansion that barely moves its total volume. When a client plans growth, we list the new sources, markets and counterparties it brings, add a ledger row for each in advance, and budget the time to sort each one into upstream, rule or person before it arrives. How fast a business can grow is set by how quickly new causes are priced and handled, not by how fast the matching engine runs.

Run the ledger, not the rate

A rising automation rate with a rising cost of the remainder is not yet progress. After go-live, the ledger is the clearest view of the operation, and it is the first thing we ask to see in any review of an automated finance process.