Reporting invoice exceptions in Global Shop Solutions

Executive Summary

Global Shop Solutions supports invoice exception reporting through its AP module: PO variance flags, receipt mismatches, and approval holds surface as a standard report or a saved query. That report is reliable for what it checks: quantity, unit price against the PO line, and tolerance thresholds set at the company level.

It does not check a rate card, a volume tier, a rebate clause, or a not-to-exceed cap, because none of those live inside the PO record it is comparing against. The PO carries the price the buyer entered at order time, not the pricing schedule in the underlying service contract. If the two drift apart, Global Shop Solutions has no field to notice.

Building a usable exception report means running two layers: the native PO-variance report inside Global Shop Solutions, and a separate contract-compliance check that reads the same invoice against the actual contract terms. The second layer is manual work, a spreadsheet, or an outside review, unless it is built deliberately.

1. What does Global Shop Solutions flag as an invoice exception natively?

Global Shop Solutions flags an invoice as an exception when the invoiced quantity or unit price falls outside the tolerance set against its matching purchase order line, or when a receipt record is missing. The flag surfaces on an AP hold report or a saved exception query inside the AP module. It is a three-way match: invoice, PO, and receipt.

It says nothing about whether the PO price itself still reflects the contract the vendor agreed to, since that comparison.

The exception report in Global Shop Solutions runs off tolerance fields set at the company or vendor level, a percentage or dollar band around the PO unit price. An invoice inside the band posts without review. One outside it lands on a hold queue an AP clerk works manually.

That queue is useful for the errors it is built to catch: a keying mistake, a quantity overship, a unit price typed wrong at receiving. It clears the noise a busy AP team cannot afford to chase by hand.

What it cannot see is the PO line itself. If a vendor's contract rate changed, and nobody updated the PO template, every invoice will match the PO exactly and never generate an exception. The match succeeds against the wrong number.

2. Why does a PO-matched invoice still contain margin drift?

A PO-matched invoice can still contain margin drift because the PO price is set once, at order creation, while contract terms such as volume-tier discounts, surcharge caps, and rebate triggers change over the life of the agreement. Global Shop Solutions checks the invoice against the PO, not against the contract document. When the two diverge, every invoice can pass the ERP's own match and still overcharge against the signed terms.

A service contract with a freight carrier or a staffing vendor carries pricing logic a PO line cannot hold: a rate that steps down after a volume threshold, a fuel surcharge tied to an index, a not-to-exceed cap on a labor category. None of that logic lives in a static PO price field.

Once the PO is cut, Global Shop Solutions treats that number as the reference point for every future invoice, indefinitely. It has no mechanism to check whether the vendor's own contract terms would produce a different number this month.

This is a structural gap, not a configuration error. The ERP's match logic was built to confirm receipt and quantity, and it does that well. Contract-term enforcement is a separate function that has to sit on top of it.

3. What should a contract-level exception report contain?

A contract-level exception report lists, for each invoice line, the rate the contract specifies, the rate actually billed, and the variance between them, broken out by vendor and category. It differs from the PO-variance report by using the contract document as the reference price, not the PO. Building it requires pulling contract terms into a structured form the invoice can be checked against line by line, rather than relying on whatever price the PO happened to carry.

The report needs four columns beyond what Global Shop Solutions already tracks: the contract clause that sets the price (rate card, tier, surcharge schedule, or cap), the rate that clause implies for this invoice's volume and period, the rate actually billed, and the dollar variance.

Without the contract rate as a column, the report collapses back into a PO-match report, which is the thing it exists to supplement.

A. Rate card lines

Each vendor rate card entry needs its own row: lane, service level, or labor category, with the current contracted rate. The invoice line references back to this row, not to the PO price.

B. Trigger conditions

Volume tiers, rebate thresholds, and surcharge caps are conditional. The report needs the trigger value and whether this period's volume or spend crossed it, not just the flat rate.

4. Can Global Shop Solutions be configured to catch contract terms directly?

Global Shop Solutions can be configured to tighten PO tolerances and require more frequent PO updates, which reduces some drift, but it has no native field for a volume tier, a rebate clause, or a surcharge index. Closing that gap means maintaining the contract rate outside the ERP and checking invoices against it separately, either as a recurring manual review or a system built specifically for contract-to-invoice matching.

Tightening tolerance bands catches more small variances but also increases the manual hold queue, since honest rounding differences start tripping the same flag as real overbilling. That trade-off has a limit before it just adds AP workload without adding accuracy.

Updating the PO price whenever a contract's tiered rate changes is possible, but it depends on someone tracking the tier trigger and editing the PO on time, for every vendor. That is a process control, not a system control, and it fails quietly when it fails.

For a not-to-exceed cap or a rebate clause, there is usually not a comparable PO field at all. Those terms accumulate across a period rather than applying to a single line, which sits outside what a line-level PO match was designed to represent.

5. Which role should own the contract-level exception review?

The contract-level exception review is best owned by whoever already owns vendor contracts: procurement or the AP lead, working from the rate card and the invoice data pulled out of Global Shop Solutions. It should not default to the clerk clearing the ERP's tolerance queue, because that reviewer works from the PO price, not the contract, and would need the underlying agreement in hand to catch the same drift.

Procurement holds the actual contract documents, the rate cards, and the amendment history, which makes it the natural owner of the reference data the review needs. AP holds the invoice history and the export capability out of Global Shop Solutions.

A workable version of this review needs both: procurement supplies the current, correct rate; AP supplies the billed amount. Neither department can run the check alone with the data it already has.

For a company with a handful of service contracts, this can run as a periodic manual reconciliation. Past a few dozen active vendor contracts across freight, labor, and MRO categories, the manual version becomes a scheduling problem before it becomes an accuracy problem.

6. When does a manual exception report stop being enough?

A manual contract-level exception report stops being enough once the number of active service contracts, rate changes, and invoice lines outgrows what one person can hold in a spreadsheet and re-check every cycle. A common trigger is a missed rate change discovered months later, after several invoices have already posted against the stale number. At that point the review needs either a dedicated audit pass or a system built specifically for contract-to-invoice checking.

A spreadsheet reconciliation degrades in a specific, predictable way. Each new vendor contract adds a row to track and a rate to keep current. Each amendment or renewal is a manual edit someone has to remember to make.

The failure mode is not that the spreadsheet stops working. It is that it silently falls behind: a rate updates in the contract but not in the tracker, and every invoice checked against the tracker passes even though it no longer matches the actual agreement.

A retrospective audit of 12 to 18 months of invoice history against the actual contracts, run once, will surface where the tracker and the contracts have already diverged. That is a different exercise from ongoing exception reporting, but it is a fast way to find out how far the drift has already gone before deciding what ongoing control is worth building.

For the wider pattern this sits inside, start with the margin drift guide. See also what is margin erosion? causes and prevention for manufacturers and margin drift vs. legitimate price increases: how to tell them apart.

7. Frequently Asked Questions (People Also Ask)

Does Global Shop Solutions support three-way matching?

Yes. It compares the invoice, the purchase order, and the receipt record, flagging a mismatch on quantity or unit price against tolerance thresholds set at the company or vendor level. This confirms the invoice matches the order, not that the order still matches the contract.

Can I run a contract-compliance report directly inside Global Shop Solutions?

Not natively. The ERP has no field for a volume tier, rebate clause, or surcharge index, so a contract-compliance check has to pull contract terms into a separate structure and compare them against exported invoice data outside the PO-match logic.

What causes a PO price to fall out of sync with the contract?

The PO carries the price entered at order creation. If the underlying contract has a tiered rate, an indexed surcharge, or a rebate trigger that changes over time, and nobody edits the PO to match, the PO keeps referencing the original number indefinitely.

Who should build and maintain the contract rate card used for exception checks?

Procurement, since it holds the contract documents, rate cards, and amendment history. AP supplies the invoice data. The check needs both inputs, so it works best as a joint process rather than sitting entirely inside one department.

Is tightening PO tolerance bands a substitute for a contract-level review?

No. Tighter tolerances catch more small variances but also flag more honest rounding differences, adding to the manual hold queue without adding a rate card, tier, or cap check the PO field was never built to hold.

How do not-to-exceed caps get missed by standard exception reports?

An NTE cap accumulates across a billing period rather than applying to a single invoice line, so a line-level PO match has no field to test against it. Catching a cap overrun requires totaling spend across the period and comparing it to the contract limit separately.

What export capability does Global Shop Solutions offer for building a separate contract check?

AP can export invoice history and PO data out of Global Shop Solutions for use in a spreadsheet or external system. The ERP itself does not build the contract-comparison logic; it only supplies the invoice-side data that logic needs.

How often should a contract-level exception review run?

That depends on how many active vendor contracts a company has and how often their rates change. A small contract portfolio can run a periodic manual check; a larger one with frequent tier changes needs a more frequent, structured review to catch drift before it accumulates.