Every automated match needs a line: below this, the difference is rounding and the machine may clear it; above it, a human looks. Where you draw that line is the entire safety story of the product, so it is worth being exact about.
There are two obvious ways to draw it, and both of them are wrong on their own.
A percentage alone
"Clear anything within 1%." Reasonable-sounding, and it scales with the size of the bill, which feels right.
Then a $180,000 bill arrives. One per cent of it is $1,800, cleared with nobody looking. The percentage did exactly what it was told; it is just that a percentage of a large number is a large number.
A cash ceiling alone
"Clear anything under $25." Also reasonable-sounding, and it caps the absolute damage.
Then a $30.00 bill arrives with a $25.00 variance on it. That is an 83% error, and it clears as rounding.
Both, with the tighter one binding
The fix is not a cleverer single number. It is to require both:
A variance is inside tolerance only when it is inside the percentage band AND the cash band.
The consequence is that the tighter of the two always binds. Small bills end up governed by the percentage; large bills end up governed by the dollar ceiling. Neither hole above is reachable, and the rule is still one sentence you can say out loud to an auditor without a footnote.
This is the same shape as an SAP tolerance key, which sets an upper limit on the percentage and an upper limit on the value and checks both. It is not a new idea. It is just one that gets quietly dropped when a tolerance is implemented as a single config field.
MatchRail's bands are 1% and $25, and they are in the source rather than in a settings screen, which is deliberate: it is a control, and a control you can widen from the UI at 4pm on the last day of the month is not much of a control.
Measure against the order, never the bill
One more detail that matters more than it looks. A percentage has to be measured against something, and the obvious candidate — the figure under dispute — is the wrong one.
If you measure the variance against the bill's figure, an inflated bill widens its own tolerance. The bigger the overcharge, the bigger the band it is judged against. Measure against the purchase order's figure instead: that is the number both parties agreed to, before anyone had a reason to move it.
And when there is no order at all, there is nothing to measure against — so the answer is not "clear it", it is "this is an exception". Failing closed is the default, not the fallback.
Quantity gets no tolerance at all
MatchRail's quantity tolerance is zero, and that is not a placeholder for a number to be tuned later.
Money is measured. Quantities are counted. A unit is either on the dock or it is not, and any non-zero value here would mean the product silently paid for goods nobody recorded arriving — which is the single failure a three-way match exists to prevent. There is no size of shortfall that clears itself.
And the arithmetic is integer
All of it runs in whole cents. Not because floating point is scary in the abstract, but because 0.1 + 0.2 deciding a money question is a defect nobody will ever see: the variance it invents is a few thousandths of a cent, the variance it hides is the same, and both round out of the report. A control an auditor will ask about should not have a category of error that is invisible by construction.