The Accounts Payable Exception Taxonomy

The smallest-decision packet #

Every exception shown to a person should include:

1. one-sentence reason;
2. blocked transition;
3. source evidence and relevant regions;
4. candidate values or comparison records;
5. applicable rule/tolerance;
6. allowed decisions;
7. downstream effect of each decision;
8. audit event after resolution.

Example:

Quantity outside tolerance. Invoice line 3 requests 120 units; the linked receipt supports 100 and policy tolerance is 2%. Choose “receipt incomplete,” “approve authorized variance,” or “request supplier correction.”

That task is answerable. “Review invoice 18429” is not.

Worked example: duplicate signal plus execution uncertainty #

An invoice resembles a prior bill. The first bill’s API request timed out, and the local system does not know whether the target object exists.

Two exceptions may be active:

• EXECUTION.QBO.TARGET_STATE_UNKNOWN — verify whether the previous action created a bill;
• DUPLICATE.ECONOMIC_EVENT.CANDIDATE — after target state is known, determine whether the new source represents the same obligation.

Collapsing both into “possible duplicate” could cause a reviewer to reject a legitimate retry or create a second bill. The execution state must be resolved before the economic-event decision.

Why exception lists fail #

Many AP systems group every difficult item into a review queue. The reviewer opens an invoice and reconstructs the problem from source documents, comments, and system state. The tool has detected uncertainty but has transferred the full diagnosis cost to a person.

Other systems use a long list of overlapping labels: “PO mismatch,” “amount mismatch,” “price mismatch,” “needs approval,” “invalid invoice,” and “other.” That may be useful for a narrow workflow, but it does not provide a durable operating model across non-PO invoices, accounting decisions, master data, integrations, and downstream verification.

The taxonomy below begins with the layer that blocks action, then attaches a more specific code and root cause.

Formal definition #

AP exception: a typed state in which a payable transaction cannot proceed to its next defined action under current controls because a required condition is absent, ambiguous, contradictory, unauthorized, failed, or unverified.

An exception record should answer:

1. What state is blocked?
2. What signal created the exception?
3. What evidence is available or missing?
4. Who owns the smallest required decision?
5. Which actions are permitted?
6. What closes the exception?
7. What would reopen it?

Top-level exception taxonomy #

ServiceNow describes invoice exceptions as discrepancies requiring resolution before payment, while SAP training materials cite missing receipts, price/quantity mismatches, duplicates, and tax variance as examples. The Number7 taxonomy extends those operational examples across the complete transaction state. Sources: ServiceNow and SAP Learning.

Exception lifecycle #

Use explicit states:

Detected → Triaged → Waiting for evidence/decision → Resolved → Actioned → Verified → Closed

An exception reopens if new evidence contradicts the resolution, the authorized action fails, the target state differs, or a later correction traces back to the same issue. Reopen reasons should be measured; they reveal false resolution and weak verification.

Metrics by exception class #

• transactions affected and rate per in-scope population;
• total touches and touches per resolved exception;
• median and 90th-percentile active minutes;
• elapsed time and waiting share;
• resolution outcome distribution;
• recurrence by vendor/client/root cause;
• reopen/correction rate;
• silent errors found by sampling;
• automation/assist rate by decision type.

The goal is not to make exception count disappear. It is to prevent avoidable exceptions, pre-assemble evidence, and reduce the cost and risk of legitimate decisions.