Finance Index
What is a price variance vs a quantity variance on an invoice, and how should each be resolved?
Reference guide to invoice match exceptions price quantity, including invoice workflow, coding, approvals, ERP impact, and AP controls.
A price variance means the invoice charges a different unit price than the PO; a quantity variance means it bills more (or less) than was ordered or received. They resolve differently: price variances are a commercial question - was a price change agreed? - answered by procurement and the vendor; quantity variances are a fulfillment question - what actually arrived? - answered by receiving records. Matching exists precisely to force these questions before payment instead of after.
At a Glance
| Aspect | Short Answer | Why It Matters |
|---|---|---|
| A price variance vs | A price variance means the invoice charges a different unit price than the PO; a quantity variance means it bills more (or less) than was ordered or received. | Reduces payment errors, timing issues, and reconciliation cleanup. |
| Card control | Park it in a visible state ("awaiting receipt"), don't bury it, and notify the receiving party that a receipt is due. | Keeps vendor records and payment decisions reliable. |
| Exception handling | Tolerance is the variance you'll accept without intervention - expressed as a percentage, an absolute amount, or both (e.g., 2% up to $100). | Helps finance decide what to do next. |
| Workflow | AP detects and routes; procurement owns the commercial resolution (agreed price change -> update the PO; vendor error -> corrected invoice or credit). | Keeps vendor records and payment decisions reliable. |
| Related terms | Fix the master data: align units on the PO or apply conversion factors on the vendor/item record so matching compares like with like. | Reduces payment errors, timing issues, and reconciliation cleanup. |
Invoice arrives before the goods are received - should AP wait, park it, or chase the receipt?
Park it in a visible state ("awaiting receipt"), don't bury it, and notify the receiving party that a receipt is due. The invoice-before-receipt sequence is normal commerce, not an error; the failure mode is invisible parking, where the invoice surfaces at due date with no receipt and becomes a fire drill. If receipts chronically lag, that's a receiving-discipline problem - measure receipt latency by location and fix it there rather than letting AP absorb the chase.
What is a matching tolerance, and how do I set thresholds so trivial variances don't block invoices?
Tolerance is the variance you'll accept without intervention - expressed as a percentage, an absolute amount, or both (e.g., 2% up to $100). Set it from data: distribution of your historical variances, the labor cost of investigating one (often $25 - 50 of someone's time), and risk appetite by category. Blocking a $3 variance on a $5,000 invoice costs more than it protects; auto-accepting 2% on million-dollar spend is real money. Use tiered tolerances by spend category, and review what auto-passed quarterly so tolerance doesn't become a blind spot vendors learn to exploit.
Invoice price doesn't match the PO price - who fixes it, AP or procurement, and what's the workflow?
AP detects and routes; procurement owns the commercial resolution (agreed price change -> update the PO; vendor error -> corrected invoice or credit). AP should never silently "fix" a price mismatch by editing the invoice - that converts a control into a bypass.
Vendor invoices in different units than the PO - cases vs eaches - and everything mismatches. How is uom handled?
Fix the master data: align units on the PO or apply conversion factors on the vendor/item record so matching compares like with like. UoM mismatches are systematic per vendor - solve them once at the source instead of resolving the same exception monthly.
Partial shipments - the vendor invoices a PO across five invoices. How should matching and closure work?
Each invoice matches against the PO's remaining open balance, cumulative billed quantity tracks against ordered, and the PO closes when fully billed and received. The control to keep: total invoiced can never exceed the PO without an explicit exception.
Freight and surcharges on the invoice weren't on the PO - match exception every time. What's the best policy?
Define non-merchandise charges as expected extras with their own tolerance (e.g., freight up to X% of merchandise value auto-accepted, coded to freight), so they stop polluting the exception queue. Surprise surcharges above the cap remain genuine exceptions worth a conversation with the vendor.
How should AP handle an invoice that references a closed or fully-billed PO?
Treat it as a hard exception - it's either a duplicate billing, a late charge that belongs on a new PO, or a closure error. Verify against billing history before anything reopens; never auto-reopen a PO to make a match pass.
What reporting should I run on match exceptions to find chronic problem vendors?
Exception rate and variance dollars by vendor, by cause, trended quarterly. A vendor with persistent price variances has a price-file or behavior problem; persistent quantity variances point at their fulfillment or your receiving. Bring the data to vendor reviews - chronic exceptions are a supplier-management issue, not an AP issue.
What is "park and post" / parked invoice handling for unmatched invoices?
SAP terminology: an invoice is "parked" - saved in the system without posting - while discrepancies resolve, then posted once complete. The concept generalizes: hold the invoice in a visible pre-posting state rather than leaving it in someone's inbox; the liability exists whether or not you've posted it.
Stampli perspective
Stampli automates two-way and three-way matching at the line level - Stampli AI detects the PO, reads invoice lines, and compares them to PO (and receipt) lines even when line structures don't correspond neatly, surfacing discrepancies for human judgment instead of forcing line-by-line reconciliation. Tolerance thresholds and partial-match handling let routine variances flow while genuine exceptions land in a match-exception queue with full context, validated against ERP data before approval and payment.