Every Tolerance Ships at Zero
Four matching tolerances on a purchase order, and every one of them ships at zero — so any variance at all is a discrepancy. Over-receipt is refused, payment on a discrepancy is blocked, and an override that excuses one is wiped the moment the documents change and the order reconciles.
A supplier sends one extra unit as a goodwill gesture, and the receipt is refused. That is not a bug — it is four settings, all of them at their strictest value, doing exactly what they say.
Matching a purchase is the oldest control in procurement. You ordered something, you received something, you were invoiced for something, and the three should describe the same transaction. Where they do not, somebody has made a mistake or somebody is being dishonest, and either way you should find out before you pay.
Every system that does this has to answer one question that the textbook does not: how close is close enough. And that answer is a number, sitting in a settings table, that almost nobody looks at.
The four numbers
| Setting | Default | What the default means |
|---|---|---|
| Over-receipt tolerance | 0% | Receiving even one more than ordered is over-receipt |
| Block over-receipt | On | And that receipt is refused rather than recorded as an exception |
| Quantity match tolerance | 0% | Any difference in quantity, per line, is a discrepancy |
| Price match tolerance | 0% | Any difference in price, per line, is a discrepancy |
| Block payment on discrepancy | On | An order with a discrepancy cannot be paid |
| Block payment before receipt | Off | Paying for something not yet received is allowed |
Read that column of defaults as a position rather than as a set of unconfigured fields. Five of the six are at their strictest setting. The system ships assuming you meant exactly what you ordered.
Which is the right default, and the one that will annoy you first
A tolerance that ships permissive is a control nobody notices is off. A tolerance that ships at zero is a control everybody notices immediately, because the first slightly-short delivery stops. The second is the better failure: it produces a conversation in week one about what your real tolerance is, rather than a discovery in year two that variances have never been flagged.
The one that is permissive, and why it matters
Blocking payment before receipt is off by default, and it is the odd one out.
The reason is that prepayment is legitimate and common. Deposits, proforma invoices, suppliers who will not ship without payment, anything imported. A system refusing to pay before goods arrive would be wrong for a large proportion of real purchasing, and switching it on would be the first thing many organisations had to undo.
But it is worth knowing it is off, because the other five defaults create an impression of strictness that this one does not share. An order can be paid before anything has been received, and none of the matching tolerances is involved in that, because there is nothing yet to match against.
Five settings at their strictest and one at its most permissive is not an inconsistency. It is a judgement about which mistakes are worth blocking.
The status that is not a result
A purchase order carries a match status with four possible values, and one of them is doing quiet but important work.
- Unchecked — the matching has not been run. This is the default, and it is not the same as matching cleanly.
- Awaiting receipt — there is nothing to match against yet, which is a legitimate state rather than a problem.
- Matched — the three documents agree, within tolerance.
- Discrepancy — they do not, and the number of discrepant lines is counted alongside.
Having unchecked as a distinct value rather than folding it into matched is the detail worth borrowing. An order that has never been examined and an order that was examined and found clean are completely different facts, and a system with only a boolean cannot tell you which one you are looking at. The time of the last check is recorded too, so a match result can be read against whether anything has changed since.
And the status is indexed per workspace, which is what makes "show me every order with a discrepancy" a usable screen rather than a scan.
The override that expires by itself
Now the best-designed part of this, and a pattern worth stealing whatever you build.
Sometimes a discrepancy is fine. The supplier substituted an equivalent item, the price moved for a reason everybody agreed to, the short delivery is being completed next week and the invoice is correct. So an override exists: a recorded reason, the person who gave it, and when.
The trap with any override is staleness. Somebody excuses a discrepancy on Monday. On Wednesday a credit note arrives, or a second delivery lands, or the invoice is reissued. The documents are now different — and the override, granted against a situation that no longer exists, is still sitting there making the order payable.
A stale override cannot keep an order payable after its documents change.
So the override is cleared whenever the match is re-run and the order reconciles. The excuse is tied to the situation it excused, and when the situation resolves the excuse goes with it.
This is a small amount of code and it changes what an override means. Without it, an override is a permanent exemption granted once. With it, an override is a decision about a specific state of the documents, which is what everybody assumed it was in the first place.
Setting your own numbers
-
Start at zero and let it complain
For a month. The defaults are already there, so this costs nothing. What you get is a list of the variances your suppliers actually produce, which is a far better basis for a tolerance than a number chosen in advance.
-
Separate quantity from price deliberately
They are different risks. A quantity variance is usually a delivery problem and is visible in the warehouse. A price variance is usually a billing problem and is visible only here. Most organisations want more slack on the first than the second, and having two settings is what lets them.
-
Decide about over-receipt as a policy, not a percentage
Receiving more than you ordered means paying for more than you ordered, or arguing about it. The question is whether your goods-in team should be able to accept it or should have to escalate — which is what the block setting decides, separately from the tolerance.
-
Leave payment blocking on
This is the one that turns matching from a report into a control. Tolerances decide what counts as a discrepancy; blocking payment is what makes a discrepancy matter to anybody.
Five questions for any procurement system about matching
What are the tolerances set to today?
A good answer sounds like
Numbers, per workspace.
What ours actually is
Zero, all four, with over-receipt blocked. Ask for the values rather than whether matching exists — a system with matching and a ten per cent tolerance is doing something quite different from one at zero.
Are quantity and price tolerances separate?
A good answer sounds like
Yes, they are different risks.
What ours actually is
Separate, both per line. A single combined tolerance forces the same slack on a delivery problem and a billing problem.
Can an order be paid while a discrepancy stands?
A good answer sounds like
No, unless somebody records why.
What ours actually is
No by default, and an override needs a recorded reason and identifies who gave it.
What happens to an override when the documents change?
A good answer sounds like
It is cleared and the match re-runs.
What ours actually is
Cleared when the match re-runs and the order reconciles. This is the question that finds stale exemptions, and most systems have no answer to it.
Can you tell a clean match from one that never ran?
A good answer sounds like
Yes, they are different statuses.
What ours actually is
Yes — unchecked is a distinct value from matched, with the time of the last check recorded. A system using a boolean here cannot distinguish them.
Our take
The defaults here are opinionated in the right direction and will irritate you in the first fortnight, which is the point. A tolerance shipped at a comfortable five per cent is a control that never fires and never gets discussed; a tolerance at zero produces an argument in week one about what your real tolerance should be, and that argument is the valuable part. The design detail worth taking away has nothing to do with procurement: an override that is cleared when the thing it excused resolves is a fundamentally different object from an override granted once and left standing. Almost every exemption mechanism in every system is the second kind, and almost everybody assumes it is the first. Where this set of settings is weakest is discoverability — six numbers deciding whether invoices can be paid should be somewhere a finance lead encounters them, rather than somewhere they are found after the first refused receipt.
What AWRA OpsHub does today
- Separate tolerance settings for over-receipt, quantity matching and price matching, all configurable per workspace and all shipping at zero.
- Quantity and price matching applied per line rather than against an order total, so offsetting errors on two lines cannot cancel out.
- A switch deciding whether over-receipt is refused outright or recorded as an exception, independent of the tolerance itself.
- A match status on every purchase order with four distinct values, including unchecked as separate from matched, so an order that was never examined is distinguishable from one found clean.
- A count of discrepant lines and the time the match last ran, held on the order.
- That status indexed per workspace, so filtering every order with a discrepancy is a query rather than a scan.
- Payment blocked on a discrepancy by default, which is what turns matching from a report into a control.
- A separate switch for blocking payment before receipt, shipping off because prepayment and deposits are legitimate.
- An override carrying a recorded reason, the person who gave it and when.
- That override cleared whenever the match re-runs and the order reconciles, so an exemption cannot outlive the situation it excused.
More we can add to your workspace
- A settings screen presenting the six values together as a matching policy, so a finance lead meets them deliberately rather than after the first refused receipt.
- Tolerances per supplier, so a reliable supplier and a problematic one can be held to different standards.
- A currency tolerance distinct from a price tolerance, so an exchange movement on an imported order reads differently from a supplier changing their price.
- A value threshold alongside the percentages, so a one per cent variance on a large order and on a small one can be treated differently.
- Notification when an override is cleared, so the person who granted it knows the order has returned to a matched state.
- A record of past match runs, so an order that reconciled after two attempts shows what changed between them.
Where we point you to a specialist
- We hold that tolerances ship at zero. A control set permissive on installation is one nobody notices is off, and the discovery that variances have never been flagged tends to arrive during an audit rather than during a review.
- We would decline to let an override survive a change in the documents it was granted against. An exemption is a decision about a specific state of an order, and one that persists after a credit note or a second delivery is an exemption nobody consciously granted.
- Where an audit standard or a funder's conditions prescribe how purchases must be matched and what evidence must exist before payment, that requirement governs and we implement it rather than treating our defaults as sufficient. Which conditions bind you is a question for your own advisers and your auditors.
Tolerances per supplier, and a value threshold alongside the percentages, are the two that most organisations reach for once they have watched the zero defaults for a month. Both build on settings that already exist per workspace.
From one policy to a policy that fits
The settings work and their defaults are right. What organisations want after living with them for a month is the ability to say that not every supplier and not every order is the same.
Tolerance per supplier
A reliable supplier and one that routinely ships short held to different standards, rather than one number covering both.
A value threshold beside the percentage
So one per cent of a large order and one per cent of a small one can be treated as the different amounts of money they are.
The six settings on one screen
The smallest item here and the one most likely to change behaviour: a matching policy a finance lead can read and set in one place.
We publish scope, not dates.
Scope your matching policyRun at zero for a month before choosing a number
The defaults are already set, so this costs nothing but attention. What you get is a list of the variances your own suppliers actually produce, and that list is a far better basis for a tolerance than any figure chosen in advance — including a figure a vendor recommends.
Talk through matchingFrequently asked questions
Why are all the tolerances zero?
Because a control that ships permissive is one nobody notices is switched off. At zero, any variance in quantity or price is flagged and over-receipt is refused, which produces a conversation in the first fortnight about what your real tolerance should be. That conversation is the valuable part, and it does not happen when the system silently accepts a five per cent difference from the day it is installed.
Does that mean one extra unit gets a delivery refused?
With the defaults, yes. Over-receipt tolerance is zero and blocking over-receipt is on, so receiving more than was ordered is refused rather than recorded as an exception. Those are two separate settings deliberately: you can allow a percentage of slack, or you can keep the tolerance at zero and let the receipt through as a recorded exception instead of a refusal.
Can we pay for something before it arrives?
Yes. Blocking payment before receipt is the one setting that ships off, because prepayment is legitimate and common — deposits, proforma invoices, suppliers who will not ship without payment, most imports. It is worth knowing it is off, because the other five defaults create an impression of strictness that this one does not share.
What happens to an override when a credit note arrives?
The override is cleared once the match is re-run and the order reconciles. This is the part of the design worth copying elsewhere: an override is a decision about a specific state of the documents, not a permanent exemption, so it should not survive the documents changing. Without that, a discrepancy excused on Monday keeps an order payable through a Wednesday that changed everything.
Why does unchecked need to be a separate status?
Because an order that was never examined and an order that was examined and found clean are entirely different facts, and a system storing a simple yes or no cannot tell you which you are looking at. Keeping unchecked distinct means a list of matched orders is a list of orders somebody actually verified. The time of the last check is recorded alongside, so a result can be read against whether anything has changed since.
Should quantity and price have the same tolerance?
Usually not, and having two settings is what lets you say so. A quantity variance is normally a delivery problem, visible in the warehouse, and often resolves itself when the balance arrives. A price variance is normally a billing problem, visible only at matching, and does not resolve itself. Most organisations end up allowing more slack on quantity than on price.
