Tolerance rules: what a matching engine is allowed to wave through

A tolerance is the variance between an invoice and its purchase order that a matching engine is permitted to accept on its own. Set it at zero and every rounding difference becomes an exception; set it too wide and the control stops being one. Most systems express it as a single percentage in a settings screen, and that single number is the reason so many exception queues are simultaneously too full and too permissive.

The useful reframing is that a tolerance is a rule object. It has a subject, a shape and a consequence, and each of those has to be stated explicitly before the number means anything.

Seven things a tolerance rule has to state

An eighth field is worth adding once the first seven exist: a cumulative window, which is the subject of the last section here. Without it the rule can only ever see one invoice at a time.

Why a single percentage leaks at one end and screams at the other

Take a 2 percent tolerance applied everywhere. On a line worth 240, it accepts a variance of 4.80 — and every variance below that reaches a human anyway in most systems, because 2 percent of a small number is smaller than the rounding differences that arise from converting a case price into a unit price. On a line worth 380,000, the same rule accepts 7,600 without anyone seeing it. One number, two opposite failures.

Read the last two columns. The and combination caps exposure in absolute terms while still filtering out proportionally trivial noise on small lines; the or combination is strictly more permissive than either rule alone, which is almost never what anyone intended when they typed both numbers into the screen. If your configuration screen does not say which it uses, that is the first thing to establish, and it is usually faster to test with a deliberately crafted invoice than to read the documentation.

Overbilling and underbilling are not the same risk

Almost every matching configuration uses one symmetric band, and almost no finance function actually holds symmetric views. Being billed more than agreed is money leaving that you do not owe. Being billed less is not a gift: it is usually a signal that something upstream is wrong, and the correction arrives later as a second invoice against a line you thought was closed.

• Overbilling. Tight, and tightest on the absolute rather than the percentage. This is the direction with a direct cash consequence and the one an auditor will ask about, so the acceptance threshold should be defensible as a stated policy rather than inherited from a default.
• Underbilling on price. Looser, because a supplier billing under the agreed price is rarely a loss and frequently a discount they applied deliberately. Still worth posting as a variance, because a pattern of it usually means the PO price is stale.
• Underbilling on quantity. Not a variance question at all. A quantity below the receipt normally means a partial billing, a split shipment, or a receipt posted for the wrong amount — and a second invoice is coming for the remainder, which is when the duplicate risk arrives.
• Quantity above the receipt. Frequently not an overbilling at all but a timing gap, because the delivery happened and the receipt has not been entered. That has its own diagnosis in matching fails because the goods receipt has not been posted yet, and treating it as a price dispute wastes everybody's afternoon.

The other asymmetry is between the header and the lines. A tolerance evaluated on the invoice total will pass an invoice where one line is overbilled and another is underbilled by a similar amount, which is the exact failure examined in totals agree but the line counts do not. Evaluate at line level and use the header check as an additional gate, never as a substitute.

The supplier who always sits just inside the limit

Every individual invoice passes. Each one is 1.4 percent over, comfortably inside a 2 percent band, and no exception is ever raised. Across 300 invoices in a quarter the same supplier has collected a material amount that nobody reviewed, because the control only ever looked at one document at a time. Random variance sums towards zero; drift does not, and the direction of the sum is the tell.

1. Post every accepted variance as a signed value on the invoice — positive for overbilling, negative for underbilling — rather than discarding it once the invoice clears. A variance you did not record cannot be summed.
2. Sum the signed variances per supplier over a rolling window, 90 days being a reasonable default because it survives one quarter's seasonality without hiding a year of drift.
3. Compare the sum against a cumulative cap expressed independently of the single-invoice limit. A useful starting point is 10 times the single-invoice absolute, tuned once you can see the real distribution.
4. Test the ratio of the absolute sum to the sum of absolute values. Near 1 means the variances all run one way, which is drift; near 0 means they cancel, which is noise. This distinguishes a supplier with sloppy rounding from one whose prices have quietly moved.
5. On breach, stop auto-accepting for that supplier and route the next invoice with the whole window attached, so the reviewer is deciding about a pattern rather than about one line.
6. Feed the outcome back into the purchase order rather than the tolerance. If the price has genuinely risen, widening the tolerance is the wrong repair; updating the agreed price and restoring a tight band is the right one.

Tolerance and duplicate detection also interact, which is easy to miss. A re-billed invoice that arrives with a slightly different amount evades an exact-amount duplicate check and then clears on tolerance, so the two controls have to be tuned together rather than owned by different people — a pattern examined in finding the near-duplicate your check missed. Threshold design is not unique to finance either; the same trade-off between a filter that catches everything and a queue that consequently stops being read shows up in dispatch and fleet exception handling, which AI in logistics operations works through in a different setting.

A tolerance is not a measure of how accurate your suppliers are. It is a statement of how much money you are willing to move without a person looking, and it should read like one.

One boundary is worth stating explicitly: tolerance decides whether a variance is acceptable, not when the invoice is due. Those get conflated whenever an approver holds an invoice while a variance is investigated and the discount window closes, which is why invoice date, received date or approval date is a separate decision from this one. When we build variance rules into AI agents and automation for a finance team, the rules stay declarative and versioned rather than living inside a model's judgement, for the same reason the rest of invoice to pay: capture, matching and approvals is built the way it is — and it is the general posture across our finance operations work: the model reads the document, and a rule decides about the money.

• invoice matching
• tolerance
• accounts payable
• controls