Exceptions across source-to-pay: the full map agents work

Exceptions across source-to-pay are the transactions that drop out of automated handling at any point between sourcing and final payment: a purchase made off contract, a requisition that never becomes a purchase order, a delivery date the supplier moved by email, an invoice that fails matching, a credit that expires unclaimed. Invoice exceptions are the best-known family because a payment deadline makes them urgent, but every stage of the source-to-pay lifecycle produces a family of its own, each with its own cause and its own resolving records.

This wiki defines procurement and AP vocabulary for a world where AI agents carry the transactional load – converting requisitions, reconciling receipts, clearing holds – and people keep the judgment calls. Most references describe each exception type at the desk that handles it; this page lays the families out as one connected map, the way an agent working the whole chain reads them.

Each stage of source-to-pay produces its own exception family

Walk the process front to back and the pattern repeats: each stage has a family, a canonical instance, and a home for its resolving context.

• Sourcing and contracting. The family is maverick spend – purchases that route around the buying process entirely – plus negotiated terms that never reach the transactional systems. A category manager signs a 4% volume rebate; the contract PDF goes into the repository, nothing reaches the SAP price master, and every subsequent PO prices at list. The resolving context is the contract and the award correspondence; the PO-first culture problem covers why purchases keep skipping the process.

• Requisition to PO. The family is failed conversions: free-text lines because the catalog item was retired, account assignments that fail validation, supplier records blocked over a stale tax form. The req sits in a buyer's queue while the requester assumes the order is placed; resolution needs the catalog, the supplier master, and often the requester's intent. Requisition-to-PO conversion works this stage in detail.

• Open orders. The family is change and drift: quantities, prices, and dates that move after the PO is issued without the ERP hearing about it. A supplier confirms a two-week slip by email, the PO keeps the original date, and the mismatch surfaces later as an expedite scramble or a match failure. The confirmation sits in an inbox or a portal; PO amendments drift from reality explains how wide the gap gets.

• Receiving. The family is missing, late, and wrong receipts. Material gets consumed on the line before anyone posts the goods receipt, the record confirming delivery, so the invoice arrives against a receipt quantity of zero. Resolution lives in packing slips and the MES, the manufacturing execution system tracking what the line actually used; quantity and receipt mismatches covers this family downstream.

• Invoicing. The family is the match failures: price, quantity, tax, and reference mismatches among the invoice, the PO, and the goods receipt, caught by the three-way match comparing all three before payment. This is the deepest cluster on the map, and invoice exceptions covers it fully; the resolving context runs from PO history in the ERP to a pricing clause three stages upstream.

• Coding and accounting. The family is misclassification: non-PO invoices coded to the wrong GL account or cost center, usually found at month-end close, if at all. A facilities invoice for $7,200 of HVAC work gets coded to repairs when the contract terms make it a capital project. Resolution needs the chart of accounts, coding history, and the tribal knowledge of which department books what; GL coding is the deep article.

• Payment and post-payment. The family is leakage after the invoice clears: duplicate invoices paid twice under different numbering, credits never applied, rebates never claimed, supplier statements that disagree with the ledger. The resolving context is payment run history, the supplier's statement, and the rebate terms, which sit in the sourcing-stage contract at the other end of the map.

Upstream exceptions manufacture the downstream queue

The families look independent on an org chart and behave as one system in practice. An exception left unresolved at one stage changes form and reappears downstream. Take an $18,900 tooling requisition that fails conversion over a blocked supplier record. The engineer phones the supplier and the work happens anyway – a sourcing-stage exception. Six weeks later the $18,900 invoice arrives with no PO reference – a non-PO invoice – and with no account assignment attached, a coding exception on top. One failed conversion produced three exceptions in three queues owned by three teams, and each team's metrics record it as their own problem.

This coupling is why the queue at any stage partly measures the stages before it. An AP department drowning in non-PO invoices is often looking at requisition-stage failures arriving late. On the procure-to-pay half of the lifecycle, where payment deadlines make exceptions visible and countable, much of the volume was created in stages with no deadline at all. Reading exceptions across source-to-pay as one map instead of seven lists makes those causes traceable.

The record that clears an exception usually lives in another stage

The map also shows that the context resolving source-to-pay exceptions rarely sits at the stage that raised them; the document that clears an invoice hold is often a sourcing or ordering artifact. Take an invoice for 8,400 units at $1.94 against a PO written at $1.82. The match engine sees a 6.6% price variance, far outside the 2% tolerance – the variance band a company pays without review – and holds $16,296. The record that clears it is a four-month-old change order, confirmed by email between buyer and supplier and never posted to the PO. An AP analyst cannot see that thread, and the buyer who can see it does not own the hold. So the case ping-pongs: AP emails the buyer, the buyer asks the supplier, the supplier resends the confirmation, and three weeks pass on a discrepancy that was documented all along.

Stage-siloed tools institutionalize the ping-pong: the matching engine routes the hold, the procurement workflow routes the change request, and every routing step adds queue time without adding evidence. An agent reading the whole chain – ERP, contract repository, supplier portal, mail – treats the confirmation and the hold as one case, verifies the change order against the contract, posts the correction, and attaches the evidence. Whether a tool resolves an exception or merely routes it comes down to whether it can reach the stage where the answer lives.

Where to start mapping your own operation

Exception rates are set upstream, by catalog coverage, contract data quality, and supplier master hygiene, which is why a worked queue refills; why exceptions never go to zero walks through the mechanics. The practical move for a leader is to map before automating. Pull a month of invoice holds and trace each one to the stage that created it: an unposted change order is an open-order exception, a non-PO invoice usually marks a requisition-stage failure, and a price variance from an unloaded contract started in sourcing. Two numbers are worth knowing before any tooling decision: what share of the AP queue originates upstream of AP, and which single stage manufactures the most downstream work. Leaders who run the exercise tend to find the answer sits further left on the map than their staffing does.

Fragment builds AI agents that work exception queues across this whole map – requisition conversions, PO changes, receipt mismatches, invoice holds, GL coding, credits and statements – inside a company's existing SAP or Ariba environment, reading the cross-stage context that clears each case while people keep the judgment calls. The workflows Fragment covers run down the same map, stage by stage, or book a demo and trace your own queue back to its causes.