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, which matches payments against the company's own records, matched without a person. A good number, and true. The finance team lead added the other side: 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, where the risk sits and whether it survives next year's growth. Business cases for AI 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, a senior analyst's afternoon and, if missed, real money. Averaging hides what a finance director most needs to know.

The exception register prices every cause

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

• Frequency per period.
• Handling time, from when a person opens the case to when it closes, excluding waiting.
• Handler cost, because an hour of a controller isn't an hour of a clerk.
• Loss when missed, where past cases show it: a duplicate paid, a fee never recovered.
• Where the cause sits: the system's rules, the basic records such as customer and supplier lists, another company's file format, or genuine judgement.

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

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

Where the cause sits decides the fix

If it sits with another company or in the basic records, the fix is at the source. A reference shortened between two systems, an invoice without an order number, a customer recorded three times: automating around them builds permanent complexity around something fixable where it starts. A request to the other company or a records clean-up is usually the cheapest reduction, and engineering-led projects overlook it because the fix isn't code.

If it sits in rules nobody wrote down, such as how a fee is calculated or which amounts are offset against each other, it's a candidate for automation, subject to the payback rule.

If it's genuine judgement, such as a dispute or writing off a debt, 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 don't automate them 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 clashing. So every proposed rule gets a price: the engineering, the test cases it adds, a year's maintenance. It's set against the register's cost for that cause. A rule that doesn't pay for itself within the year isn't built, and the cause stays with a person.

Rules also have to keep earning their place. Each logs how often it fires. A rule that hasn't fired across two month-ends is reviewed and, unless it guards against a rare but expensive loss, removed. Unused rules are code nobody remembers, waiting to clash with the next change. Removing them keeps the register an asset rather than a maintenance burden.

Showing a sponsor this calculation usually moves the question 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. They rarely do. Rules remove the frequent, simple causes first, so every point of automation shifts the remainder towards cases that are rare, unclear or disputed. Average handling time per exception rises even as the count falls.

We forecast this from the register before each new rule goes live: which causes it removes, and what time and seniority the rest will need. It usually shows fewer people on routine items and more senior time on disputes, conversations with other companies and owning the rules. The easy cases that trained new staff are gone, so training moves to reviewing disagreements and rule changes. That change of role should be planned, not discovered.

Lisanne Bainbridge described this for industrial process control in "Ironies of Automation" (1983): automation takes over the tasks people could do easily and leaves them the ones nobody could automate, while removing the daily 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. Over forty years later, finance teams meet it 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 fees. A new market brings a currency, local tax rules and a bank that formats references its own way. An acquisition brings a second way of structuring the accounts. Each is a new row in the register, and each starts in the expensive state: unautomated, unfamiliar, handled by whoever is most senior.

So an operation that looks comfortable can struggle after an expansion that barely moves its volume. When a client plans growth, we list the new sources, markets and partners it brings, add a row for each in advance, and budget the time to sort each one into source, 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 runs.

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