Setting tolerance thresholds in SyteLine

Executive Summary

SyteLine's price and quantity tolerance fields compare an invoice against the PO line, not against the underlying contract. That mechanism catches data entry and receiving errors well. It does not catch a stale PO price left behind when a rate card, rebate clause, or surcharge expiration changed under the contract, because the tolerance check never looks at the contract at all.

The fix is not a wider or narrower tolerance band. It is a second layer that checks the PO line against the contract terms themselves, on a schedule the contract sets rather than the PO's last update. That layer sits outside SyteLine's native matching, whether run manually or built as a control.

1. Where do you configure tolerance thresholds in SyteLine?

Tolerance thresholds in SyteLine are set as percentage or dollar variance fields attached to the item master, the vendor record, or an individual PO line, and they control how far an invoice's unit price or extended amount can differ from the PO before the system holds it for review instead of posting it automatically. The fields exist specifically to separate invoices worth a human's time from invoices that match closely enough to process straight through.

The item master carries a default tolerance that applies whenever no more specific value overrides it. A vendor-level tolerance overrides the item default for every PO issued to that vendor, which is useful when one supplier's billing system rounds differently or bills in a currency with conversion variance. A PO line tolerance overrides both, and is the level to use when a specific contract term justifies a wider or narrower band than the vendor's usual pattern.

Most teams set tolerance as a percentage of unit price rather than a flat dollar amount, because a fixed dollar band is too loose on a small line item and too tight on a large one. A percentage band on a low-cost part and the same percentage band on a high-value machine component behave very differently in dollar terms, which is the point: the percentage scales with the transaction.

Quantity tolerance is a separate field from price tolerance and should be set independently. A vendor that reliably ships exact quantities does not need the same quantity band as one that ships in case packs and rounds up.

2. What does the tolerance check actually compare against?

The tolerance check compares the invoice line against the price and quantity recorded on the purchase order line, not against the underlying vendor contract. If the PO line was created correctly and never needed to change, that comparison is sound. If the contract has a rate card, a volume tier, or a rebate schedule that should have changed the reference price since the PO was cut, the tolerance check has no way to know and compares against a stale number.

This is the structural limit, not a configuration mistake. Three-way matching in SyteLine checks the invoice against the PO and the receipt. It was built to catch data entry errors and receiving discrepancies, and it does that well.

It does not test whether a surcharge on the invoice has an expiration date that has already passed, or whether a rebate clause in the master agreement should have lowered this month's net price.

A rate card gets loaded into the PO line once, usually at the time the contract is signed or renewed. If the vendor's rates change under a volume tier trigger, or a promotional rate reverts to standard, nothing in SyteLine prompts anyone to update that PO line. The tolerance band then holds steady around a stale reference point, and every invoice that matches the stale price passes clean.

What SyteLine's tolerance check tests versus what a contract compliance check tests.

3. How should you size the tolerance band for indirect spend?

Indirect spend categories such as freight, contract labor, and MRO carry line items with legitimate, contract-permitted variance, which means a tolerance band tight enough to catch real drift often also generates a volume of false holds an AP team cannot review. The band has to be sized to the category's normal variance, not set to one blanket percentage across every vendor and every kind of spend.

A fuel surcharge on a freight invoice moves with a published index and is expected to vary invoice to invoice, so a tight tolerance on that line produces holds that a reviewer clears without finding anything, and the team learns to wave them through. A fixed MRO catalog item, by contrast, should barely vary at all, so the same wide band that suits freight lets real drift on that line pass unreviewed.

Setting tolerance by category rather than by one company-wide default takes more setup work but avoids both failure modes: alert fatigue on variable categories, and blind spots on stable ones. This is configuration work inside SyteLine itself, and it is worth doing regardless of what other control sits alongside it, because a badly sized tolerance band undermines any review process built downstream of it.

4. Can a wider PO tolerance replace a contract compliance review?

No. Widening or narrowing the tolerance band changes how many invoices get held for manual review inside SyteLine's existing comparison, but it does not add a comparison against the contract itself. A wider band lets more invoices post automatically, including ones that drifted from the contract but stayed close enough to a stale PO price.

A narrower band creates more manual holds without giving the reviewer contract terms to check the hold against.

This distinction matters because tightening tolerance is the fix AP teams reach for first, since it is the lever available inside the system they already use. It reduces the wrong kind of error. A tighter band catches an invoice that deviates from the PO, but the PO was never the problem if the PO itself has gone stale against the contract.

A reviewer clearing a tolerance hold in SyteLine sees the PO price and the invoice price side by side. They do not see the rate card, the rebate clause, or the NTE cap unless someone pulls the contract PDF separately, which most AP teams do not do on a routine hold. The hold gets cleared on PO agreement, not contract agreement, and the drift, if there is any, survives the review.

5. Should the contract check happen in SyteLine or alongside it?

SyteLine's tolerance fields are built for PO-to-invoice comparison and were not designed to hold rate cards, rebate terms, or NTE caps as structured, checkable data, so a contract compliance check generally has to run as a separate step rather than a native SyteLine configuration. That step can be a periodic manual review of PO lines against contract files, or a forward control that runs the comparison on every invoice.

Neither option lives inside SyteLine's tolerance configuration screen, because that screen has nowhere to store a rebate schedule or an NTE cap in the first place. The choice is between running the comparison on a calendar and running it on every transaction.

A. Periodic manual review

A scheduled review, usually quarterly, pulls active PO lines for a vendor and checks each against the current contract: rate card, volume tier status, rebate accrual, and any surcharge expiration. This finds stale PO pricing and catches drift that has already accumulated, but it is retrospective. Drift between review cycles still posts and gets paid before anyone catches it.

B. Forward control on every invoice

A control layered on top of SyteLine's invoice feed checks each invoice against the contract terms as it arrives, rather than against the PO line alone. This closes the gap a quarterly review leaves open, since nothing waits for the next cycle. Building this well requires the contract terms to be captured as structured data in the first place, which most contracts do not start as: they arrive as PDFs with clauses, not fields.

6. What should you check first before adjusting SyteLine's settings?

Before touching tolerance percentages, pull a sample of PO lines for your highest-spend indirect vendors and compare each reference price against the current signed contract, not against what the PO says. Margin drift across a full diagnostic typically runs 1% to 3% of service vendor spend, across ValueXPA diagnostics, and the source of that gap is consistently PO and rate data that went stale after the contract changed, not a tolerance band set too wide.

This sample check tells you which failure mode you actually have. If PO lines match their contracts closely, your tolerance settings are the right lever and tuning them by category, as above, is enough. If PO lines have drifted from contract terms, no amount of tolerance tuning inside SyteLine fixes that, because the tolerance check was never comparing against the contract to begin with.

The sample also tells you the scale of the problem before you invest in a fix. A handful of stale lines might justify a manual quarterly review. Dozens of vendors with drifted rate cards across freight, contract labor, and MRO justify a structured diagnostic that reconstructs the contract terms as checkable data and quantifies what has already leaked, which is a different exercise than a SyteLine configuration change.

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 SyteLine's tolerance check catch a stale rate card?

No. The tolerance check compares the invoice against the PO line, and a PO line holds whatever price was loaded when it was created. If the contract's rate card changed since then and the PO line was never updated, the tolerance check compares the invoice against a stale reference and lets a mismatched invoice pass clean.

What is the difference between price tolerance and quantity tolerance in SyteLine?

Price tolerance limits how far an invoice's unit price can vary from the PO's unit price before the system holds it. Quantity tolerance does the same for the billed quantity against the received or ordered quantity. They are separate fields and should be set independently, since a vendor's pricing accuracy and its shipping accuracy are unrelated.

Can I set different tolerance bands for different vendors in SyteLine?

Yes. Tolerance can be set at the item master level as a default, then overridden at the vendor level, then overridden again at the individual PO line level. This lets you set a tighter band for a vendor with a history of billing errors and a wider one for a vendor whose invoices legitimately vary, such as a freight carrier billing fuel surcharges.

Why does a tolerance hold in SyteLine get cleared without catching real drift?

A reviewer clearing a hold typically compares the invoice price to the PO price, which is exactly what the tolerance check already did. Unless the reviewer separately pulls the signed contract, the rate card, and any rebate or NTE terms, the hold gets cleared on agreement with a possibly stale PO, not agreement with the contract.

Is three-way matching in SyteLine the same as a contract compliance check?

No. Three-way matching checks the invoice against the purchase order and the goods receipt to confirm quantities and prices line up across those three documents. It has no mechanism for testing a rate card, a volume tier trigger, a rebate clause, or a surcharge expiration date, all of which live in the contract, not in the PO or receipt.

How often should PO line prices be checked against the actual contract?

SyteLine has no built-in schedule for this since it does not store contract terms as structured data. A periodic manual review, run on a set schedule such as quarterly, catches drift that has accumulated since the last check. A forward control that checks every invoice against contract terms as it arrives closes the gap a periodic review leaves open between cycles.

Does widening the tolerance band reduce false holds without missing real drift?

Widening the band reduces false holds by letting more invoices post automatically, but every one of those invoices is still only being compared to the PO line, not the contract. If the PO line itself is stale, a wider band simply lets more drifted invoices through without review, rather than catching them at a wider threshold.

What happens if a rebate clause in the contract is never checked against SyteLine data?

SyteLine's tolerance and matching functions do not track rebate accrual or trigger conditions, so an earned rebate has no automated point of enforcement inside the system. It has to be tracked and claimed through a separate process, whether a manual log or a forward control built specifically to hold rebate terms as checkable data.