Pricing Exceptions: The Ledger Behind Finance Automation

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 looked at it and pointed out that the remaining 0.75% was still around 34,500 items, every period, and that her team now spent its whole day on them.

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. Most business cases for AI in operations are sold on the first number and paid for in 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 the only information a finance director needs.

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: our rules, the client's master data, a counterparty, or genuine judgement.

The first four multiply out to a cost per cause per period. In every ledger we have kept, a handful of causes carry most of the cost, and they are rarely the ones the project team expected at the start.

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 payment provider that truncates references, suppliers who leave out the purchase order number, one customer recorded three times: automating around these builds permanent complexity to compensate for something someone could simply correct. A request to a counterparty or a master data clean-up is usually the cheapest exception reduction available, and engineering teams skip it most often, because it is not engineering.

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.

Showing a sponsor this calculation ends most debates about chasing a higher rate. The question stops being "can we automate this" and becomes "is this cause worth a rule".

The remainder gets harder as the rate rises

Business cases assume the remaining exceptions look like the old ones, only fewer. They do not. 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.

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 progress. After go-live, the ledger is the operation, and it is the first thing we ask to see in any review of an automated finance process.