Tolerances in Accounts Payable, Explained
A tolerance is the band within which a difference is accepted instead of raised.
That definition sounds mild, so it is worth being blunt about what it means in practice: a tolerance is a decision about how much you will pay without anyone looking. Set well, it keeps the exception queue focused on things that matter. Set badly, it is an unattended budget.
What a tolerance is genuinely for
Some differences are noise. Rounding to two decimal places on a per-line calculation, a currency conversion applied at a slightly different moment, a tax figure computed in a different order — these produce differences of pennies that mean nothing.
Without a tolerance, every one of those becomes an exception, a queue fills with items no human action can improve, and reviewers learn to clear things without reading. A tolerance that is too tight destroys the value of the check as surely as one that is too loose, because it trains people to stop looking.
The purpose is to distinguish noise from signal. Not to make things pass.
Why quantity tolerance should be zero
Price legitimately drifts. Quantity does not.
Either 5 units arrived or 8 did. There is no measurement error in counting boxes, no rounding, no conversion. A quantity discrepancy is always a real event: a short delivery, a miscount, a double bill, or a vendor error.
So a quantity tolerance does not absorb noise, because there is no noise to absorb. It only absorbs findings — and specifically it absorbs the small ones, which are exactly the ones a systematic error produces before it becomes a large one.
Consider a vendor whose system consistently rounds quantities up by one unit on part-cases. With a quantity tolerance of two units, every one of those invoices passes silently. The error is invisible for a year and then discovered as an annual figure.
The correct setting is zero, and the correct design is not to make it configurable at all.
(Claiming fewer units than were received is a different matter. That is not an overcharge, it is often a legitimate instalment, and it should be a warning rather than a failure.)
Percentage and cap: whichever binds first
Price tolerance is usually expressed as a percentage. On its own, a percentage has a failure mode that gets worse exactly where it matters most.
A 2% tolerance is:
- 4 pence on a £2 item. Sensible.
- £400 on a £20,000 item. Not sensible.
The same rule that correctly ignores rounding on small lines quietly waves through a substantial overcharge on large ones — and large lines are where a percentage error costs real money.
The fix is to state both a percentage and a flat cap, and apply whichever binds first:
accepted if the difference is within 2% and within £50
Now the small line gets its 2% and the large line gets stopped at £50. The percentage handles proportional noise; the cap handles absolute exposure.
Anywhere you see a bare percentage tolerance with no cap, ask what it evaluates to on your largest line.
The asymmetry: cheaper is always fine
A tolerance band should not be symmetric.
If the vendor charges less than the agreed price, accept it, at any magnitude. There is no amount by which a vendor undercharging you is a problem requiring a human. A symmetric ±2% band creates exceptions for invoices that are unambiguously in your favour, which is pure queue noise.
If the vendor charges more, apply the tolerance.
The same asymmetry applies to quantity: over-claiming stops the document, under-claiming is a warning.
You are checking for overcharge. Build the rule to say so.
Tax tolerance is a rounding band, not a policy
Tax variance deserves its own, much tighter, setting — and it should be understood as a rounding band rather than a tolerance in the same sense.
Tax computed line-by-line and then summed can differ by a penny or two from tax computed on the document total. That is arithmetic, not disagreement, and it needs a small band.
A tax difference beyond a few pence is not rounding. It is a different tax treatment — a different rate, a different tax group on the item or the vendor, a different jurisdiction — and it should be looked at. Setting a generous tax tolerance to make those stop appearing does not resolve them; it hides a master-data problem that will keep producing wrong figures.
Where to set them
Tolerances belong to a policy, and policies get applied to vendors. Not one global number, and not a setting per vendor typed independently.
The reason is maintenance. A single global tolerance cannot accommodate the genuine differences between a commodity supplier whose prices move weekly and a contracted supplier whose prices are fixed. Per-vendor numbers typed independently drift, and nobody can answer “what are our tolerances?” without reading them all.
A small number of named policies — standard, contracted, commodity — assigned to vendors gives you both.
How to tell you have set them badly
Too tight: the queue is full of items where the resolution is always “accept”. Reviewers clear them in batches without reading. The check has become theatre.
Too loose: the queue is nearly empty, and periodic reviews keep turning up small overcharges that nobody flagged. The check is passing things it should have caught.
The useful discipline is to look, once a quarter, at the distribution of variances that passed. If there is a cluster sitting just inside the tolerance, that is not noise — that is a vendor, or a rule, that has found the edge of your band and settled against it.