Finance Index
What is a match tolerance, and what tolerance levels should I set?
Reference guide to match tolerances exception handling, including request intake, purchasing controls, approval routing, vendor coordination, and finance visibility.
A match tolerance is the allowed variance between PO and invoice (on price and quantity) before an otherwise-matched invoice is flagged as an exception. Tolerances exist because perfect matches are rare - rounding, freight, minor price drift. Set them wide enough that trivial differences flow through and tight enough that real errors stop. Zero tolerance sends everything to exception; loose tolerance lets overbilling pass.
At a Glance
| Aspect | Short Answer | Why It Matters |
|---|---|---|
| A match tolerance | A match tolerance is the allowed variance between PO and invoice (on price and quantity) before an otherwise-matched invoice is flagged as an exception. | Keeps spend controlled before the commitment is made. |
| Related terms | Use both, whichever is tighter, and set them per the math of your spend. | Keeps spend tied to policy, ownership, and review. |
| Control point | Zero tolerance isn't control, it's a queue - when everything is an exception, nothing gets real scrutiny. | Keeps evidence clear and reduces control risk. |
| What match tolerance do most | Low-single-digit percentages paired with a modest dollar floor are common, but "normal" is a starting point, not an answer - the right tolerance reflects your average invoice size, vendor reliability, and risk appetite. | Keeps vendor records and payment decisions reliable. |
| Vendor impact | Tighten tolerances for high-risk or chronically-inaccurate vendors and categories, loosen them for reliable, low-stakes spend. | Keeps vendor records and payment decisions reliable. |
What tolerance levels should I set - percentage vs dollar thresholds for price and quantity variances?
Use both, whichever is tighter, and set them per the math of your spend. A percentage tolerance (e.g., a few percent) handles proportional drift on large POs; a dollar floor (e.g., a small absolute amount) prevents a tiny percentage on a huge invoice from waving through real money. Set quantity tolerance tighter than price for goods (you generally shouldn't pay for more than you received), and recognize services need value tolerance rather than quantity. The honest benchmark is that most mid-market teams land in the low-single-digit-percent or modest-dollar range - but the right number comes from your own exception data, not a template: start moderately tight, watch what auto-passes and what bottlenecks, and tune.
Every invoice goes to exception because our tolerances are zero - how do I tune tolerances without losing control?
Zero tolerance isn't control, it's a queue - when everything is an exception, nothing gets real scrutiny. Pull data on your last few hundred exceptions and look at the distribution: a large share are almost certainly sub-dollar or sub-percent differences that nobody would dispute. Set tolerances that auto-clear those, route the rest to review, and add an audit trail on what auto-passed. You'll cut exception volume sharply while focusing human attention on the variances that actually matter - and you can tighten any category that later shows abuse.
What match tolerance do most mid-market companies use - is 5% or $100 normal?
Low-single-digit percentages paired with a modest dollar floor are common, but "normal" is a starting point, not an answer - the right tolerance reflects your average invoice size, vendor reliability, and risk appetite. Anchor on your own exception data rather than a borrowed number.
How do I set different tolerances by vendor, category, or PO type?
Tighten tolerances for high-risk or chronically-inaccurate vendors and categories, loosen them for reliable, low-stakes spend. Differentiated tolerance is how you keep exception volume sane without going blind on the spend that warrants scrutiny; confirm your system supports it before assuming a single global tolerance is your only option.
Who should resolve match exceptions - AP, the buyer, or the requester?
AP owns the queue and resolves documentation/coding issues; price and quantity disputes route to the buyer or requester who knows what was actually ordered and received. The principle: route each exception to the person with the information to resolve it, not whoever happens to hold the invoice.
How do I route match exceptions back to the original requester or receiver automatically?
Carry the requester/receiver identity on the PO and receipt so the system can route a quantity or delivery dispute to them directly, with context and a one-click response path. Manual "who do I ask?" triage is most of the delay in exception handling.
How do I report on match exception rates and root causes?
Track exception rate (exceptions ÷ matched invoices) and tag each by cause - price drift, quantity/short-ship, missing receipt, missing PO, UOM, freight/tax. The root-cause distribution tells you whether to fix tolerances, receiving discipline, or vendor behavior. A flat exception rate with no cause analysis is just a complaint.
Vendor price increases keep failing match because nobody updated the PO - process fix options?
Build a price-change loop: vendors notify procurement of increases, the PO (or contract rate) is updated before the next invoice, and matching passes cleanly. Tactically, a tolerance accommodates small drift, but persistent failures mean the PO data is stale - fix the data, don't keep widening tolerance.
Should tolerance overrides require approval and who can override a failed match?
Yes - overriding a failed match is paying something that didn't reconcile, so it should require a defined approver above a threshold and land in the audit trail. Unlogged overrides are the loophole; documented overrides are a normal exception.
How do I handle substitute items the vendor shipped that don't match the PO line item?
Decide deliberately: accept the substitute (update the PO line to reflect what was actually received and approved) or reject it. Either way, document the decision against the line - silently paying for an unmatched substitute breaks the audit trail and the inventory record.
Stampli perspective
Stampli supports tolerance-based routing within line-level PO matching: invoices within tolerance flow forward, and those outside it surface as exceptions for review, with the full PO - receipt - invoice context attached so the person resolving it isn't hunting for documents. Because matching, receiving, budget, and the audit trail live in one platform, exception ownership and history travel with the invoice.