A tolerance is the difference the company will accept between documents before an invoice is flagged for review. It is set as a fixed amount, a percentage of the line, or both, and it sits at the center of three-way matching: the tolerance decides which mismatches a person ever sees.
For something so consequential, tolerances get remarkably little attention. Most were set at go-live and never revisited.
Tolerance is the cheapest lever in AP
Every tolerance decision moves real workload. Tighten by half a percent and hundreds of trivial rounding differences land in the queue each month. Loosen carelessly and genuine overbilling clears without review. Few settings anywhere in the ERP trade risk against labor this directly, and few are cheaper to change.
Set both a percentage and an absolute cap
A percentage tolerance alone scales badly: two percent of a large equipment line is real money to wave through. An absolute tolerance alone punishes big lines for rounding noise. The standard answer is both together, flagging a line only when it breaches the percentage and the fixed cap, so small noise clears everywhere and large gaps always get looked at.
One tolerance for every category is a mistake
Commodity prices drift between order and invoice as markets move. Catalog parts should land on the penny. Freight-heavy categories carry surcharges that behave differently from unit prices. A single company-wide tolerance treats all of these the same, which guarantees it is wrong for most of them. Set tolerances by category, and for the handful of suppliers with distinctive billing behavior, by supplier.
Price and quantity deserve different limits
A price gap is a commercial disagreement; a quantity gap means paying for goods with no evidence they arrived. Most companies rightly hold quantity tighter than price, often to zero over-billing, while giving price room for currency movement and rounding. Treating the two checks as one setting hides that difference.
Review tolerances on a schedule, and let the queue testify
The exception queue is a running audit of the settings. A queue full of cent-level price flags says a tolerance is too tight. Overbilling found only in year-end audits says one is too loose. Review the settings against the queue a few times a year, and treat every recurring low-value flag as a configuration bug rather than a workload to staff. Resolution of what remains should run autonomously, so tuning tolerances stops being a trade between control and headcount and becomes a pure control decision.
Fragment resolves the exceptions tolerances still catch by reading the contract, order, and history behind each flag. See how Fragment reads that context or request a demo.