How to set tolerance thresholds in Dynamics 365 BC

Executive Summary

Business Central ships a tolerance percentage or amount on purchase invoice matching. Set too tight, it rejects invoices your team has to override anyway. Set too loose, it passes exactly the overbilling a vendor is counting on it to pass. The setting is a single global or per-vendor number, not a contract engine, so it cannot read a rate card, a volume tier, or a not-to-exceed cap.

That gap is structural, not a configuration mistake. Tolerance in BC compares the invoice to the purchase order and receipt: quantity, unit price, line amount. It has no field for a rebate clause, a surcharge expiration date, or a minimum volume commitment, because those terms live in a contract document the ERP never ingests.

A vendor who knows the tolerance band can price an invoice just inside it, and BC will approve it every time.

The fix is not a tighter percentage. It is treating BC's tolerance as the receiving-side check it is, and putting contract terms through a separate review: either a manual audit against the vendor agreement or a diagnostic that matches invoices line by line against the underlying contract.

1. Where do tolerance settings live in Business Central?

Tolerance for purchase invoice matching sits on the Purchases & Payables Setup page, under the Amount Tolerance % and Quantity Tolerance % fields, with an override available per vendor card. These fields govern three-way matching: they set how far an invoice's quantity or line amount can vary from the purchase order and receipt before Business Central blocks posting or flags the line for approval. There is no separate contract-terms table feeding this comparison.

Amount Tolerance % applies to unit cost and line amount. Quantity Tolerance % applies to received versus invoiced quantity. Both accept a positive percentage; the invoice posts automatically only when it lands within that configured band of the PO line, in either direction.

A vendor-level override exists on the vendor card's Invoicing tab, so a vendor with a history of small currency-rounding variances can carry a wider band than the company default without loosening it for everyone else.

None of these fields reference a rate card, a rebate schedule, or a volume commitment. The comparison is always invoice against PO and receipt, both of which reflect what was ordered and received, not what the contract permits the vendor to charge for it.

2. How do you calculate the right tolerance percentage?

Start from your own posting history: pull a sample of matched invoices over a recent period and measure the actual variance between invoiced and ordered amounts, since most of that variance clusters near zero from currency rounding and unit conversion. Set the tolerance just above that cluster, tight enough to flag anything larger, loose enough that legitimate rounding does not generate approval queue noise your AP team has to clear by hand every week.

The working method is algebraic, not a fixed number: take your historical variance distribution, find where it flattens out (the point past which variances stop clustering and start looking like distinct pricing events), and set the band at that point.

A band set from someone else's default, or copied from a prior ERP without re-measuring, will not match your vendor mix. A distributor buying mostly fixed-unit-price goods will show a tighter natural variance than one buying freight, where accessorial charges move the total line amount for reasons a quantity match cannot see.

Revisit the number after a vendor renegotiation or a new contract category is onboarded. A tolerance calibrated for one vendor population drifts out of fit as the population changes underneath it.

3. Can Business Central tolerance catch a rate card violation?

No. Business Central's tolerance fields compare the invoice to the purchase order and receipt, both of which reflect what was ordered internally, not what a contract's rate card, tier, or surcharge schedule permits the vendor to bill. A vendor invoice can match its own PO exactly, sit inside tolerance, and still charge a rate the contract does not allow, because the PO itself was generated at whatever unit price the vendor last quoted.

This is the core limitation, and it is a design boundary rather than a bug. Three-way matching answers one question: does the invoice agree with what was ordered and received? It does not answer a second, separate question: does what was ordered and received agree with the contract?

A rate card lives outside the PO in most contract relationships: a master service agreement, a pricing addendum, or a standalone rate sheet a vendor updates periodically. Business Central has no native field that stores that document's terms and checks an incoming invoice against them line by line.

So an invoice priced above the contracted rate, but matching a PO that was itself keyed at the same inflated rate, clears tolerance cleanly. The control never sees the discrepancy because the comparison point (the PO) was never validated against the contract in the first place. This same gap shows up wherever three-way matching is the only control in place, whether the ERP is Business Central or a peer system covering freight and 3PL controls in NetSuite or maintenance and repair controls in QuickBooks Enterprise.

4. What contract terms fall outside tolerance matching entirely?

Volume tiers, minimum commitments, rebate clauses, and time-bound surcharge or not-to-exceed caps all fall outside what tolerance matching checks. Each depends on a condition, a cumulative total, or a date that lives in the contract document rather than in the purchase order or receipt line. Business Central's matching engine has no field for any of the three, so invoices that violate these terms clear the same tolerance band as invoices that do not.

These four categories describe contract terms a typical service vendor agreement contains, and none of them are quantity or unit-price variances in the sense BC's matching engine tests.

The practical consequence: a company that tightens its tolerance percentage in response to a discovered overbilling will stop that one invoice shape from recurring, but leaves every other clause type unchecked, because the fix addressed the symptom the system happened to be able to see.

A. Volume tiers and minimum commitments

A contract that drops the unit price once volume crosses a threshold has no analog in BC's tolerance fields. The system checks the invoiced amount against the PO amount, not against a tier table that says the rate should have stepped down last month.

B. Rebate and credit memo clauses

Earned rebates depend on cumulative spend tracked outside the transaction being matched. Tolerance matching is line-by-line and transaction-scoped; it has no mechanism to accumulate spend across invoices and test whether a rebate should have been triggered or applied.

C. Surcharge and NTE caps

A fuel surcharge with an expiration date, or a not-to-exceed cap on a labor contract, is a condition attached to a clause, not a quantity or amount variance. Tolerance has no field for a date condition or a cumulative cap, so a surcharge that should have expired, or a labor bill that has crossed its NTE, posts cleanly as long as it falls inside the percentage band.

5. Should you build a workaround in Business Central for contract checks?

You can extend Business Central with custom fields, a rate table per vendor, and validation logic on posting, and some teams do. The tradeoff is that contract terms change on renewal cycles the ERP customization will not track automatically, and someone has to own re-entering every rate card, tier, and cap by hand whenever a contract is renegotiated. That maintenance burden is the real cost, not the initial build.

A custom extension can, in principle, store a rate per SKU or service line per vendor and flag an invoice that exceeds it. Several BC partners have built versions of this for specific verticals.

The harder part is upkeep. A rate card table is only as accurate as the last person who updated it after a contract amendment, and contract amendments arrive as PDFs, emails, and side letters, not as structured data feeds into the ERP.

For a company running a handful of vendor contracts with simple, stable pricing, a custom table can work. For a company managing dozens of service vendor contracts across freight, labor, maintenance, and IT categories, each with its own tier structure and renewal date, the maintenance load can outpace what an internal build sustains without dedicated ownership. The same build-versus-buy tradeoff applies whether the checking layer is a custom BC extension or a spreadsheet: see build vs. buy: can you do contract-to-invoice matching in Excel.

6. What should you check outside Business Central's tolerance settings?

Match every invoice against the actual contract document, not the PO, for rate card compliance, volume tier triggers, rebate accrual, and surcharge or NTE expiration. This is a periodic review exercise, not a real-time posting control, and it needs someone reading the contract's fine print alongside the invoice line. Tolerance in BC still does its job of catching quantity and rounding variance; it was never the layer meant to catch contract-specific terms.

This kind of review is exactly what an invoice-to-contract audit does that a purchase-matching tolerance cannot: it starts from the contract document, not the PO, and tests the invoice against clauses that never entered Business Central as structured fields.

For a company deciding whether to build this checking capability internally or bring in a fixed-scope review, the deciding factor is how many contracts and categories are in scope, and how often those contracts change, which is the question addressed in diagnostic or software: what to buy first. Similar contract-versus-PO gaps also show up in IT and professional services controls in NetSuite and calibration and safety compliance controls in QuickBooks Enterprise for readers running those systems instead of BC.

1. Rate card comparison: Pull the current rate sheet or pricing addendum and check the invoiced unit price line by line, independent of what the PO says.
2. Volume tier trigger: Track cumulative spend or units against the contract's tier thresholds to confirm the rate stepped down when it should have.
3. Rebate accrual: Reconcile earned rebates against what has actually been credited, since BC's matching has no accrual mechanism to catch a missed one.
4. Surcharge and NTE conditions: Check surcharge expiration dates and cumulative not-to-exceed totals against the contract clause, not against the invoice amount alone.

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 Business Central's tolerance setting apply to service invoices the same way it applies to goods?

Yes, the same Amount Tolerance % and Quantity Tolerance % fields apply, though a service line without a distinct received quantity often relies more heavily on the amount tolerance than the quantity check. The comparison still runs against the PO and receipt, not against a service contract's rate terms.

Can I set a different tolerance for freight vendors than for MRO vendors?

Yes, through the vendor card override on the Invoicing tab, which lets a specific vendor carry a wider or narrower band than the company default. There is no category-level setting; each override applies to one vendor at a time.

Will tightening tolerance stop a vendor from overbilling on a rate card?

No. Tolerance compares the invoice to the PO, and if the PO itself was generated at the inflated rate, a tighter band does not catch it. Rate card compliance requires comparing the invoice to the contract document directly, which tolerance settings do not do.

What happens when an invoice falls outside the tolerance band in Business Central?

The system blocks posting or routes the line to an approval workflow, depending on how matching is configured. It does not reject the invoice outright; someone still has to review and either override or return it to the vendor.

Does Business Central have a native field for rebate clauses?

No. Rebate accrual depends on cumulative spend across multiple invoices over time, and Business Central's purchase matching evaluates one transaction at a time. Tracking a rebate clause requires a process outside the matching engine, whether manual or a separate audit.

Should tolerance be set the same across all vendors?

A single company-wide default is a reasonable starting point, but vendor-level overrides let you widen the band for vendors with a known pattern of small rounding variances without loosening the control for everyone else. The right default still comes from your own posting history, not a generic figure.

Can a third-party app or extension add contract-term checking to Business Central?

Some BC partners have built custom extensions that store a rate table per vendor and validate invoices against it. The ongoing cost is keeping that table current every time a contract renews or a rate changes, which is a manual maintenance task the extension itself does not solve.

Is invoice tolerance the same thing as a contract compliance check?

No. Tolerance is a receiving-side control that compares an invoice to what was ordered and received. A contract compliance check compares the invoice to what the vendor agreement actually permits, which is a separate document tolerance never reads.