Invoice exception handling: where automation succeeds or fails

The happy path in invoice automation is close to a solved problem: a well-formed invoice with a matching order, an agreed price and a reconciling tax total can be posted without anyone touching it. Invoice exception handling is everything else, and it is where the project is judged. An exception is not a defect in the pipeline; it is a decision the pipeline is not entitled to make alone. Systems that confuse the two either block good invoices or pay bad ones.

What counts as an invoice exception?

Any invoice for which the system cannot produce a matched, approved, postable record from stored data. Across ERP invoice processing, three families recur, and each needs different handling:

• Missing evidence. No purchase order, no delivery note, no receipt. The documents do not exist, so no rule can settle the question.
• Disagreement. The documents exist and contradict each other: a quantity received below the quantity invoiced, a unit price above the one agreed.
• Policy. The data is complete and consistent, but a threshold, a currency or a tax treatment needs a named person's approval.

The distinction matters because the first family is closed by chasing a document, the second by a conversation with a supplier, and the third by a signature. One queue labelling all of them "needs review" gets triaged by whoever complains loudest.

How do you tell a data problem from a business problem?

A structured e-invoice validated against a schema answers this precisely. The OASIS UBL invoice standard defines the invoice as named business terms, so a missing order reference is a missing term — the supplier can resend a corrected document — while a price that differs from the order is a value that is present and wrong. The first is a data problem. The second is a decision someone has to own.

A scanned invoice offers no such clarity: everything is an interpretation, so receiving records a confidence per field and the exception rule tests that confidence before the value. An exception raised because extraction misread a digit teaches the approver to ignore the queue.

Who owns each exception, and what does the system record?

Ownership is a role, not a person: "the accountant" and "management" tell nobody who is expected to act on Tuesday morning.

Exception	Who owns the decision	What the record must hold
No purchase order	the buyer who placed the order	who requested it, why it arrived without a reference, the decision and its date
Quantity received below invoiced	receiving lead	counted quantity, delivery note reference, who counted, when
Unit price differs from the order	buyer or category manager	both prices, the agreement cited, who accepted the difference
Tax does not reconcile	the accountant	computed tax, supplied tax, rate applied, who ruled
Invoice presented twice	accounts payable lead	both arrival records, the matching key, which copy was released
Partial delivery	receiving lead	quantities per line, whether the remainder is still expected

The third column is the one that gets skipped, and it is the one that matters a year later, when someone asks why an invoice was paid at a price no order authorised.

What must never be approved automatically?

A change of bank details. That is not an invoice exception; it is a payment instruction, and it needs its own verification path outside the invoice queue. Treating it as one more field to correct is how a supplier's mailbox compromise becomes a transfer.

Tax treatment when the supplied tax does not reconcile. The system can compute the expected tax, but which rate applies to a mixed invoice is a judgement, and it is the accountant's.

A posting with no counterpart document. An approval given in the absence of the order is a manager's memory, not evidence. If the order cannot be produced, the invoice waits.

Any exception closed without a reason code. "Resolved" is not a reason, and the next person to see the same supplier cannot learn from it.

Anything above the approver's own limit, including when the approver is the person who raised the purchase in the first place.

How should the exception queue be built?

1. Enumerate the exceptions from last month's real invoices, not from a template. The categories that appear in the documents are the ones that will appear in the queue.
2. Write the reason codes with finance, in their words. Codes invented by developers produce a queue the accountants cannot use and will work around.
3. Assign a role to each code, and tie the override to an authenticated account rather than a shared login. The OWASP authentication cheat sheet is blunt about this: if identity is ambiguous, every later authorisation is theatre.
4. Record the decision with the data it was made on, versioned, so the state at approval can be reproduced. That is the provenance the W3C data on the web best practices argue for, and it is what turns an override into an audit trail.
5. Time-box every state and escalate on age, not on volume. An exception that has waited a week is a different problem from one that arrived this morning.
6. Report aging by exception type, so the recurring one becomes a fix upstream: a supplier whose invoices never carry a reference is a master-data problem, not an approvals problem.

Where this goes wrong

An exception as a status instead of a queue. A record marked "pending review" with no list, no owner and no age is invisible. The invoice is neither rejected nor payable, and nobody knows it exists.

Approving on a timer. Auto-closing an exception after a fixed period removes the queue from the report and puts the risk on the payment run. A deadline escalates; it does not decide.

One bucket called "other". It grows, it hides the pattern, and it becomes the place where the difficult invoices go to be forgotten.

Measuring volume rather than aging. A team clearing many exceptions can look worse than a team ignoring them. Count how long the oldest item has waited.

Keeping only the outcome. A model can propose a match, but a decision stored without its rationale cannot be defended when the supplier disputes it. Store the rule matched, the values compared and who accepted.

What this does not cover

This describes the mechanism, not the policy. Approval thresholds, which tax rate applies, and whether a supplier dispute should be settled or offset are decisions for the finance function and, in some cases, for a professional adviser; nothing here should be read as tax guidance. It also assumes the counterpart documents exist somewhere. Where a purchase was never formally ordered — a common reality in small businesses — the exception is not a queue item but a control gap, and no amount of automation repairs it.

We build the exception queue before widening the automation, because the queue is the part of the system people trust when the answer is no.