Here is the promise of back-office automation: the machine takes the repetitive work, and your people are freed for higher-value tasks. The first half comes true. The second half rarely does — because of what "the work that's left" actually is.
Start with the numbers everyone quotes as good news. With currently demonstrated technology, roughly 42% of finance activities can be fully automated and a further 19% mostly automated [1]. The routine, in other words, is largely a solved problem. But notice what those numbers imply about the remainder. The tasks automation handles best are the standardised, high-volume, rules-based ones — the easy majority. What survives automation is the opposite: the non-standard, low-volume, judgment-heavy cases. The exceptions.
The inversion: the tail becomes the business
Most operating models are still designed as if exceptions are noise — a small deviation from the "happy path" to be cleared and forgotten. Automation inverts that. When the happy path runs itself, the exceptions are the path your people spend their day on.
Locate your own team on the spectrum below. Where does most of their actual working time go?
Where does the work that's left actually sit?
The nature of the remaining work
Where does most of your team's day now go?
You are entering the exception economy
The centre of gravity is shifting to cross-functional exceptions. This is where handoffs and lost context quietly tax you — design the routing and ownership before volume grows.
- 1High-volume transactions
Invoice capture, matching, standard postings — the natural home of rule-based automation.
- 2Structured reconciliations
Repeatable matching with clear rules; largely automatable, with a small review queue.
- 3Cross-system exceptions
Blocked invoices, mismatches, missing context — resolution needs several systems and people.
- 4Judgment calls
Novel cases, materiality, policy interpretation — the work that defines a good operator.
As automation matures, teams migrate rightward — and the operating model has to migrate with them.
Wherever you landed, the direction of travel is the same: rightward. The uncomfortable part is that the right-hand side is where traditional operating models are weakest.
Why the tail is so expensive
Exceptions are costly for reasons that have nothing to do with volume. They are cross-functional (they need procurement, tax, treasury, and a business owner in the same conversation), they are context-hungry (the answer isn't in one system), and they resist the very standardisation that made the routine cheap.
The data shows how thin the "fully solved" layer really is. In a typical record-to-report process, only about a fifth of tasks are fully automatable and nearly half are mostly automatable — which means a human still closes the loop on most of them [2]. And rule-based automation, by design, breaks the moment a case leaves the rules: it clears the standard invoice but stalls on the one where cumulative volumes should have triggered a lower price tier — an exception only visible across many documents [3].
Exceptions as failure vs exceptions as a capability
The strategic error is treating every exception as a defect to be stamped out. Some are. But many are permanent features of a complex business — new products, edge-case contracts, genuine judgment. The winning move is to stop fighting the category and start building for it.
Exceptions as failure
The default model
Every exception is treated as a defect off the happy path — cleared and forgotten. The category is never designed for, so it quietly clogs the same queues as routine work.
- What an exception is
- Noise off the happy path
- Where handled
- Wherever it lands, ad hoc
- Who owns resolution
- Whoever is free
- What you measure
- Straight-through rate
- What compounds
- Backlogs, rework, key-person risk
The tail silently absorbs your best people and your risk.
Exceptions as a capability
The advantageThe designed model
Exceptions are treated as a permanent, valuable category with its own designed path — triaged, routed, instrumented, and fed back into process design.
- What an exception is
- A permanent, valuable category
- Where handled
- A deliberate judgment layer
- Who owns resolution
- A named owner, by type
- What you measure
- Exception rate, aging, recurrence
- What compounds
- Faster resolution, a redesign backlog
The tail becomes a managed capability — and a source of advantage.
How to industrialise the exception
You cannot automate the exception away — but you can make the exception itself a well-run, instrumented process. That is a different discipline from automating the routine, and it runs in this order.
Industrialising the Exception
How to Run the Tail as a Capability
Tap a play to see why it matters and how to run it
Triage every item the moment it arrives: does it fit the rules, or not? The routine goes straight to automation; the exception goes to a designed path.
Why it matters
Most operations blur the two and let exceptions clog the same queue as routine work — so both slow down and neither is measured properly.
In practice
Add an explicit classification gate at intake. Route "fits the rules" to straight-through processing and "does not" to the exception path, with different SLAs.
That last step is the one most organisations skip, and it's the one the evidence rewards most. The biggest back-office gains came not from bolting automation onto existing steps, but from redesigning the process itself — grouping automatable tasks, eliminating handoffs, and resequencing approvals [2]. And the discipline of defining where human judgment is required is precisely what separates the organisations getting real value from AI from those still stuck in pilots [4].
Where does your operating model stand?
Before the closing argument, locate yourself honestly. The questions below map to the four plays above — the pattern of your answers shows whether you are still optimising the solved problem or genuinely running the tail as a capability.
The Exception Readiness Assessment
Is Your Operating Model Built for the Tail?
When an item does not fit the rules, what happens to it?
The question that matters
The routine is a solved problem — and a solved problem is, by definition, not a source of advantage. Anyone can buy the same tools and automate the same 42%.
Your advantage now lives entirely in the tail: how well you triage, route, resolve, and learn from the exceptions that no tool can standardise. Stop pouring your best energy into optimising the part everyone can automate. Build the capability to run the part no one else can.
Sources
- McKinsey & Company. Bots, algorithms, and the future of the finance function. January 2018.Using McKinsey Global Institute methodology, currently demonstrated technologies can fully automate 42% of finance activities and mostly automate a further 19%.View source
- McKinsey & Company. What does automation mean for G&A and the back office?. 2018.In a typical record-to-report process ~20% of tasks are fully automatable and nearly 50% mostly so; the largest gains came from redesigning processes — grouping automatable tasks, eliminating handoffs, and resequencing approvals — not automating existing steps.View source
- McKinsey & Company. AI in finance: How finance teams are putting AI to work today. 2025.Rule-based automation handles repetitive tasks (invoices, reconciliations); agentic AI is needed to orchestrate exception-laden workflows such as the close, and to catch value leakage that only appears across multiple documents.View source
- McKinsey & Company (QuantumBlack). The State of AI: Global Survey 2025. November 2025.AI high performers are far more likely than others to have defined processes for when outputs need human validation — one of the top factors distinguishing them.View source