AI changed the economics of automation. Most finance teams haven't repriced.

That looks like a failure rate, but it more likely tracks how AI is getting rolled out in finance orgs: tooling that makes subject matter experts and leaders more efficient in the work they were already getting done.

While those productivity gains are real, they distract from pointing AI at the true cost centers: the complex, high-volume operational processes, and the exceptions those processes generate.

When teams do target those processes, the common failure is the approach itself. A generation of automation work taught finance that systems are rigid and that changing anything means a request to IT's backlog. So the rational move was exhaustive upfront discovery that yielded a fixed "straight-through" target to justify the IT investment. Yet the biggest opportunities for automation typically can't be fully specified in advance, no matter how long discovery runs.

A well-designed AI system makes change cheap, fast, and safe. Process owners can start with the most expensive parts of the process and expand iteratively from there, creating value faster and compounding it over time. For those processes, AI changes both the cost to build the automation and the overall cost to run the workflow.

Map any operational finance process and you'll find it requires less expert judgment than anyone expects. Whether automating it pays off comes down to the number most proposals don't price accurately: the cost to run, and what exceptions actually cost.

The AI model is only one source of exceptions, and rarely is it the main one. A system can extract every field on a purchase order perfectly and still throw an exception because the PO itself is wrong. The master data doesn't match, a variance falls outside tolerance, or the handling rule was never written down.

If the finance department is using AI for reconciliation and the process runs at an 80% straight-through rate, one out of five reconciliations fall out as an exception requiring human review. In addition to the ongoing costs of the AI model, tokens, and IT resources, the organization will incur:

Exception economics raises an obvious question: why not wait for the model to get better? If AI already handles 80% of reconciliations cleanly, why not wait for the next release and close the gap?

Partly because the model was never the main source of exceptions. No new release fixes a wrong PO or a stale vendor master. The remaining 20% isn't a failure of the AI. It's a failure to identify which work AI should never have been doing.

The deeper reason has nothing to do with whether a model can get the right answer. Modern models usually can, and will even reach for a calculator on their own. The problem is how they get there.

A control is a fixed, reviewable procedure that shows how every output was produced. A model that reaches the right answer by a different path on each transaction isn't a control, even at 100% accuracy. It's a million small judgment calls, and verifying them means re-checking every output.

This is where many AI deployments quietly go wrong: they ask the model to do the math instead of asking it to write the code, or use a deterministic tool to do the math. Written once, reviewed once, versioned, then identical at any volume: that's what turns logic into a control instead of a behavior.

You wouldn't ask a junior analyst to recompute a complex amortization schedule from memory every month. Instead you'd have them build and pressure-test the formula and run it at volume. The analyst's value is knowing which formula to build, recognizing when an output looks wrong, and handling the cases the spreadsheet wasn't designed for.

An LLM is the analyst, not the spreadsheet. It's reliable at writing the logic, classifying exceptions, and routing decisions. It's not reliable as the calculation itself, running hundreds of thousands of times a month with zero tolerance for drift.

Before deploying AI on any finance process, map the workflow into three buckets.

A first pass at this map is worth making, and it will be incomplete. The goal isn't a perfect map before go-live; it's a system that finishes the map as it runs.

Once you know how the work within the process needs to get done, you need a system that coordinates the work at scale: classifying tasks, executing or escalating them, and recording what happens along the way. That creates the improvement loop required to push the cost curve down over time.

Manufacturing solved this problem a century ago. Sakichi Toyoda's looms wove automatically, but the real innovation was knowing when to stop: a broken thread halted the machine instantly, so defects never traveled downstream and one operator could supervise dozens of looms instead of watching one.

A core principle Toyota built its production system on is jidoka, or automation with human intelligence. Machines run the routine work and stop the moment something is abnormal, so operators fix the root cause. Instead of piling on workarounds, the fix becomes the new standard, and the line never trips on that thread again.

Back-office processes can run the same way, but it requires full visibility into how work gets done and the ability to reconfigure it safely on the fly. Coordinator-driven systems enable this, turning operators into managers of the system rather than the work itself.

For most finance and accounting processes, 100% automation shouldn't be the target, for two reasons: economics and risk. Automating complex finance processes can significantly reduce exceptions, but it won't eliminate them altogether.

First, economics. The exceptions left at the end are the rarest and most idiosyncratic, so the cost to automate each additional one rises while the review labor it displaces stays flat. Somewhere short of 100%, automating the next exception costs more than reviewing it, and stopping there is the correct call, not a compromise.

Second, risk. The last cases are the ones nobody can write a rule for yet, which makes them the hardest to verify. And a wrong call in these processes doesn't stay contained. The deliberate move is to pick the degree of automation each process warrants, on a spectrum from fully manual to fully automated.

With economics and risk in mind, pick the degree of automation the process warrants and price that move before you commit to it.

Every point on the spectrum, including the last, keeps a human in the loop. What changes is the work the humans do.

Finance leaders hear the same question from their boards: "Why don't we have AI doing X yet?" The answer is almost always that the initiative was planned around the easy 80%, and nobody priced the rest.