The exception is the business.

The invoice is for 100 boxes at $10 each, $1,000 in all. The purchase order behind it also says 100 boxes at $10. The receiving record, the document that says what actually came through the door, shows 60. Clipped to the invoice is a handwritten note: "Forty went to the other site." The example is constructed for this essay and every number in it is invented, but anyone who has worked in accounts payable will recognize the shape of it. The arithmetic is fine. What the paperwork cannot do is establish that all 100 boxes arrived.

An automated matching system, the kind that compares invoices with orders and receipts and pays the ones that agree, would do exactly the right thing with this invoice. It would refuse to clear it and set it aside. That is a success: the system has found a case it cannot settle. But finding a case is not settling it. Someone still has to locate a second receiving record, establish whether the delivery happened and reconcile the evidence, and the note is a lead, not proof. A demonstration in which every invoice matches and sails through can show real capability while saying nothing about this part of the work.

My argument is that automating the routine path does not finish the design of a process. It changes the work left for people, and that remaining exception work needs a design of its own. When automation takes the straightforward cases, the human queue fills with incomplete records, conflicting evidence, unusual circumstances and decisions no rule yet covers. Fewer items need not mean proportionately less effort, expertise or time. This is not a claim that automation fails, or that exceptions are precious or permanently beyond machines. Automation can reduce both kinds of work, and some exceptions should simply disappear, because their cause is a bad input, an unnecessary rule or a broken handoff. The title means something narrower: a business has to be able to meet its obligations when the standard route cannot complete the case.

Last week's essay asked who gave the machine permission to act. This one begins where that question ends. Once a system hands a case to a person, what does it take to resolve it?

What makes an exception

It helps to be precise about the word. An exception is not a property of the shipment. The delivery may be perfectly legitimate; the forty boxes may be sitting at the other site exactly as the note says. The exception is the gap between what this process requires before it pays, a receipt for everything invoiced, and what its records currently establish. Change the process and the same shipment might not be an exception at all.

Read a queue of such cases and the gaps turn out to have different causes. Some are missing evidence: the second receiving record exists somewhere, or should. Some are recurring defects: deliveries to the other site are routinely logged late, so the same mismatch turns up every week. Some are unsettled policy: nobody has decided what should happen when goods arrive at a location other than the one on the order. Some are genuinely unusual and need investigation and judgment. And some are made by the automation itself: a misread quantity, a wrong classification, an action that has to be undone.

The remedy depends on the cause. No amount of better reasoning, human or machine, can manufacture a receipt that was never recorded. A change to how the other site logs its deliveries can remove a whole class of exceptions at once. A policy owner can settle in an afternoon an ambiguity that would otherwise be argued case by case. Only what remains needs informed investigation. A queue treated as one undifferentiated pile marked "manual review" hides these differences, and the cheapest fixes with them.

There is a second caution. The sorting is imperfect too. A false positive sends a sound invoice to a person for nothing; a false negative lets a problem invoice through without anyone looking. A low exception rate is therefore not, by itself, evidence that a process works. It may mean the filter is letting the wrong cases pass.

Count the minutes, not just the cases

The number most often quoted for automation is volume: the share of cases that go through without a person. It is a real number and a useful one, but it can hide where the work goes. Figure 2 is a deliberately simple model. A team receives 1,000 cases a week. Nine hundred are routine and take a person two minutes each. One hundred are exceptions and take twenty minutes each. Before any automation, routine work takes 1,800 minutes a week and exceptions take 2,000. The exceptions are a tenth of the cases and more than half of the effort.

Now automate the routine cases, and have a person check a 10 percent sample of the automatic ones at a minute apiece. At full coverage, 90 percent of incoming cases are processed automatically, and people's processing time falls from 3,800 minutes to 2,090, a reduction of 45 percent. That is a real gain, and the model shows it plainly. But 55 percent of the original effort remains, and almost all of it is the same 2,000 minutes of exception work, which has gone from just over half of people's time to 96 percent of it.

Read the model for what it shows and no more. Automation has not created extra work: the exceptions are exactly as numerous and as slow as before, and total effort has fallen by almost half. What changed is the composition of the job. The people who remain spend nearly all their time on the hardest cases. Averages move with that mix, too. The time it takes to close a case rises as the easy cases leave, even if nobody works any slower, which is worth remembering before such a number lands on a scorecard. Nor do the minutes translate directly into headcount. When work arrives, which skills it needs, how long cases wait on someone else and what else people are responsible for all matter as much. And the 90 percent is not "90 percent touchless": in the model, 90 of the automatic cases are still opened by a person. Better tools, better data and better processes could shrink the blue work as well, a possibility the model leaves out on purpose so that the change in composition is easy to see.

Design the handoff as work

Go back to the invoice. "Send it to a person" is not a design; it is the absence of one. The design question is what arrives with the case. I would want a short resolution packet: the invoice and the order, the receiving evidence, the exact discrepancy (100 invoiced, 60 recorded, 40 unexplained), what has already been tried, and the specific fact or decision that would close it. If a model has proposed an explanation, say that the forty boxes went to the other site, the packet should show it as a proposal, kept apart from the source documents, so nobody mistakes a plausible story for evidence. And the case needs a named owner and a place to record how it ended.

The person who receives it needs time, relevant knowledge, access to the other site's records and a way to reach the colleague who can find them. They need the authority to act on what they find, which was the subject of last week's essay, but authority alone resolves nothing. Notice, too, that effort and elapsed time are different quantities. Twenty minutes of investigation can sit open for days while the other site looks for its paperwork. The age of a backlog measures waiting as much as working, and treating the two as one leads to the wrong fixes.

Keep the expertise alive

In 1983 the psychologist Lisanne Bainbridge published a short paper called "Ironies of Automation." She was writing about industrial process control, with examples from the flight deck, and her central observation was that a designer who tries to remove the operator still leaves the operator "the tasks which the designer cannot think how to automate": watching the system and taking over when something goes wrong. The irony is that removing the routine work also removes the practice that keeps skills and knowledge fresh, so the operator is least practiced at exactly the moment the job demands the most skill.¹ An accounts-payable team is not a control room, and the analogy should not be pushed far. But the structure is familiar. A role made entirely of the cases nobody could standardize is a demanding role, and it needs deliberate support.

It would be too easy to conclude from this that machines take the simple tasks and people get everything hard. David Autor and Neil Thompson argue, in a working paper dated June 2025, that what automation does to a job depends on which of its tasks it removes. Take away the job's inexpert tasks and what remains demands more expertise; take away its expert tasks and the job becomes easier to fill. Their running example is close to this essay's invoice. Accounting clerks lost routine work such as recording transactions and reconciling statements, kept problem-solving tasks that need specialized knowledge, and between 1980 and 2018 saw employment fall substantially while wages rose. Inventory clerks, whose remaining tasks needed less training, saw the opposite.² Automation can raise the expertise a role requires or lower it, depending on what is left.

And AI need not only take the easy work away. In a study of 5,172 customer-support agents, Erik Brynjolfsson, Danielle Li and Lindsey Raymond found that an AI assistant raised the number of issues resolved per hour by about 15 percent on average, with the largest gains, in both speed and quality, among less experienced agents.⁴ Assistance can help people with the hard cases, not merely remove the easy ones.

What would deliberate support look like? I would propose three things, as design choices rather than interventions the studies have tested in a finance office: a library of resolved cases, reviewed so that the reasoning and evidence behind good decisions can be shared; supervised practice, so that newer staff meet hard cases before they handle them alone; and a dependable way to reach experienced colleagues. The aim is not to turn every judgment into a rule, nor to depend on the one employee who knows every workaround. It is to make useful reasoning visible.

Let the exceptions improve the process

Exceptions carry information about the process that produced them. If the other site's deliveries are logged late every week, the cheapest fix is to change how that site records them, not to fund the same investigation fifty-two times a year. For that to happen, the record of each exception has to say what kind it was: missing data, a recurring defect, a policy question or a genuinely unusual case. Patterns appear only when the cases are classified.

Changes should be tested before they are promoted into the routine path, and caution runs the other way too. One person's discretionary decision about one odd case does not automatically become general policy, or trustworthy training data for the next model. Three outcomes are all legitimate: an exception can be eliminated, it can be made easier with better assistance, or it can remain a matter for human judgment. Not every exception should end up automated.

Objections, considered

The exceptions are only a small percentage. In volume, often true, and volume matters. But volume is not effort, and effort is not consequence. In the model, exceptions are a tenth of the cases and more than half the minutes before automation, and nearly all of them after. Not every small minority of cases consumes most of the work, but a process cannot be judged by counting cases alone.

Better models will handle these cases too. Some of them, certainly. Boundaries move, and assistance can shorten investigations. But capability is uneven. In a field experiment with 758 consultants at Boston Consulting Group, Fabrizio Dell'Acqua and colleagues found that access to GPT-4 made consultants markedly more productive on tasks within its capabilities, yet on a task selected to fall outside them, those using it were 19 percentage points less likely to reach a correct solution than those without it.³ That is one experiment, with one model and selected consulting tasks, not a measure of invoice processing. Its lesson is narrower: success on one class of work does not establish competence on all of it. And some exceptions need a fact or a decision, not a more fluent answer. The forty boxes are either recorded somewhere or they are not.

This is an excuse to preserve inefficient manual work. It should not be. The argument separates genuine judgment from avoidable friction. Repeat defects should be eliminated, unnecessary rules simplified, and the resolution route measured to see whether it is improving. A team ought to be able to show that its exception queue is shrinking wherever it can.

Humans make mistakes too. Agreed. Sending a case to a person guarantees nothing. Evidence, support, appropriate review and learning from outcomes matter for manual work as much as for automated work. The argument is not that people are reliable and machines are not. It is that the work left over deserves the same design attention as the work that was automated.

The process is only as complete as its route for the cases that do not fit.

Five questions about what remains

• What remains after routine automation? Which cases, how many, and how much of people's time they take.
• What makes those cases hard? Missing evidence, a recurring defect, an unsettled policy, or a genuinely unusual situation.
• Who has the evidence and the capacity to resolve them? A named owner with the documents, the time and the colleagues the case requires.
• Which recurring causes should be removed? An exception that appears every week is a process to fix, not a queue to staff.
• How would we know if cases wrongly pass through? The exception rate shows what was caught, not what was missed.

Back to the invoice with its note. The note is a good lead, and it is only that. Someone calls the other site. Perhaps the forty boxes were received there and logged a day late, in which case the second receiving record goes into the file and the invoice clears. Perhaps they never arrived, in which case it does not. Either way, the decision is recorded with its evidence. And if this is the third time this quarter that the other site has logged a delivery late, someone fixes the logging, so that next month's invoice never needs a note at all.