The Accounts Payable Exception Taxonomy

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 code design #

Use stable, composable codes:

[CLASS].[OBJECT].[CONDITION]

Examples:

• IDENTITY.VENDOR.MULTIPLE_MATCHES
• EVIDENCE.RECEIPT.MISSING
• MATCH.QUANTITY.OUTSIDE_TOLERANCE
• DUPLICATE.ECONOMIC_EVENT.CANDIDATE
• AUTHORITY.APPROVER.LIMIT_EXCEEDED
• EXECUTION.QBO.TARGET_STATE_UNKNOWN

The code should describe the state, not blame the person or system. Root cause belongs in a separate field: supplier behavior, master-data quality, onboarding gap, extraction failure, policy design, integration defect, or another cause discovered during resolution.

Attributes that cut across classes #

Attach these to every exception:

• severity and materiality;
• confidence/strength of the detection signal;
• age and SLA;
• client/entity/vendor;
• transaction value and currency;
• required owner role;
• available evidence;
• permitted decisions;
• active versus waiting time;
• recurrence/root cause;
• first occurrence versus reopen;
• product/system boundary.

Do not create top-level classes called “high priority,” “AI,” “manual,” or “overdue.” Those describe handling or age, not why action is blocked.

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.

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.

Limitations #

Organizations must adapt the taxonomy to their controls, materiality, jurisdictions, transaction types, and systems. Some cases span multiple classes; use a primary blocking state plus linked secondary states rather than forcing one label. Tax and accounting questions require qualified review.

The taxonomy does not imply every exception should be resolved automatically. High-risk or irreversible actions may require people even when the system can propose an answer.

Sources #

• ServiceNow: invoice exceptions.
• SAP Learning: handling exceptions.
• Number7 Research: AP exception taxonomy, revision 1.0.

How to cite #

Number7 Research. “The Accounts Payable Exception Taxonomy.” Number7AI, revision 1.0, 7 September 2026. https://number7ai.com/research/ap-exception-taxonomy.

Revision history #

Next step #

Classify the last 100 manual AP interventions by blocking state, root cause, touches, and active minutes.