Does SyteLine check invoices against contracts?

Executive Summary

SyteLine's three-way match confirms that the quantity and price on an invoice agree with the quantity and price on the PO, and that both agree with what was received. That is a real control, and it stops a class of errors: wrong quantities, duplicate receipts, a price entered incorrectly at order time.

What it does not do is reach outside the PO to test the contract the PO was supposed to reflect. Rate cards, volume tier triggers, rebate clauses, NTE caps and surcharge schedules live in PDFs, side letters and vendor portals, not as structured fields SyteLine can query against an invoice line.

A PO can carry a stale unit price, an invoice can match that PO exactly, and three-way matching passes it without incident. The contract violation happened upstream of the control, at PO creation, where SyteLine never looked.

1. What does SyteLine's three-way match actually check?

SyteLine's three-way match compares the purchase order, the goods or service receipt, and the vendor invoice, confirming quantity and unit price agree across all three before payment. It catches an invoice billed for more units than received, a price typed incorrectly at order entry, or a duplicate invoice against the same receipt. It does not compare any of those three documents to the underlying vendor contract, because the contract is not one of the documents in the match.

The match logic sits entirely inside documents SyteLine already owns. The PO is a system record, the receipt is a system record, and the invoice is entered or received as one. All three live in structured fields SyteLine can compare directly.

The contract is different. It is usually a signed PDF or a master service agreement stored outside the ERP, referenced by the PO only through whatever price a buyer typed in when the PO was cut. If that price was wrong on day one, or the contract changed after the PO was cut, the match has nothing to catch it against.

2. Where do the two prices diverge?

The PO price and the contract price diverge at the moment someone keys the PO, not at invoicing. A buyer copies a rate from a prior order, a rate card update never reaches the person cutting POs, or a volume tier crosses its threshold mid-year without the system re-pricing the open PO. SyteLine's match then faithfully enforces whatever number sits on the PO, correct or not, because agreement with the PO is the only test it runs.

Rate cards get renegotiated on their own calendar. A freight contract might reprice lanes quarterly; a staffing agreement might step up hourly rates at a contract anniversary. Unless someone updates every open PO referencing that vendor, the PO keeps the old number.

Volume tiers create the same gap in the other direction. A contract might specify a lower per-unit rate once annual spend crosses a threshold. Nothing in a standard PO workflow recalculates historical invoices, or even flags future ones, once that threshold is crossed.

3. Which contract terms live entirely outside the ERP?

Rebate clauses, not-to-exceed caps, minimum volume commitments and surcharge expiration conditions typically exist only as contract language, not as ERP fields. SyteLine has no native field for an earned but unclaimed rebate, or for a surcharge that was time-limited to 90 days and never removed from a recurring invoice. Testing those terms requires reading the contract text and comparing it to invoice history line by line.

A fuel surcharge is a common example. A carrier contract might allow a surcharge only while diesel prices sit above a stated threshold. SyteLine has no field tracking diesel price, and no logic that would remove the surcharge once the condition lapses.

A. Rebate and rate-tier clauses

A rebate clause promises money back once spend crosses a threshold. SyteLine records the spend, but nothing prompts anyone to invoice the vendor for the rebate or net it against future payments. It stays a contract right, unclaimed, unless someone reads the contract and checks it against year-to-date spend.

B. NTE and minimum commitment clauses

A not-to-exceed clause caps what a vendor may bill for a scope of work; a minimum commitment obligates the buyer to pay for volume whether or not it ships. Both require comparing a running total against a contract ceiling or floor that SyteLine does not store.

4. Can a SyteLine configuration close this gap?

Configuration can tighten SyteLine's existing controls, adding tolerance thresholds, approval routing, or more granular item matching, but it cannot test a clause the system has no field for. Closing the gap requires either keying every relevant contract term into a structured field somewhere, which most contracts do not support cleanly, or running a separate process that reads the contract and checks invoices against it outside the ERP.

Tighter tolerances help with a narrower problem: they stop small price variances from clearing automatically. They do not help with a surcharge that should not exist at all, because the invoice price still matches the PO price exactly.

Some teams try to encode rate cards as SyteLine item costs and refresh them manually. That works for a simple per-unit rate card. It does not work for a tiered rate, a conditional surcharge, or a rebate that nets against a future invoice, because those are conditional logic, not a static price field.

5. Should you buy software or run an audit first?

Buy or build forward-looking software once you can already name which contract clauses are being violated and how often, because a control configured against a guess enforces the guess. Before that, an audit of historical invoices against actual contract language shows which clauses matter for your vendor base, sized in dollars, so any control you build afterward targets a real problem instead of a hypothetical one.

A retrospective audit tests invoices already paid, over a defined look-back period, against the contract terms in force during that period. It answers what already leaked and from which vendors, categories and clause types.

A forward control, whether configured inside SyteLine or added alongside it, tests the next invoice before it pays. Building that control well depends on already knowing which clauses actually get violated in your vendor base, which is exactly what the retrospective step establishes first.

6. What should an AP or controller team do about this today?

Start by pulling the contracts behind your highest-spend service vendors and reading the rate, tier, rebate and surcharge clauses against a sample of recent invoices, independent of what SyteLine's match already approved. Passing three-way match is not evidence the price was correct, only that it matched the PO. A sampled manual check on the largest vendors by spend will surface whether the gap is worth pursuing further.

Pick the ten or twenty vendors carrying the largest share of indirect spend: freight, contract labor, maintenance, IT services, MRO and calibration are the categories where contract terms tend to be most complex and least visible inside the ERP.

For each, pull the current contract and a few months of recent invoices, and check unit prices, surcharges and any tier or rebate language against what was actually billed. A pattern across several vendors in the same category is a signal worth sizing properly rather than sampling further by hand.

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 SyteLine's three-way match catch contract price violations?

No. Three-way match compares the PO, receipt and invoice to each other, not to the vendor contract. If the PO already carries a wrong or stale price, the invoice can match it exactly and still violate the contract.

Can SyteLine store a vendor rate card directly?

SyteLine can store item costs and PO prices, which works for a simple flat rate. It has no native structure for conditional terms like volume tiers, rebate clauses or time-limited surcharges, which require reading the contract text itself.

What kinds of errors does SyteLine's matching actually stop?

It stops quantity mismatches, duplicate invoices against the same receipt, and a price typed differently at invoicing than at order entry. These are data-entry and process errors, not contract compliance errors.

Why would a PO carry the wrong price in the first place?

A buyer may copy a rate from a prior order, a rate card update may not reach whoever cuts POs, or a volume tier may be crossed mid-year without anyone repricing open POs. SyteLine has no mechanism that flags any of these.

Is a fuel surcharge something SyteLine would catch if it should have expired?

No. A surcharge tied to a diesel price threshold or a time limit requires comparing the invoice to a condition outside SyteLine's data model. The system has no field for the trigger, so an expired surcharge can keep billing indefinitely.

Should we configure SyteLine differently or run an audit first?

Run a retrospective audit first. It tells you which contract clauses are actually being violated, in which vendors and categories, so any configuration or forward control you build afterward targets a real, sized problem rather than a guess.

Does upgrading to CloudSuite change this limitation?

The cloud deployment changes hosting and update cadence, not the underlying match logic. Three-way matching in CloudSuite SyteLine still compares PO, receipt and invoice to each other, with the same blind spot on contract terms.

What is the fastest way to check if this is costing us money?

Pull the current contracts for your ten to twenty highest-spend service vendors and compare recent invoices against the rate, tier and surcharge language directly, independent of what SyteLine already approved. A pattern across several vendors is worth sizing formally.