How do you set up tolerance thresholds in NetSuite?

Executive Summary

NetSuite's variance tolerance fields, found under Accounting Preferences and repeated at the vendor record, compare a bill's unit price and quantity against the purchase order line. Set correctly, they stop a bill from posting automatically when the price on the invoice does not match the price on the PO within a configured percentage or amount.

That is the whole mechanism. It is a two-way match between two numbers already inside NetSuite: the PO line and the bill line. It has no visibility into the contract PDF that generated the PO price in the first place, so it cannot tell you whether the PO price itself is still correct.

The setup below gets the native control working as designed. The sections after it explain, honestly, what that control cannot see, so the reader is not left assuming a passed match means a correct invoice.

1. Where do you set tolerance thresholds in NetSuite?

NetSuite's price and quantity variance tolerances live under Setup > Accounting > Accounting Preferences, on the Items/Transactions subtab, as percentage or amount fields for bill matching. A vendor-specific override sits on the vendor record's Purchasing tab, which takes priority over the global default when populated. Both fields apply only to bills entered against an existing purchase order; a bill with no PO reference has nothing to compare against and bypasses the check entirely.

The global fields are labeled for price variance and quantity variance, each with a percentage and an amount option. NetSuite evaluates whichever threshold is reached first when both are set, so a dollar cap and a percentage cap on the same line will trigger on whichever the invoice crosses first.

The vendor-level override exists because a single global number rarely fits a supplier base that spans a freight carrier with volatile fuel surcharges and an MRO supplier with a fixed rate card. Setting it per vendor is the only way to avoid choosing between a tolerance too loose for one and too tight for the other.

A bill entered by three-way match against a PO and receipt uses the same fields. The comparison logic does not change; only the additional receipt-quantity check is layered on.

2. What actually happens when a bill exceeds the threshold?

A bill that exceeds the configured variance is held for approval rather than blocked outright. NetSuite marks the line with a variance flag and routes the bill through whatever approval workflow is configured, instead of posting it straight through. If no approval workflow exists, the variance flag still appears on the bill record but nothing stops an AP clerk from approving and posting it manually within the same session.

This is the detail that determines whether the setting does anything at all. The threshold by itself is a flag, not a gate. Its enforcement value comes entirely from what happens after the flag is raised: a configured approval routing that requires a second person to clear it, or nothing.

A company that sets a tight tolerance but has no approval workflow behind it has built a reporting field, not a control. The variance shows up in a saved search or a SuiteAnalytics report after the fact, which is useful for audit trail but does not stop the payment.

For the threshold to function as a control rather than a record, it needs an approval workflow tied to the Bill record type, scoped to trigger on the variance flag specifically.

3. How do you decide what percentage to set?

NetSuite gives no recommended default, because the right threshold depends on how the vendor's pricing actually moves, not on a general best practice. A vendor billed off a fixed rate card can run a tight tolerance, close to zero, because any variance signals an error. A vendor billed against a fuel surcharge or spot-rate index needs room for legitimate movement, or the flag fires on every bill and gets ignored.

Setting the number too tight against a volatile-price vendor trains the AP team to wave through the exception queue without reading it, because most of what lands there is normal movement rather than an error. That habit removes the value of the control faster than never having it at all.

Setting it too loose against a fixed-rate vendor lets a real overcharge pass silently through. A stale rate applied after a contract renewal can sit under a loose tolerance for months without ever triggering review.

The practical approach is to group vendors by pricing mechanism first: fixed rate card, tiered volume pricing, indexed surcharge, and set the tolerance per group rather than per vendor individually. This keeps the count of distinct thresholds manageable while matching each group's actual price behavior.

4. What does the tolerance threshold not check?

The threshold compares the bill line to the PO line. It does not read the underlying vendor contract, so it cannot detect a PO price that was entered wrong in the first place, a rebate tier the vendor stopped applying, a surcharge that should have expired, or a not-to-exceed cap defined only in a signed agreement. If the PO price is wrong, a bill that matches it perfectly passes with zero variance.

This is the structural limit, not a configuration mistake. NetSuite's variance check is a two-way match between two numbers already inside the system. Contract terms such as volume-tier rebates, minimum commitment credits, or NTE caps live in a PDF outside the ERP, and nothing in the Bill screen reads that document.

A rate schedule violation is a case in point: the PO was built off last year's rate, the vendor's new rate is higher, and both the PO and the bill agree on the new, wrong number. Zero variance, clean match, and the overcharge posts.

Three-way matching against a receipt adds a quantity check against what physically arrived. It still does not test a surcharge's expiration condition or a rebate clause's trigger volume, because neither of those exists as a field NetSuite compares.

5. Which categories need this control?

Any category billed against a rate card, a tiered schedule, or a surcharge structure benefits from a tolerance threshold, because each has a specific price field that can drift out of sync with the PO. The mechanism differs by category even though the NetSuite setting is identical across them: freight surcharges move on a carrier schedule, labor rates carry NTE caps, and calibration contracts carry annual escalation clauses that reset what the correct price should be.

A tolerance set once at implementation and never revisited drifts out of relevance as vendor pricing structures change. Each category below has its own price mechanism, which is why a single global percentage rarely serves all of them well.

See the category-specific pages on freight and 3PL controls in NetSuite and contract labor and staffing controls for how the underlying contract terms map to what NetSuite can and cannot enforce natively.

• Freight and 3PL: Fuel surcharges and accessorial fees change on a schedule set by the carrier, so the PO price can be correct on the day it was cut and wrong two invoices later.
• Contract labor and staffing: Bill rates tied to a not-to-exceed cap or a shift differential can post above the agreed ceiling if the PO was built on a base rate alone.
• Maintenance and repair: Time-and-materials work orders often carry a labor rate and a parts markup that were never reconciled against the master service agreement.
• MRO and Class C consumables: High line-item volume on low-dollar parts makes a tight percentage tolerance noisy unless it is paired with a dollar-amount floor.
• Calibration and safety compliance: Recurring service contracts with an annual escalation clause need the tolerance reset each renewal, or the new correct price trips the old threshold.

6. Should you rely on the native setting alone or add a review layer?

The native threshold is worth configuring regardless, because it catches PO-to-bill mismatches at low incremental cost once set up correctly. It is not sufficient on its own for a company whose vendor contracts carry rebate clauses, tiered volume pricing, or NTE caps, because those terms live outside the two fields NetSuite compares.

The decision is not whether to use the native setting. Configure it, set the approval workflow behind it, and revisit the percentages by vendor group at each contract renewal. That much costs nothing beyond the setup time.

The separate decision is whether the company needs something that reads the contract itself: matches an invoice against a rate card, a rebate tier, or a surcharge expiration date rather than against a PO price that may itself be stale. That requires either a manual periodic review of contracts against paid invoices, or a fixed-scope diagnostic built for exactly that comparison.

A periodic audit tests a window of history against the contract terms directly. A native ERP tolerance tests the next invoice against the PO. They answer different questions, and a company that has never run the first one cannot say whether its PO prices are still correct in the first place.

For the wider pattern this sits inside, start with the margin drift guide. See also the six categories drift hides in and what is margin erosion? causes and prevention for manufacturers.

For the wider pattern this sits inside, start with the margin drift guide. See also the six categories drift hides in and what is margin erosion? causes and prevention for manufacturers.

7. Frequently Asked Questions (People Also Ask)

Does NetSuite have a built-in tolerance threshold for bill matching?

Yes. NetSuite's price and quantity variance tolerances are configured under Accounting Preferences, with an optional override at the vendor record level. They compare a bill's line price and quantity against the purchase order line the bill was entered against.

Will a bill over the tolerance threshold be blocked automatically?

Not by itself. NetSuite flags the variance and, if an approval workflow is configured, routes the bill for review. Without that workflow, the flag appears on the record but an AP clerk can still approve and post the bill manually.

Can NetSuite check a bill against the actual vendor contract?

No. The tolerance fields compare the bill line to the PO line, two numbers already inside NetSuite. Neither field reads the contract PDF, so a rebate clause, a surcharge expiration date, or an NTE cap defined only in the agreement is invisible to the check.

Should tolerance thresholds be the same for every vendor?

No. A fixed rate card vendor supports a tight tolerance because any variance likely signals an error. A vendor billed against a fuel surcharge or spot-rate index needs a wider tolerance or the exception queue fills with normal price movement and stops getting reviewed.

Does three-way matching close the gap that tolerance thresholds leave open?

Partially. Three-way matching adds a check against the receipt quantity, confirming what physically arrived. It still does not test whether a surcharge has expired or whether a rebate clause's trigger volume was met, because neither exists as a field NetSuite compares.

What happens if the PO price itself was entered incorrectly?

The tolerance check passes with zero variance, because it only compares the bill to the PO, not the PO to the contract. A wrong PO price and a matching bill price produce a clean match and the error posts unnoticed.

How often should tolerance percentages be revisited?

At each contract renewal for the vendor in question. A percentage set at implementation and left alone drifts out of relevance as pricing structures, surcharge schedules, or rate cards change over the life of the contract.

Is a tolerance threshold enough to catch a stale rate card?

No. A stale rate card produces a PO and bill that agree with each other while both are wrong relative to the current contract. Catching that requires comparing paid invoices against the contract directly, which the tolerance fields do not do.