Price variance exceptions: how an AI agent clears them

Price variance exceptions are supplier invoices held because the unit price billed differs from the price on the purchase order or contract by more than the company's tolerance – the variance band allowed before a line needs review. The invoice fails the price leg of three-way matching, the line-by-line comparison of invoice, purchase order, and goods receipt, and stops in a hold queue until someone establishes which price is correct. They top most catalogs of types of invoice exceptions by volume, and the large majority trace to a documented, benign cause.

This wiki describes source-to-pay work as AI agents now perform it, with people holding the judgment calls rather than the queues. Most glossaries stop at what a price variance is; this page covers how one comes apart. A price variance has an anatomy: a short ordered list of causes, each confirmed or killed by one specific record, and an agent clears the exception by testing the list top to bottom.

Price variance exceptions have six causes worth testing in order

An experienced AP analyst runs a mental checklist on a price gap, ordered by how often each cause appears and how cheap it is to check, and stops at the first hypothesis the records confirm. An agent works the same list explicitly. Whether a gap becomes an exception at all is a question of match tolerances and thresholds – a 0.4% difference inside a 2% band never surfaces.

1. A contract escalator or index clause repriced the item. Long-term materials and freight contracts often reset price on a schedule or against a published index. The deciding record is the pricing schedule in the executed contract, plus the index value for the period. If the clause's formula reproduces the invoiced price to the cent, the invoice is correct and the purchase order is stale. If the schedule shows fixed pricing, the hypothesis dies in one read.

1. The order crossed a tier or volume break. Tiered pricing charges a different unit price once cumulative volume passes a threshold, in either direction. The deciding records are the tier table in the contract and the cumulative ordered or received volume in the ERP for the measurement period. The arithmetic either lands exactly on the invoiced price or it rules the tier out.

1. A promotion or negotiated discount started or lapsed. Suppliers bill list price when a discount's validity window and the invoice disagree about dates. The deciding record is the discount agreement's validity dates set against the order and invoice dates; which date governs is itself a contract term, and the agent reads it first.

1. Currency moved between order and invoice. A purchase order cut in one currency and invoiced in another can produce a gap that is pure conversion. The deciding records are the contract's convention for which day's rate applies – order date, ship date, or invoice date – and the ERP's exchange-rate table. Recomputing at the contractual rate either explains the variance exactly or eliminates it.

1. The price master is stale. The price master – in SAP, the purchasing info record that supplies the default price when a PO is created – lags renegotiations. The deciding comparison is the master's last-updated date against the latest contract amendment. If the amendment is newer, the invoice is right, the default is wrong, and the variance will recur on every new order until the master is fixed – the one confirmation that also prevents future exceptions.

1. The supplier genuinely overbilled. The last hypothesis is reached by elimination. When the five checks above all fail, the invoiced price has no documented basis, and those failed checks are already the evidence.

The first five causes are benign: something is out of date, and the fix is administrative. Overbilling sits last because it is the most consequential finding and should only be declared once everything else is dead.

One carton invoice runs the whole list in minutes

Take a price variance exception raised at a food manufacturer: a purchase order for 48,000 corrugated shipping cartons at $1.04 each, invoiced by the supplier at $1.12. The variance is 7.7% against a 2% tolerance, and a $53,760 invoice goes on hold over a $3,840 gap.

The agent opens the contract. The pricing schedule is fixed for the term, with no escalator or index reference, so hypothesis one dies in one read. The same schedule carries a tier table: $1.12 per carton below 200,000 units per contract year, $1.04 at 200,000 and above. Cumulative receipts in SAP show 176,400 units with four months left in the year. The buyer priced the PO at the high-volume tier while actual volume sits below the break, and 48,000 multiplied by $1.12 reproduces the invoice total to the cent. Hypothesis two is confirmed, and three through six never need testing.

What the agent does next separates it from a lookup script. It posts the match with an override code and attaches the tier table, the receipts query, and the arithmetic. Then it handles the recurrence: every open order still priced at $1.04 will raise the same exception until volumes recover, so it flags those orders and the price default for correction and alerts the category manager, who may prefer to renegotiate the break. The manual version of the same investigation usually waits days for an analyst to email the buyer about carton prices.

Real overbilling ends in a credit request the agent has already built

A minority of price variance exceptions survive all five benign hypotheses, and those are the cases the control exists to catch. Take a maintenance chemical billed at $18.90 per drum against a contract price of $17.25 on 2,600 drums, where every benign hypothesis has failed in turn. The overcharge is $1.65 per drum, $4,290 on the invoice.

Because the conclusion was reached by elimination, the credit request writes itself: the invoice lines, the contract clause with the agreed price, the computed overcharge, and the supplier's own prior invoices at $17.25 as precedent. The agent drafts the credit memo request, then applies whatever policy dictates while the credit is open – holding the invoice, or short-paying it, which means paying the corrected amount and disputing only the difference. It also logs the pattern, because one overbill is an error and the same overbill across four invoices is a conversation for procurement.

What escalates is a judgment call, delivered with the file complete

Some cases belong with a person. A supplier claims a verbal price agreement with the buyer that no system records. A clause is ambiguous about whether the order date or the invoice date governs a discount. A variance exceeds the sign-off threshold regardless of evidence, or a supplier disputes a credit request and the case needs an owner. An agent that guessed at any of these would convert an exception into a liability.

What changes with an agent is what arrives with the escalation. A rules engine forwards a hold code and an attachment, and the analyst rebuilds the investigation from the start. An agent forwards its case file: the hypotheses tested, the record that killed each one, the calculation that nearly cleared the case, and the single open question. The decision takes minutes. The rate at which variances occur stays put, because prices move upstream for reasons AP never controls – why invoice exceptions happen works through them. An agent changes what each variance costs to clear; the count is a procurement problem.

Fragment builds AI agents that work price variance exceptions this way, inside a company's existing SAP or Ariba environment – testing each cause against the contract, the volume history, and the price master, clearing what the records prove, and assembling the credit request when they prove overbilling. See how the workflows run or request a demo.