Invoice exceptions fall into a handful of recurring types. They are usually grouped by the check the invoice failed: the match against the purchase order, the duplicate test, the tax and freight calculation, the general ledger coding, or the approval rules. Knowing the type matters because it decides who can resolve the invoice and how quickly.
The types below cover most of what an AP team sees. A single invoice can trip more than one at once.
Price and quantity exceptions dominate the queue
The most common exceptions come out of three-way matching, where the invoice is compared against the purchase order and the goods receipt. A price variance is raised when the unit price billed is higher or lower than the price on the order. A quantity or receipt mismatch is raised when the amount billed does not agree with what was received, often because a shipment arrived in parts. These two account for a large share of the exception queue in most AP teams.
No purchase order means no automated check
Some invoices reference a purchase order that does not exist, was closed, or was never raised. Others arrive with no purchase order at all, which is normal for services and tail spend. Without an order to match against, a non-PO invoice needs a different validation path and frequently stops for review.
Duplicates are the expensive ones
A duplicate invoice bills for something already in the system, often because a supplier resubmitted one they believed was lost. Duplicates are dangerous because the failure mode is an overpayment, so a duplicate that slips through costs real money rather than stalling a queue.
Tax and freight break the match from outside the order
An invoice can fail because the tax code or tax amount does not reconcile, because freight or a surcharge appears that was not on the order, or because the currency does not match what the system expects. These tax and freight discrepancies are easy to miscalculate and easy to miss.
Accurate invoices still stall on coding and approval
Even an invoice that matches cleanly can stop if it is not coded to the right general ledger account and cost center, or if it falls outside the company's approval rules. These coding and approval exceptions are about where the cost lands and who signs off, rather than whether the amount is right.
The type tells you where the answer lives
The type tells you where the answer lives. A price variance is usually settled by checking the contract or the buyer. A quantity mismatch waits on the goods receipt. A non-PO invoice needs the requester who bought the service. A duplicate needs a look across payment history. The reason exceptions are slow is that this context is spread across systems and people, and the person clearing the invoice has to go find it. The why exceptions happen page goes into the root causes.
Fragment resolves these exception types autonomously by reading the invoice against the same context a buyer or clerk would check, without ripping out or replacing your existing systems. See how it works or request a demo.