Types of invoice exceptions: what each one asks an agent to prove
The types of invoice exceptions are the recurring ways a supplier invoice fails validation before payment: price variances, quantity and receipt mismatches, missing or invalid purchase orders, duplicates, tax and freight discrepancies, and coding or approval failures. Each type names the check the invoice failed, and each failed check is a claim the accounts payable system could not verify from the records it can see.
This wiki covers procure-to-pay operations where AI agents carry the operational load – running matches, chasing receipts, computing tax – and people keep the calls that need judgment. A conventional glossary presents exception types as categories on a hold report a clerk will sort by hand. This page redraws the taxonomy as a set of instructions: each type tells an agent what to prove and where the proof usually sits.
The types of invoice exceptions sort by the proof that failed
Nearly every check an invoice can fail runs during three-way matching, the line-by-line comparison of the invoice against the purchase order and the goods receipt, the warehouse record confirming what actually arrived. A match passes when every line agrees within tolerance, the variance band a company accepts without review; the bands are covered on the match tolerances and thresholds page. When a line falls outside a band, the system assigns a hold code that names the symptom.
The symptom is a weak way to organize the work. Two exceptions with the same hold code can require different investigations, and two different codes can resolve from the same document. The stronger grouping is by proof family: what claim failed, which record can settle it, and whether an agent can fetch that record on its own. Six families cover the invoice exceptions an AP team sees; a single invoice can sit in several at once.
Price proofs resolve against the contract
A price variance exception means the system could not prove the unit price. The PO says one number, the invoice says another, and the PO price is only a copy of a price agreed somewhere else, usually a contract, a quote, or a catalog entry, and that original agreement is where the proof lives. In practice, take a corrugated packaging supplier invoicing 8,000 boxes at $1.42 each against a PO written at $1.31. The variance is 8.4%, the tolerance allows 2%, and $11,360 goes on hold over an $880 difference. An agent clears it by pulling the supplier's contract, finding the annual escalation clause tied to a paperboard index, computing the adjusted price, and confirming $1.42 to the cent. If the computation disagrees, the same evidence backs a credit request. Either way, the proof was a document the matching engine never opened.
Quantity and receipt proofs live in the warehouse records
A quantity or receipt mismatch means the system could not prove delivery. The invoice bills 500 units; the goods receipt shows 400, or shows nothing at all. The proof lives in receiving: goods receipt postings in the ERP, packing slips, carrier confirmations, and sometimes a dock supervisor's knowledge that a pallet sits uncounted. An agent checks whether a later receipt posted after the invoice arrived, whether the supplier routinely ships in split lots, and whether the open delta lines up with an in-transit shipment. Many of these clear themselves once the remaining receipt posts; the agent's contribution is releasing the hold the moment the record lands, instead of letting the invoice age while the goods sit received but unposted.
Existence proofs fail before matching can start
A non-PO invoice means the system could not prove the purchase was ordered. The invoice references a PO that was never raised, was closed early, or was consumed by earlier invoices; services and tail spend, the long tail of small and infrequent purchases, often arrive with no PO at all. With no order to match, the proof shifts to intent: who asked for this work, under what agreement, and against which budget. That evidence lives in statements of work, email threads, and approval hierarchies rather than in the matching engine. An agent identifies the likely requester from the invoice text and the supplier's history, confirms the engagement against the contract repository, and routes that person a one-question confirmation rather than a blank invoice image.
Coding and approval proofs run against the company's own rules
A coding and approval exception means the invoice may be correct and still cannot post, because the system could not prove where the cost belongs or that the right person signed off. The proof lives in the chart of accounts, the cost center structure, the delegation-of-authority policy, and years of precedent about how a given plant or category actually books things; the written rules cover less than teams assume. An agent clears these by matching the line to how identical purchases were coded before, applying the approval matrix, and routing the request with the coding rationale attached, so the approver checks a conclusion instead of researching one.
Tax and freight proofs are computations, and computations can be rerun
A tax and freight discrepancy means the system could not prove a calculated amount: the tax code, the tax total, or a freight or surcharge line the PO never carried. The proof lives in the tax engine's determination logs, the jurisdiction rules for the ship-to address, and the freight terms in the contract, including incoterms, the standard trade codes that fix who pays freight and where ownership transfers. This family suits an agent well because the answer is arithmetic. Rerun the tax determination with the corrected inputs, recompute the freight allocation against the terms, and the invoice's number either reproduces or it does not. What a person does slowly with a rate table, an agent does in seconds, with the full calculation preserved for audit.
Duplicate proofs are identity checks across payment history
A duplicate invoice means the system could not prove the invoice is new. Exact duplicates are cheap to catch; the dangerous ones are near-duplicates, the resubmission with a suffix added to the invoice number or a PDF regenerated with a fresh date after the supplier assumed the original was lost. The proof lives in payment history across every channel an invoice can enter, including the ones that bypass the scanner. A duplicate that escapes is an overpayment already out the door, a recovery project rather than a delay, which is why duplicates carry an outsized share of the cost of invoice exceptions. An agent runs the identity check the way a fraud analyst would, across amount, date proximity, line-level fingerprints, and the supplier's resubmission habits, and blocks the payment before it leaves rather than clawing it back afterward.
The types of invoice exceptions double as a routing table
Read as proof families, the types of invoice exceptions become a routing table: price to the contract, quantity to the warehouse, existence to the requester, coding to precedent, tax to the engine, duplicates to payment history. A human analyst carries that table in their head and still walks each route one system at a time. An agent holds all six routes at once and starts down the right one the moment the hold posts. What the table cannot do is shrink itself. The mismatches keep arriving from stale price masters, suppliers who invoice before goods ship, and POs cut after the work started, causes the why invoice exceptions happen page works through. A team running agents should expect every family to clear faster and no family to disappear.
Fragment builds AI agents that work all six families inside a company's existing SAP, Ariba, or Coupa environment: pulling the contract for a price proof, watching receipts for a quantity proof, rerunning determinations for a tax proof, and escalating the genuine judgment calls with the evidence already attached. See how the workflows run or request a demo.