Set up tolerance thresholds in SAP Business One

How to configure quantity and price tolerance limits in SAP Business One so invoices post inside contract terms instead of just inside rounding error.

Twitter LinkedIn WhatsApp
Ask AI: ChatGPT Claude Gemini Grok
Set up tolerance thresholds in SAP Business One

Margin drift is the gap between what a vendor contract says and what the invoice actually charges. SAP Business One gives you a place to set that gap's outer edge: tolerance thresholds on quantity and price variance, checked at goods receipt and AP invoice.

Most implementations set these fields once, during rollout, and never revisit them against the contract library. That single fact is why tolerance thresholds in SAP Business One end up doing far less than the name suggests.

Executive Summary

SAP Business One's tolerance fields sit in two places: the item master and the AP invoice document settings, controlling how far a received quantity or unit price can vary from the purchase order before the system blocks or flags posting. The mechanism is a percentage or fixed-amount band, applied uniformly to whatever document it is configured against.

The gap is that a tolerance band is a single number and a contract is not. A rate card can specify a volume tier, a rebate trigger, an NTE cap, and a surcharge schedule that expires on a date. SAP Business One's tolerance setting can only ask "is this price within X% of the PO price," not "is this the correct price under this month's tier." A price can sit inside tolerance and outside the contract at the same time.

What changes this is treating the tolerance field as the last line of defense, not the control itself, and keeping the contract terms it should be checking against in a document the AP team actually reads before approving.

1. Where do you configure tolerance thresholds in SAP Business One?

Quantity and price tolerance in SAP Business One is set in two places: the Item Master Data record, under Purchasing Data, for item-level variance limits, and the Document Settings for Purchase Order and AP Invoice, under the Per Document tab, for a document-wide default. A percentage or fixed value entered there controls how far a receipt or invoice can vary from the PO before the system issues a warning or a hard stop, depending on how the message log is.

The item-level setting takes precedence over the document-wide default when both exist, so a mixed configuration, where some items carry their own tolerance and others fall back to the document setting, is common and easy to lose track of.

General Settings, under Per Document, also carries a message log entry for each tolerance type: quantity variance, price variance, and total variance. Each can be set to Error, Warning, or no message. An Error setting blocks the document from adding until the user overrides it with the right authorization, which is the closest SAP Business One comes to a hard control.

A warning-only setting posts the invoice regardless and simply logs that the threshold was crossed. On many systems this is the default left over from initial rollout, which means the tolerance exists on paper but stops nothing in practice.

2. What tolerance types can you actually set?

SAP Business One supports three tolerance types on the purchasing side: quantity tolerance, comparing received quantity to ordered quantity; price tolerance, comparing invoiced unit price to PO unit price; and total tolerance, comparing the invoice's total value to the PO's total value. Each can carry its own percentage or amount and its own message level, so a business can allow a wider band on quantity than on price, or the reverse.

These three types are configured independently, which means a company can run a tight price tolerance while leaving quantity tolerance wide, or the reverse, matched to where its own risk actually sits.

A. Quantity tolerance

This compares the quantity on the goods receipt PO, or the AP invoice if entered directly, against the quantity on the purchase order. It catches a partial shipment invoiced as a full one, or a receipt logged for more units than the PO authorized. It says nothing about whether the unit itself, or the freight to move it, was billed at the contracted rate.

B. Price tolerance

This compares unit price line by line. It is the closest SAP Business One gets to a rate-card check, but it checks against the PO's stored price, not against the vendor's current contract. If the PO was built from a stale price list, price tolerance confirms the invoice matches the wrong number precisely.

C. Total tolerance

This checks the invoice's grand total against the PO's grand total, catching a combination of small variances that individually clear their own thresholds but sum to a material gap. It is the type most often left unconfigured because it duplicates the other two in the common case.

3. Why does a passing tolerance check not mean the invoice matches the contract?

A tolerance check compares the invoice to the purchase order, not to the underlying vendor contract. If the PO price is wrong, stale, or missing a volume-tier step-down, the invoice can sit inside tolerance while still being wrong against the contract. Rebate clauses, minimum volume commitments, and surcharge expiration dates live in the contract PDF, not in any field SAP Business One's purchasing module reads or evaluates.

The PO is only as accurate as whoever entered it, and it is set once, near the start of a purchasing cycle. A three-tier volume rate, where the per-unit price drops after a cumulative threshold, requires updating the PO's price each time the tier changes. If nobody does that, tolerance checks every subsequent invoice against a price that stopped being correct months earlier.

Surcharge schedules carry the same problem in the other direction. A fuel surcharge or peak-season accessorial that was contractually time-boxed can keep appearing on invoices after its expiration date, at a price that matches the PO because the PO was never told the surcharge had a stop date to begin with.

Three-way matching, which is what a quantity and price tolerance check together approximate, tests the invoice against the PO and the receipt. It does not test a surcharge's expiration condition, a rebate's earn threshold, or an NTE cap on a services contract, because none of those are fields the PO carries.

4. How wide should you set quantity and price tolerance?

There is no universal percentage, because the right band depends on what is genuinely normal variance for a given item or vendor, such as a bulk material with expected weighing loss, versus what should trigger review, such as any deviation on a fixed-price services line. Set tolerance per item or per vendor category rather than one document-wide number, and treat a wide default as a gap waiting to be found rather than a convenience.

A band set once during implementation, then left alone, tends to widen in effect over time as prices and volumes shift around it without anyone revisiting the percentage itself.

  • Set item-level, not document-wide: A single document-wide percentage forces the same band onto commodity materials and fixed-price services, when the two have nothing in common.
  • Use Error, not Warning, on price: A warning-only price tolerance logs the exception and posts anyway, which means the control exists in the configuration screen but not in the approval workflow.
  • Set total tolerance separately from price tolerance: A stack of small line-level variances that each clear their own band can still add up to a total worth catching.
  • Review the band against the contract, not against history: A tolerance set to match what invoices have historically looked like will simply keep approving the pattern already present, drift included.

5. What does tolerance checking miss on a services or indirect spend invoice?

Tolerance checking is built around quantity and unit price on a purchase order line, which fits a physical good. Contract labor, maintenance, IT services, and freight invoices carry variance types a PO tolerance field was never built to test: an NTE cap on total contract value, a rate card with time-of-day or overtime multipliers, and a rebate clause tied to cumulative annual spend rather than any single invoice.

A not-to-exceed cap on a staffing or services contract limits total billing across the life of the engagement, not the price on any one line. SAP Business One's tolerance fields evaluate one document against one PO. Nothing in the standard configuration tracks a running total against a cap that spans months of invoices.

A rate card with an overtime or after-hours multiplier requires knowing which hours on the invoice were billed at which rate, information that lives in the vendor's backup documentation, not in the PO's unit price field. Tolerance checking sees a rate and compares it to another rate; it has no way to evaluate whether the multiplier applied was the one the contract specifies.

A rebate clause, similarly, is evaluated against cumulative spend across a period, which is exactly the kind of check a single-invoice tolerance field cannot perform by design.

6. Should you rely on SAP Business One's tolerance settings alone, or add a separate control?

Tolerance settings are worth configuring correctly because they catch a real category of error at the point of entry, and configuring them well costs nothing beyond attention. But they were built to test a PO, not a contract, so they leave rate-card drift, surcharge persistence past an expiration date, and NTE overruns on services contracts uncaught by design, regardless of how tightly the bands are set.

Tightening a tolerance percentage narrows the gap for quantity and price errors on items where the PO price is correct and current. It does nothing for the case where the PO price itself is the problem, which is a common source of drift on indirect spend categories where prices change by contract clause rather than by catalog update.

The more durable fix is not a tighter tolerance number. It is confirming that the PO price reflects the contract's current terms before the tolerance check ever runs, which means reading the contract, not the purchasing module. That work is either a periodic review someone owns, or a forward control that checks invoices against the contract terms directly rather than against a PO that assumes those terms are current.

A Margin Drift Diagnostic on an SAP Business One environment starts by testing exactly this gap: which invoices cleared the system's tolerance checks and still diverge from the underlying rate card, volume tier, or NTE cap. That is where recovery usually sits, because it is the variance the system was never configured to see.

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 SAP Business One check invoices against the vendor contract automatically?

No. SAP Business One's standard tolerance fields compare the AP invoice to the purchase order and goods receipt, not to the contract document. A contract's rate card, rebate clause, or NTE cap has to be reflected in the PO manually for tolerance checking to catch a deviation from it.

What is the difference between quantity tolerance and price tolerance?

Quantity tolerance compares the received or invoiced quantity to the PO's ordered quantity. Price tolerance compares the invoiced unit price to the PO's stored unit price. They are configured separately and can carry different percentage bands and different message levels.

Can tolerance thresholds block an invoice from posting?

Yes, if the message log for that tolerance type is set to Error rather than Warning. An Error setting stops the document from being added until a user with the right authorization overrides it. A Warning setting logs the exception but allows the document to post anyway.

Where in SAP Business One do you set tolerance for a specific item?

Open the Item Master Data record for that item, go to the Purchasing Data tab, and enter the quantity and price tolerance values there. Item-level settings override the document-wide default configured in General Settings.

Why would a price tolerance check pass on an invoice that is still overbilled?

Price tolerance compares the invoice to the PO's stored price, not to the vendor's current contract rate. If the PO price is stale, for example missing a volume-tier step-down, the invoice can match the PO exactly and still be wrong against the contract.

Can SAP Business One track a not-to-exceed cap across multiple invoices?

Not through standard tolerance fields. Those fields evaluate one invoice against one purchase order. An NTE cap that limits total billing across a services engagement spanning many invoices requires a separate running total, tracked outside the tolerance configuration.

Is a wider tolerance band always safer for avoiding blocked invoices?

A wider band reduces false stops but also widens the range of prices and quantities that will clear the check without review. Setting the band per item or vendor category, rather than one wide default across all purchasing, keeps it useful without hiding real variance.

Do surcharges and accessorial charges get checked by tolerance settings?

A surcharge line is checked the same way any other price line is: against the PO's stored value. If the PO does not carry an expiration date for a time-boxed surcharge, tolerance checking has no basis to flag the surcharge continuing to appear after its contractual end date.

Margin Drift Resources