Your exception queue is growing: it is a defect list, not a headcount gap

Adding a clearer to a queue that is growing buys a slower growth rate and nothing else. Exceptions are not produced by chance: they are produced by deterministic rules firing on repeating inputs, which means the same supplier, the same document type and the same tolerance produce the same exception every time an invoice arrives. That is why an exception queue is almost never evenly distributed, and why the first move is a pivot table rather than a rota.

Cut the open queue by exception type against supplier, and again against legal entity or site. In a queue that is genuinely out of control, a handful of cells carry most of the volume, and each of those cells is a single upstream defect with a single owner. The rest of the queue is the working level the process was designed for.

Two pivots that decide whether you have a staffing problem at all

This takes an afternoon against the exception table and replaces the argument about headcount with a list of named defects. Run it before anything else, and keep it as a stored view rather than a spreadsheet somebody rebuilds each quarter.

1. Snapshot every open exception with type, supplier id, legal entity, receiving site, creation date, age in days and current assignee. Age in days, not a bucket label — buckets hide the shape.
2. Pivot type against supplier, sort descending by count, and add a cumulative share column. Read the point at which the running total passes 50% and 80%. If 80% arrives inside 10 cells, the queue is a defect list.
3. Pivot type against entity and site. A type that concentrates on one site but spreads across suppliers is an internal process fault; one that concentrates on one supplier across sites is an inbound document fault.
4. Plot arrivals and clearances per type per week for 8 weeks. Only types where arrivals exceed clearances are still generating; everything else is a backlog to burn down once, not a defect to fix.
5. Mark the first date each supplier-and-type pair appeared. Pairs first seen in the last 90 days indicate a change — a new supplier, a new template, a new tolerance — rather than a standing weakness.
6. Count items with more than 1 queue entry. Anything that left the queue and came back is being counted twice in every report you have read so far.

Five defects behind a queue that outruns its clearers

A queue is a symptom with an address. Every exception in it was created by a rule that will fire again tomorrow unless somebody changes the rule or the input.

The supplier who changed their invoice layout in March

The tell is a date discontinuity confined to one supplier: exceptions for that supplier were background noise until a specific week, and afterwards every invoice from them lands in review. Confirm it by reading per-field extraction confidence for that supplier before and after the date. A layout change shows up as 2 or 3 fields collapsing while the rest hold, which is quite different from a general accuracy drift.

Check the delivery channel before touching the model. A supplier who moved from an emailed invoice to a portal-generated PDF, or who started attaching 4 invoices to one message, has changed the intake stage rather than the document — the failure modes in turning an invoice mailbox into a pipeline. Where the supplier carries enough volume, the durable answer is to stop reading their document at all, which is the argument in invoice capture or a purchase-order flip for top suppliers.

A tolerance written against the wrong basis

A single company-wide percentage fails at both ends of the spend distribution. On low-value consumable lines it flags rounding as a variance; on high-value capital lines the same percentage waves through a difference nobody intended to accept. The pivot signature is unmistakable: one exception type, one spend category, many suppliers, and a difference distribution clustered tightly just outside the limit.

Basis matters as much as size. A tolerance applied to unit price, to the extended line and to the invoice total produce three different verdicts on the same document, and a rule that inherited its basis from whatever the previous system used is the most common cause of a category-wide flood. The rule object that fixes it is set out in price and quantity tolerance in invoice matching, and the underlying decision of when a difference may be waved through at all is argued in exact match against tolerance match for settlement lines.

One supplier, three vendor rows, and a match that cannot key

When the same supplier exists twice in the master, the purchase order attaches to one record and the invoice keys to the other, so a perfectly correct invoice cannot find its commitment. It surfaces as a missing-PO or unmatched exception type, spread across a single supplier's whole invoice population and unresponsive to any amount of reviewer effort, because the reviewer resolves it by hand each time and the next invoice repeats it.

Duplicate records are created, not born: a new remit-to address, a merged entity, a name spelled differently at onboarding. The field set that prevents it, and the aliases a matcher needs to survive the ones already created, are in the fields a vendor master record has to carry. Merging is the fix; a fuzzy name match in the matcher is a workaround that hides the defect from the pivot you just built.

Timing exceptions and returning items are inflating the count

Two categories in the queue are not really exceptions. The first is timing: an invoice that arrived before the goods receipt was posted is not a discrepancy, and routing it to a person on the first attempt guarantees the person will do nothing except wait. It belongs in a hold-and-recheck loop sized to the site's measured receipting lag, as set out in the invoice that arrived before the receipt posted.

The second is recirculation. An item that was worked, released and came back has consumed reviewer time twice and is counted twice in every report. The usual cause is downstream: an approval hop that resolves to nobody sends the invoice back to accounts payable rather than forward, which is the failure diagnosed in invoices that stall in approval. Until re-entries are separated out, the queue looks larger and less concentrated than it is.

The three exception types you must never engineer away

What clearing the top cells will not fix

Removing the top defects shrinks the queue; it does not tell you how the remaining queue should be run. Stages, single ownership per exception type, explicit exit criteria and an aging escalation are a separate design problem, covered in designing an exceptions-first approvals queue. Nor does it settle what to measure afterwards — a falling exception count can be bought by loosening tolerances, which is exactly the trap examined in chasing a touchless rate.

It also will not repair a capture stage that never read the document properly, and it will not survive a reorganisation that changes sites and entities without changing the rules keyed to them. Re-run the two pivots quarterly. The rest of this sits inside invoice to pay: capture, matching and approvals; the exception tooling and queue instrumentation we build for finance operations teams is scoped under internal tools and ops.

• accounts payable
• exceptions
• diagnostics
• matching