Open your exception queue and count the items an AP clerk can close on their own, without asking anyone a question. On most queues the honest answer is one type: suspected duplicates. Everything else is waiting on a fact that lives outside AP — a price someone negotiated, a delivery someone received, a budget someone owns, a bank change someone has to verify.

That is the whole problem in one sentence. AP owns the queue and holds almost none of the resolutions. Which is why "reduce exceptions" projects aimed at AP headcount fail, why the queue is worked in arrival order, and why the median item sits for days with no one accountable for the delay.

The fix is not a tool. It is a taxonomy, a named owner per type, and a clock that runs whether or not anyone remembers to chase.

Start with the arithmetic, because it decides the priority

Take a team processing 800 invoices a month with 14% going to exception. That is 112 items. Suppose the median one sits on hold for 5 days.

That is 560 hold-days a month, and hold-days — not exception count — is the number that matters. Twelve price-variance disputes sitting 9 days each cost you 108 hold-days. Sixty missing-coding items cleared in half a day cost you 30. The second type is five times more frequent and one-fifth the problem, and if you work the queue in arrival order you will spend most of your attention on it.

Hold-days is also what converts into money you can name. On 2/10 net 30 terms, the annualised cost of missing the discount window is:

2 / (100 − 2) × 365 / (30 − 10) = 2.04% × 18.25 = 37.2%

Anything that pushes an invoice past day 10 is expensive borrowing, whatever the queue looks like. See early payment discounts for how to work out what your own terms are worth.

The rule that assigns every owner

You do not need judgement to route an exception. You need one question:

What fact is missing, and who holds it?

Whoever holds the missing fact owns the exception. AP holds the invoice; AP does not hold the price agreement, the receipt, the budget code, or the vendor's banking relationship. Apply the rule mechanically and the routing table writes itself.

The taxonomy: eight types and their owners

#	Exception type	How it is detected	Missing fact	Owner (a named person)	AP's actual job
1	No PO on file	Invoice arrives with no PO reference, or the reference does not resolve	Was this spend committed, and by whom?	The requisitioner who bought it	Identify the buyer, route, and log it as a policy breach
2	Price variance	Invoice unit price exceeds PO price beyond tolerance	Which price was agreed — the PO or the invoice?	The buyer who raised the PO	Present both figures and the contract reference
3	Quantity variance or no receipt	Invoiced quantity exceeds received, or no GRN exists	What physically arrived?	The receiving supervisor at that site	Nothing until receiving answers
4	Missing or disputed GL coding	No cost centre, or a code the budget owner rejects	Which budget carries this?	The cost centre owner	Apply a coding rule if one exists; route only if it does not
5	Suspected duplicate	Vendor plus amount plus invoice number matches an existing record	Is this the same document twice?	AP	Resolve it; this one is genuinely yours
6	Vendor master defect	New vendor, changed bank details, missing tax ID	Is this vendor and this account legitimate?	Vendor master owner or controller	Never resolve unilaterally — this is a fraud control
7	Tax or compliance defect	Wrong tax treatment, missing registration number, e-invoice rejected	What is the correct treatment?	Tax lead or controller	Collect the vendor's documentation
8	Approval stalled	Routed correctly, sitting unactioned past SLA	Does the approver accept this?	The approver, then their manager	Escalate on the clock

Two of these deserve a note.

Type 6 is not a workflow problem, it is a control. A bank-detail change arriving by email is the standard business email compromise vector, and AP must not be able to clear it alone. Route it through vendor bank account verification with callback to a number from the vendor master, not from the email. The segregation of duties that makes this real is that the person who changes the master record cannot also release the payment.

Type 8 is usually the largest and is rarely counted. An invoice sitting in an approver's inbox is not classed as an exception in most systems, so it never appears in exception reporting — while consuming more cycle time than types 1 through 7 combined. Count it. If your approval workflow has four levels, count each level separately; the stall is almost never spread evenly across them.

Two clocks, not one

Most AP dashboards show one number — days since the invoice arrived — and it produces no accountability, because everyone can see it and nobody is named by it. Run two.

Invoice age starts at receipt and never stops. It drives payment-terms risk: discount window, due date, late fees. It belongs to AP.

Hold age starts when the exception is assigned to an owner. It drives accountability, and it belongs to the current owner by name.

The design detail that matters: hold age must not reset on reassignment. Keep a total-hold clock alongside a current-owner clock. Without the total, an item can bounce between procurement and receiving three times, show two days on the current owner's clock every time, and quietly age for a fortnight. Ping-pong is the most common failure in exception handling and a single-clock design makes it invisible.

Both belong on the AP dashboard as separate tiles. If you only have room for one, show hold age, because it is the one somebody can act on today.

SLAs set from the work, not from a round number

A flat "5 days to resolve" is what everyone writes and it is wrong in both directions — too slow for a warehouse walk, too fast for a contract dispute. Set each type from what the resolution actually requires.

Type	SLA	Why that number
Missing GRN or quantity variance	1 business day	Someone walks to the dock and checks. It is not a research task
Suspected duplicate	1 business day	AP holds both documents already
GL coding	2 business days	One email to a budget owner who knows the answer
Price variance	3 business days	Requires pulling the contract or rate card
Tax or compliance defect	3 business days	Usually needs a document from the vendor
Approval stalled	2 business days per level	Beyond this it is not busy, it is stuck
Vendor master defect	3 business days	Callback verification takes as long as it takes; do not compress it
No PO	5 business days	A retrospective PO is a policy exception and needs a decision, not just a form

Clock in business days, not calendar days, or every Friday exception breaches over the weekend and your report fills with noise.

The escalation ladder

Escalation that depends on someone remembering to chase is not escalation. Three design constraints make it fire on its own.

It goes to a person, not a mailbox. A shared inbox is where escalations go to die, because a message addressed to everyone is addressed to nobody.

It fires on the clock, not on the weekly report. A report is a record of what already went wrong.

It has a terminus. An escalation ladder with no final decision-maker is a chase with extra steps. Someone must be empowered to say pay it or reject it.

A ladder that works:

Trigger	Action
SLA breached	Automated reminder to the named owner, with the missing fact restated
SLA + 2 days	Owner's manager copied, item named in the escalation list
SLA + 5 days	Item appears by owner name on the weekly exception review
Due date − 2 days	Terminal. Goes to the AP manager with a pay / hold / reject decision, which is made that day

The terminal step is the one teams leave out and the one that does the work. Without it, a disputed invoice can sit past its due date indefinitely while everyone is technically compliant with the process. With it, an unresolved dispute becomes a decision someone signs — pay it and pursue the credit, or reject it and tell the vendor why.

Route the decision authority through your delegation of authority matrix so the threshold for "pay it and chase the credit later" is written down rather than improvised at day 28.

Which type to attack first

Rank by hold-days, then read the resolution outcome. Those two columns together tell you which of three completely different fixes you need.

Type	Count / month	Median hold	Hold-days	Usual resolution
Price variance	12	9.0 d	108	Accepted as invoiced
Approval stalled	40	2.5 d	100	Approved unchanged
No PO	9	8.0 d	72	Retrospective PO raised
Missing GRN	22	2.0 d	44	GRN posted late
GL coding	60	0.5 d	30	Coded by AP

Now read the last column, because it names the fix:

Resolved as "accept as invoiced" → your tolerance is too tight. The control is not catching errors, it is generating work and then waving it through. Widen the tolerance and the exceptions stop being created. Price variance at 108 hold-days that always ends in acceptance is not a procurement problem — it is a threshold problem, and it is the cheapest thing on this list to fix.

Resolved by amending the PO or posting the GRN → the upstream process is broken. Receiving posts late, or buyers raise POs after the fact. No amount of AP effort touches this; the fix sits in the warehouse or in procurement, and the purchase order approval workflow is where it lives.

Resolved by the vendor issuing a credit → it is a vendor problem, and it belongs on a vendor scorecard rather than in your queue. Three vendors usually account for most of it.

In the table above, the top two rows are 208 of 354 hold-days, and neither is fixed by working harder on exceptions. One is a tolerance setting. The other is an approver who needs a deadline. Both are a morning's work; sorting the queue by arrival date would have you looking at GL coding instead.

Tolerances: the exceptions worth not creating

An exception that is always accepted is not a control. It is a tax on two people's time, collected daily.

Set matching tolerances as both a percentage and an absolute amount, and apply whichever is lower. A flat 5% waves through $20,000 on a $400,000 invoice and stops a $3 rounding difference on a $60 one. Something like 2% or $50, whichever is lower, behaves sensibly across the range — pick your own numbers, but pick two.

Then review the auto-accept rate quarterly. If a tolerance band produces exceptions that are accepted more than about 90% of the time, it is set too tight. If it never produces one, it is set too wide and you have no control at all. This sits directly on top of your matching design; if you are still deciding how much matching to run, two-way vs three-way matching covers which invoices justify the third check.

What to implement this month

None of this requires new software. It requires two fields on your exception record.

owner — a person, not a team. "Procurement" is not an owner. If your system only supports queues, put the name in the subject line. It works.

assigned_at — a timestamp. Hold age derives from this, total hold derives from the history of it, and the escalation ladder derives from both.

With those two fields you can build the rest in a spreadsheet:

Classify one month backwards. Take last month's closed exceptions and tag each with a type from the table. An hour of work, and it gives you the hold-days ranking without waiting a month.
Publish the routing table. One page, eight rows, names in the owner column. Circulate it to procurement, receiving and the budget owners — the point is that they see their own name before the first escalation, not after.
Set the clock and the ladder. Even a daily manual scan against the SLA table beats waiting for someone to notice.
Run a 20-minute weekly review of the top three types by hold-days. Not the whole queue. Three types.

Only then look at tooling, and look at it for the two things a person cannot do well: classifying every exception the moment it is created, and firing escalations on time without being asked. Everything else on this page is a decision, and no product makes decisions for you. If you are earlier than this and still measuring, invoice processing time metrics covers where the days actually go.

Ken does the classification and the clock inside Slack, which matters mainly because the owners of six of these eight types do not have a login to your AP system and never will. An escalation that reaches a buyer where they already work gets answered. One that requires them to log into finance software gets ignored, and then it becomes a chase, and then you are back to arrival order.

FAQ

What counts as an invoice exception?

Any invoice that cannot proceed to payment without a human resolving something — a match failure, a missing purchase order, a coding gap, a vendor data problem, or a compliance defect. The definition worth adopting is broader than most systems use: include invoices sitting unactioned with an approver past their SLA. They are functionally identical to a match exception, they consume more cycle time than any other category on most queues, and leaving them out makes your exception rate look better while your days-to-pay stays the same.

Who should own invoice exceptions — AP or the business?

AP owns the queue; the business owns the resolutions. Of the eight common types, AP can independently resolve exactly one, the suspected duplicate. The rest wait on a fact held by a buyer, a receiver, a budget owner, a controller or an approver. Assigning a named person outside AP to each type is what separates an exception process from a chase list, and it is why exception reduction targets given to AP alone do not move.

How do you decide which exception type to fix first?

Rank by hold-days — count multiplied by median days on hold — not by count. Then read how each type is usually resolved, because that names the fix. Types that end in "accepted as invoiced" mean a tolerance is too tight. Types that end in an amended PO or a late GRN mean an upstream process is broken. Types that end in a vendor credit are a vendor management problem. The three need entirely different work, and the resolution column is the only thing that tells you which one you have.

What is a reasonable invoice exception rate?

Less useful than a target on hold-days. A team can drive the exception rate down by widening tolerances until nothing is caught, which looks like an improvement and is the opposite of one. Track exception rate alongside total hold-days and the auto-accept rate per tolerance band; a healthy queue has a stable exception rate, falling hold-days, and tolerance bands that produce exceptions which are genuinely resolved rather than routinely waved through.

How long should an invoice exception take to resolve?

It depends on what the resolution requires, which is why a single flat SLA fails. A missing goods receipt is someone walking to the dock: one business day. A price variance needs a contract pulled: three. A no-PO invoice needs a retrospective policy decision: five. Set the SLA from the work, count in business days, and make the escalation terminal at two days before the due date so an unresolved dispute becomes a decision rather than a default.

Invoice Exception Handling: A Taxonomy, an Owner for Each Type, and an Ageing Clock