How do you set up tolerance thresholds in Plex?

Executive Summary

Plex tolerance thresholds live on the purchase order and are checked at three-way match: the invoice quantity and unit price against the PO, within a percentage or dollar band you configure per part class or vendor. Get the band too tight and AP drowns in holds for pennies. Get it too loose and it passes exactly the overbilling it exists to stop.

The mechanism problem is separate from the configuration problem. Even a well-tuned tolerance only tests the PO line against the invoice line. It does not test the PO price against the contract's rate card, and it does not test whether a volume tier, a rebate clause, or a surcharge condition should have changed the price before the PO was ever cut.

Setting up tolerance thresholds well in Plex is worth doing. It closes one layer of leakage. The layer underneath it, the contract terms that never made it into a PO at all, needs a separate check against the source contract.

1. Where do tolerance thresholds live in Plex?

Tolerance thresholds sit inside Plex's purchase order and receiving configuration, applied at three-way match between the purchase order, the receipt, and the incoming invoice. You set a quantity variance band and a price variance band, expressed as a percentage or a fixed dollar amount, and Plex applies them at the part or vendor level rather than as one setting for the whole system. A match inside the band posts automatically; a match outside it routes to a hold queue.

The configuration typically lives under purchasing or supplier settings, alongside the PO terms themselves. Because Plex is built around a manufacturing shop floor, the default tolerance logic favors quantity variance: a partial shipment or an over-receipt against a work order is common and expected, so quantity bands tend to be set wider than price bands.

Price tolerance is usually the tighter of the two, and for good reason. A quantity variance is visible on the dock. A price variance is visible only if someone checks the invoice against the number that should have been on the PO in the first place, which assumes the PO was priced correctly to start with.

2. What tolerance bands should you actually set?

There is no universal correct band. A wide tolerance clears more invoices automatically but lets more real variance through unchecked; a narrow one catches more but generates holds AP has to clear manually, which slows payment and trains staff to override warnings. The right starting point is segmentation: tighter bands for high-dollar or high-frequency vendor categories, looser bands for low-value consumables where the cost of review exceeds the exposure.

Segmenting by category and by dollar exposure gives a starting point that a single system-wide setting cannot.

A. By vendor category

Freight, contract labor, and professional services carry variable pricing structures (fuel surcharges, overtime rates, rate card tiers) that make small variances routine and expected. A tight band on these categories creates constant holds for legitimate charges. MRO and Class C consumables price flat against a catalog, so a tight band there catches real errors without much noise.

B. By dollar exposure

A percentage-only tolerance lets a large PO clear with a dollar variance that would trigger a hold on a small one. Pairing a percentage band with a dollar cap, whichever is stricter, keeps a small-looking percentage variance on a large PO from clearing silently just because the percentage itself looks small on paper.

3. What does a Plex tolerance check actually test?

A Plex tolerance check tests one thing: does the invoice line match the PO line, within the band you configured. It does not test whether the PO line itself was priced correctly against the vendor contract. If a rate card changed, a volume tier was crossed, or a rebate should have applied, and the PO was cut at the old number, the invoice matches the PO perfectly and clears with no hold at all.

This is the structural limit of any three-way match, not a Plex-specific gap. Three-way matching checks the invoice against the PO and receipt; it does not test the PO against the contract terms that should have generated it. The PO is treated as ground truth, when the PO is itself only as accurate as whoever priced it.

A surcharge is a clear example. A freight contract may state a fuel surcharge that steps down once a diesel index falls below a threshold. Plex has no field for that condition, so a PO built with the old surcharge rate clears every subsequent invoice at the same rate, inside tolerance, indefinitely.

The same happens with a volume tier or a rebate clause: the contract obligation lives in a PDF outside the ERP, and nothing in the tolerance configuration reads it.

4. How do you handle terms Plex tolerance fields can't test?

Terms that live in the contract but not on the PO, rate card tiers, rebate triggers, surcharge step-downs, not-to-exceed caps, need a separate check against the source document, because tolerance thresholds only ever compare the invoice to the PO. That check can be a manual periodic review of open contracts against recent invoices, or a structured audit that reconciles a period of invoices directly against contract terms rather than against Plex's own PO data.

The practical difference matters. A tolerance threshold is a forward control: it stops a new mismatch at the point of payment. A contract-to-invoice review is retrospective: it looks at invoices already paid and asks whether the price on them ever matched what the contract actually says, independent of what the PO said.

Both are needed because they catch different failures. Tightening tolerance bands will not surface a stale rate card that has been silently wrong; only comparing the invoice against the contract directly does that.

5. Should you rely on Plex tolerance settings alone?

No single tolerance configuration, however well tuned, replaces a periodic check of invoices against the underlying contract, because tolerance only ever validates against the PO and the PO can be wrong for an extended period without tripping anything. Treat tolerance thresholds as the first layer that catches obvious entry errors and duplicate charges, and treat a contract-level review as the second layer that catches the drift a correctly-matched PO can still be hiding.

This is not an argument against configuring tolerance carefully. A loose or unset tolerance band lets basic errors through that a five-minute configuration change would stop. Get that layer right first.

What it means is treating tolerance as necessary but not sufficient. A manufacturer running Plex still needs a way to periodically pull contract terms, rate cards, rebate schedules, NTE caps, and check them against what has actually been invoiced over the past several months, not just against what the PO said at the time.

6. What does a contract-level review add on top of Plex?

A contract-level review reconciles invoices already paid against the vendor's actual contract terms rather than against the PO, which surfaces drift that tolerance thresholds structurally cannot see: a stale rate, an unclaimed rebate, a surcharge that never stepped down, or an NTE cap that was quietly exceeded. It is retrospective by design, covering a defined period of historical spend rather than the next invoice in the queue.

This kind of review works across the categories where drift tends to accumulate: freight and 3PL, contract labor and staffing, maintenance and repair, IT and professional services, MRO and Class C consumables, and calibration and safety compliance. Each category has its own contract structure and its own way of drifting from the PO price.

For a Plex environment specifically, the review has to account for how Plex structures its PO and receiving data, since that is the system of record the invoices are being reconciled against, alongside the actual contract documents that sit outside it.

For the wider pattern this sits inside, start with the margin drift guide.

For the wider pattern this sits inside, start with the margin drift guide.

7. Frequently Asked Questions (People Also Ask)

Does Plex support three-way matching out of the box?

Yes. Plex checks the purchase order, the receipt, and the invoice against each other at match time, and the tolerance bands you configure determine how much quantity or price variance is allowed before the match routes to a hold instead of posting automatically.

Can Plex tolerance settings catch a duplicate invoice?

Tolerance bands are built for quantity and price variance, not duplicate detection. Catching a duplicate invoice depends on Plex's invoice numbering and duplicate-check logic at entry, which is a separate configuration from the tolerance fields on the PO match.

Should tolerance bands be the same for every vendor?

No. A single system-wide band ignores real differences between categories: freight and labor pricing move for legitimate reasons that flat-priced MRO items do not, so a band tuned for one category will be wrong for the other in one direction or the other.

What happens when an invoice fails tolerance in Plex?

It routes to a hold queue instead of posting automatically. Someone on the AP or purchasing team then has to review the variance and decide whether to approve it, reject it, or send it back to the vendor before payment proceeds.

Can tolerance fields in Plex read a vendor rate card?

No. Tolerance fields compare the invoice line to the PO line only. A rate card, rebate clause, or surcharge schedule that lives outside the ERP, typically in a contract PDF, is never read by the tolerance check regardless of how the bands are set.

How often should tolerance bands be reviewed?

There is no fixed schedule the registry supports stating. As a practical matter, bands set once at implementation drift out of step with actual vendor pricing behavior over time and benefit from periodic review alongside a contract-level audit.

Is a tight tolerance band always better?

No. A tighter band catches more variance but also generates more holds for legitimate charges, which slows payment cycles and can push staff toward routinely overriding warnings, which defeats the purpose of the control.

Does fixing tolerance settings replace a contract audit?

No. Tolerance settings validate the invoice against the PO. A contract audit validates the PO and invoice history against the actual contract terms, which is the only way to catch a price that was wrong on the PO from the start.

What categories are hardest to set tolerance for in Plex?

Categories with variable, condition-based pricing, such as freight surcharges or contract labor rates, are harder to tolerance correctly than flat-priced categories like standard MRO items, because the variance itself is expected rather than an error.