Why invoice exceptions happen: the upstream causes agents trace
Invoice exceptions happen because the documents an accounts payable system compares – purchase order, goods receipt, invoice – are created at different times by different parties, and the business keeps moving in between. A price updates after the PO is cut, a supplier bills before goods ship, a negotiated term never reaches the ERP. The mismatch surfaces in AP, but the cause entered the process weeks earlier.
This wiki defines source-to-pay concepts for companies where AI agents carry the operational load and people keep the judgment calls. Most pages on why invoice exceptions happen stop at a list of mismatch categories; this one follows a single purchase order through its life and marks the exact record where each cause gets in, because that record is what an agent reads when it traces a case backward.
One order's timeline shows where each cause gets in
The clearest way to see why invoice exceptions happen is to lay one order's paperwork on a timeline. Take PO 4500218774: a maintenance planner at a manufacturer orders 60 pillow-block bearings at $118.40 each and 12 cases of grease cartridges from an industrial distributor – a $7,104 bearing line plus consumables, entered in SAP against next week's scheduled line overhaul. When the distributor's invoice arrives, AP will run a three-way match, a line-by-line comparison of the invoice against the purchase order and the goods receipt, the warehouse record confirming what physically arrived. Any line that disagrees beyond tolerance, the small variance band a company accepts without review, becomes an invoice exception and stops for investigation; the types of invoice exceptions page catalogs the downstream failure modes, and three-way matching covers the match itself. What follows is where the disagreements originate. Five causes enter at four different points on this timeline, and none of them enters in AP.
The first cause predates the purchase order
In practice, orders often start out of sequence. Suppose the overhaul gets pulled forward because a spindle fails on a Tuesday: maintenance drives to the distributor's counter, takes the bearings that day, and the buyer cuts PO 4500218774 on Thursday to paper the purchase after the fact – a retroactive PO. Downstream, the resulting exception looks odd enough to trip fraud-adjacent checks: the invoice and delivery note carry dates earlier than the PO's existence, or the receipt was posted with no PO to post against. An agent tracing the case reads the PO header's creation timestamp in SAP, the delivery note date, and the requisition or email trail that authorized the emergency pull, then establishes that the sequence was legitimate. The record it lands on is the timestamp gap itself: evidence that the commitment was recorded after the consumption.
Price has more owners than the purchase order admits
Two causes enter at PO creation, both through price. The PO's $118.40 came from the purchasing info record, the SAP master record that stores the negotiated price for a given material and vendor, and its change log shows it was last maintained 14 months ago. The distributor's current list price is $123.10, so the invoice arrives at $123.10 and fails the price check: a $4.70-per-unit variance, $282 across 60 units, roughly 4% against a 2% tolerance. The second cause hides underneath the first. A supply agreement signed in March fixed this bearing at $121.30 for the year, and nobody synced that schedule into the info record. Three prices now disagree, and the only correct one lives in a PDF in the contract repository. An agent traces the exception through the info record's change history, then to the contract's pricing schedule, and concludes that the invoice needs a $1.80-per-unit credit while the PO and the info record both need updating. The same decay affects orders after they are cut; PO amendments covers how quickly an order falls behind the truth it was written to record.
A case and a unit disagree before anything ships
The grease cartridges carry a quieter cause: unit of measure, the quantity basis a line is counted in. The buyer's material master defines the item in cases of 24, so the PO line reads 12 CS. The distributor's item master carries the same cartridge as an each, so its systems ship and bill 288 EA – exactly 12 cases, expressed differently. The match engine compares 12 against 288 and raises a quantity exception that reads as a 2,300% overbilling on paper. An agent traces it to the unit-of-measure conversion in the material master on one side and the supplier's catalog entry on the other, confirms that 288 divided by 24 equals the 12 ordered, and clears the line. The same mismatch will fire on every future order of this cartridge until someone corrects the conversion, which is a master-data project rather than an AP task.
The invoice can leave the supplier before the goods do
The final cause enters between shipment and receipt. The distributor bills on dispatch, so the bearing invoice is generated the moment the truck is loaded; the goods spend six days in transit, and the goods receipt cannot be posted until the warehouse counts them in. For those six days the match compares 60 units billed against zero received and fails. The invoice is accurate and the shipment is on schedule; the sequence alone breaks the check. An agent traces this cause forward rather than backward, reading the advance shipping notice, the supplier's electronic notification that goods are on the way, along with the carrier tracking, and parks the invoice with a release date instead of escalating it. Timing cases like this one fill a meaningful share of most queues, and they clear themselves once something can safely tell them apart from genuinely missing shipments.
Every cause sits upstream of AP, so prevention is separate work
Look back at where each answer to why invoice exceptions happen was found: a PO timestamp, an info record change log, a contract pricing schedule, a material master conversion, an advance shipping notice. AP owns none of those records. Procurement, master-data teams, receiving, legal, and the supplier own them, which is why resolving exceptions and preventing them are separate projects with different owners. An agent working the queue changes resolution speed and gives every case a documented root cause; the rate itself moves only when the upstream owners repair their records, and some causes, like a supplier that bills on dispatch, sit outside the buyer's control entirely. That is why rates cluster in a stubborn band – the invoice exception rate benchmarks page shows where – and why exceptions never go to zero. The useful byproduct of agent-led resolution is the trace evidence: a month of resolved cases doubles as a ranked defect list showing exactly which info records, conversions, and contracts are generating the queue.
Fragment builds AI agents that work invoice exceptions this way inside a company's existing SAP or Ariba environment – tracing each case back to the info record, contract clause, or shipping notice that explains it, clearing what the evidence supports, and handing people the judgment calls with the trace attached, with no rip and replace. See how the workflows run or request a demo.