Humans as verifiers, not exception handlers

The queue at the end of the pipe

Here is the shape of it, whatever the tooling. Transactions arrive. A rule set, a model, or some combination of the two assigns each one a category, a client, a project, an approver. Most get handled. A residue does not: the vendor nobody has seen before, the description that reads like three things at once, the amount that trips a threshold. That residue lands in a queue, and somebody works the queue.

It is an appealing design because it is measurable. Queue depth, time to clear, items per hour. You can put it on a dashboard by Friday. Most of the agency finance automation we are asked to review is built exactly this way, and the throughput numbers are usually excellent.

The trouble is what the design assumes. It assumes that the system's own confidence is a reliable guide to where the errors are. Sort into handled and unhandled, watch the unhandled pile, and the handled pile takes care of itself. Deming spent thirty years arguing the general version of this point: you cannot inspect quality into a product, and inspecting only what has already been rejected tells you nothing about what was accepted. Nothing about that changed when the sorting got done by software.

The errors you care about are confident

Think about how a categorization rule actually goes wrong at an agency. It is almost never a case the rule found confusing. It is a case the rule found easy and got wrong for a reason nobody encoded.

A freelance editor invoices through an LLC whose name looks like a software vendor, so eighteen months of production cost sits in subscriptions. A pass-through media buy gets coded to revenue because the deposit looks like every other client deposit, and the gross-to-net picture quietly stops being true. A retainer client's out-of-scope work gets coded to the retainer project because that is where their work always goes, so the overrun never appears and the renewal gets priced off a fiction. Every one of those is processed at high confidence, on the first pass, without hesitation. None of them ever reaches the queue.

Say a categorizer processes four hundred transactions a month, flags twelve for a person, and handles the other three hundred and eighty-eight itself at ninety-six percent accuracy. Sixteen of those are wrong, and none of them reach the queue. Your exception handler is looking at the twelve the system flagged, of which maybe two were genuinely hard. And a rule error does not stay one error, which is the part that gets missed. A person miscoding by hand makes a mistake. A rule miscoding does the same thing every month until somebody notices, which is why automation multiplies rather than repairs.

So the honest description of a well-run exception queue is that it is a measure of the system's self-awareness. Useful. It is not a control.

Four things that separate a verifier from a handler

Often the same person, at the same desk, on the same salary. The distinction is in how the seat is designed, not in who is sitting in it.

How to build the seat

None of this requires better technology, which is fortunate, because most agencies already have more automation than they have verification. It requires four decisions made on purpose.

Write down what correct means, before you automate anything. Not the process. The output. What a correctly coded media buy looks like, what belongs in project cost and what does not, when a timesheet entry is billable. If that document does not exist, verification is a matter of opinion and the loudest opinion wins. This is the part of controller work that survives every wave of tooling, and it is the part agencies most often skip because the bookkeeping appeared to be working.

Sample the confident output on a fixed schedule. Twenty-five transactions a month, drawn at random, checked against the standard, error rate written down. It takes under an hour and it is the only thing in this article that will tell you whether your automation is any good. Sample size matters far less than doing it every month, because the value is in the trend and in seeing the same category fail twice.

Give the verifier authority over the rule, with a record. They change it, they note what changed and why, the change gets reviewed at month end. Authority without a record is how you get undocumented drift. A record without authority is how you get a very tidy list of problems nobody fixed.

Watch whether the queue is shrinking. A healthy exception queue gets smaller over time, because each exception either becomes a rule or reveals one that was wrong. A queue that holds steady month after month is not a workload. It is a design that has stopped learning, and the person working it has been assigned to absorb the difference indefinitely.

The seat this creates is senior

The uncomfortable implication is that the exception-handler role should not exist as a job, and in most agencies it currently is one, held by somebody capable who has been given a queue instead of a scope. That is a bad outcome for the agency and a worse one for the person. It is all residue, no ownership, and no route to being able to fix the thing generating the work.

The verifier seat is different in kind. It needs someone who can hold a standard, judge whether a number is credible before it goes in front of an owner, and reason about why a rule failed rather than just that it did. At a digital marketing agency running pass-through media, that judgment is the difference between a gross revenue figure you can bank a hiring decision on and one you cannot. It is not a data entry job that got automated. It is the judgment layer that was always underneath the data entry, and it was easier to see back when a person touched every transaction.

Which is why the honest answer to "will automation reduce my finance headcount" is: it will change what the headcount is for. The processing hours compress. The verification and standard-setting hours do not, and they get more valuable as volume rises, because a bad rule now runs at scale. An agency that cuts the seat because the transactions stopped needing hands has automated away its only remaining check. What it should be doing is moving that seat up, and putting the recovered hours where the CFO layer can use them: pricing, capacity, the client-level profitability nobody has had time to look at.

Where to start

When a finance function already has automation running, the exception queue is the wrong place to start. The better first pass is a sample of the confident output against whatever written standard exists, and where no written standard exists, that is the finding that matters most. It is a dull exercise and it is where the real errors are, because the queue has usually been worked diligently for months by someone who was never given anything else to work with.

Then build the loop: a standard, a monthly sample, a named person with the authority to change the rule, and the error rate on the same page as the throughput. That is Plan-Do-Study-Act applied to the part of the process everybody assumed was finished, and it is the study step that nearly always turns out to be missing. Most automations we inherit have a plan and a do, and a dashboard proving the do is fast.

The reason to care goes past accuracy. A person who verifies is a person whose judgment the system depends on and improves from, which is a role worth holding. A person who handles exceptions is a queue with a name, and that fact eventually shows up in the data, because the process shapes the behavior and not the other way round. If the aim is a system where the people in it are the point, then how you place the human relative to the machine is not an HR question. It is the design.

Common questions