# What invoice controls does Global Shop Solutions not have?

> Global Shop Solutions checks the PO and the receipt. It does not read a rate card, a rebate clause, or an NTE cap. Here is what that gap leaves open.

Source: https://valuexpa.com/insights/what-invoice-controls-does-global-shop-solutions-not-have
Publisher: ValueXPA (https://valuexpa.com)
Updated: 2026-10-22

---

Margin drift is the gap between what a vendor contract says and what the invoice actually charges. Global Shop Solutions was built to run a machine shop floor: work orders, routings, inventory, job costing. Its AP module keeps that shop floor's books. It was not built to interpret a freight tariff, a staffing rate card, or a rebate clause.

That distinction matters more than it looks. A manufacturer running Global Shop Solutions can still get duplicate payments caught and three-way matches enforced. What it cannot get from the ERP itself is anyone checking the invoice against the contract terms that sit outside it, in a PDF or a spreadsheet nobody loaded in.

## Executive Summary

Global Shop Solutions enforces the controls a shop-floor ERP is built for: purchase order existence, quantity received, and unit price against the PO line. Those checks stop a vendor from billing for units that were never ordered or never received. They do not stop a vendor from billing the wrong rate on units that were both ordered and received.

The mechanism behind that gap is structural, not a bug to be patched. A rate card, a volume tier, a rebate clause, a not-to-exceed cap, and a surcharge expiration date are all contract terms. They live in a document the ERP never ingests. Three-way matching was never designed to read that document, so it does not test against it, no matter how well the ERP is configured.

What changes this is either a control layer that reads the contract and checks each invoice line against it going forward, or a retrospective review of paid invoices against those same contract terms to find what already slipped through. Manufacturers on Global Shop Solutions typically need both answers: a quantified picture of what has already leaked, and a decision on what ongoing check closes the gap for the next invoice.

## 1. What does Global Shop Solutions actually check on an incoming invoice?

**Global Shop Solutions runs three-way matching: it confirms a purchase order exists, confirms the receipt logged against it, and confirms the invoice's unit price matches the price recorded on that PO line. That is a control against phantom charges and quantity errors. It is not a control against a rate that was correct when the PO was cut but wrong under the current contract, because the PO price field and the contract's rate card are two different records that the.**

The match runs at the line level, tying invoice quantity to receipt quantity and invoice price to PO price. If a vendor bills for 500 units and only 400 were received, the mismatch holds the invoice for review. If the unit price on the invoice differs from the unit price on the PO, that too triggers a hold.

Both checks assume the PO price is correct. Neither checks whether the PO price itself reflects the current contract. If a rate card was renegotiated and the PO template was never updated, matching passes every invoice at the old, wrong rate, because the invoice agrees with the PO and the PO is what the system trusts.

This is the boundary of what three-way matching does anywhere, not a Global Shop Solutions shortcoming specifically. The control was designed to prevent billing for goods not ordered or not received. Extending it to test a rate card, a tier, or a rebate clause is a separate function the module does not perform.

## 2. Why doesn't matching catch a rate card change?

**Matching compares the invoice to the purchase order, and the purchase order to nothing else. A rate card lives in a contract document, not in a PO field, so a renegotiated rate never propagates into the match unless someone manually edits every affected PO. Until that edit happens, the invoice, the PO, and the match all agree with each other while all three disagree with the actual contract in force.**

A rate card sets price by category, region, or service level, and it usually changes on a schedule the AP team does not track line by line. When a carrier or staffing vendor updates rates, the change arrives as a letter or an amendment, not as a system feed.

Someone has to translate that document into an updated PO price or a new item record. Until they do, every invoice referencing the old PO price clears the match cleanly. The invoice is internally consistent with the PO. It is just consistent with the wrong number.

The fix is not a matching rule; it is a step upstream of matching that checks the invoice against the current rate card directly, independent of whatever price sits on the PO.

## 3. Can Global Shop Solutions catch a not-to-exceed overrun?

**Not directly. A not-to-exceed cap is a ceiling on total billing across a project or period, and the ERP has no field that tracks cumulative spend against that ceiling across multiple invoices tied to the same engagement. Each invoice matches its own PO line correctly. Nothing in the system sums the series and flags the point where the running total crosses the cap the contract sets.**

NTE caps are common on IT projects, professional services engagements, and contract labor assignments where the vendor bills incrementally against a total ceiling. The cap is a contract term about the sum of many invoices, not a limit on any single one.

Three-way matching evaluates each invoice against its own PO line in isolation. It has no mechanism for tracking a running total across a project and comparing that total to a cap defined in a separate contract document.

A vendor can bill correctly against each individual PO release and still overrun the project ceiling, because no invoice in the series is wrong by itself. Catching this requires tracking cumulative billing against the cap outside the invoice-by-invoice match, which is a different kind of check than the ERP runs.

## 4. What about rebates and volume tiers?

**Rebate clauses and volume tiers reward spend the buyer has already committed by contract, and claiming them requires someone to track cumulative purchases against the tier threshold and file for the rebate before it expires. Global Shop Solutions records the purchases. It does not track them against a tier schedule, and it does not generate a claim when a threshold is crossed, so an earned rebate goes unclaimed unless a person is watching for it.**

A volume tier drops the unit rate once cumulative purchases cross a threshold, often measured quarterly or annually. A rebate clause pays money back on top of that once the threshold is met, frequently on a claim deadline the buyer has to hit.

Both are cumulative, contract-level terms, structurally similar to a not-to-exceed cap but running in the opposite direction: the buyer is owed money instead of capped on spend.

The ERP has no tier table tied to the contract and no trigger that fires when a threshold is crossed. Someone in AP or procurement has to track the running total by hand, know the deadline, and file the claim. Miss any one of those steps and the rebate lapses unclaimed, with no error, hold, or exception raised anywhere in the system.

## 5. Does a surcharge get checked against its own expiration date?

**No. A fuel surcharge, a temporary accessorial, or a peak-season fee is added to a PO or an item record as a flat adjustment, and matching checks that the invoice reflects that adjustment correctly. It does not check whether the surcharge's own expiration condition, a date or an index threshold, has already passed. The surcharge keeps billing after its trigger has lapsed because nothing in the match tests the trigger itself.**

Carriers and service vendors often apply a surcharge tied to a condition: a fuel index above a level, a labor shortage period, a named peak season. The condition has a start and, usually, an end.

Once that surcharge is set up as a line item or a percentage adjustment on a PO, matching treats it like any other price component. It checks that the invoice charges the amount configured, not whether the configured amount should still apply.

If the index drops back below the trigger level or the peak season ends, the surcharge keeps billing until someone notices and removes it manually. The invoice matches the PO the whole time it is wrong, because the PO was never updated to reflect the surcharge's own expiration.

## 6. What has to happen outside the ERP to close these gaps?

**Two separate things, and they answer different questions. A retrospective review reads 12 to 18 months of paid invoices against the actual contract terms to find what has already leaked, and it produces a dollar figure. A forward control reads each new invoice against the same contract terms before or as it posts, and it prevents the next instance of the same drift type from recurring.**

Both approaches need the same starting input: the contract terms themselves, pulled out of PDFs and spreadsheets and turned into something checkable line by line. Neither the retrospective review nor the forward control can run without that translation step done first.

A manufacturer deciding between the two is really deciding what they need first. Margin drift across a full diagnostic typically runs 1% to 3% of service vendor spend, a figure that only a review of historical invoices against contract terms can establish for a given company. A forward control cannot tell you what has already leaked; it can only stop the next occurrence once the rules exist to check against.

Two approaches to the same gap, answering different questions.

| Approach
| Question it answers
| What it needs

| Retrospective review
| How much has already leaked, and where
| 12 to 18 months of paid invoices plus the underlying contracts

| Forward control
| Will the next invoice be checked before it posts
| Contract terms translated into rules a system can apply invoice by invoice

| Neither
| Nothing answered
| Matching alone, unchanged

For the wider pattern this sits inside, start with the [margin drift](/insights/best-invoice-validation-software-smb) guide. See also [the six categories drift hides in](/insights/indirect-spend-audit-categories) and [what is margin erosion? causes and prevention for manufacturers](/insights/what-is-margin-erosion-causes-and-prevention-for).

## 7. Frequently Asked Questions (People Also Ask)

### Does Global Shop Solutions do three-way matching?

Yes. It matches the invoice against the purchase order and the receipt, confirming quantity received and unit price against the PO line. That stops billing for goods never ordered or never received. It does not check the PO price against the current contract rate.

### Can Global Shop Solutions catch a duplicate invoice?

Duplicate detection depends on how the invoice number and vendor are keyed in the AP module and how consistently vendors format their invoice numbers. It catches exact duplicates reliably. It is less reliable against a resubmitted invoice with a slightly altered number or date, which still requires a manual check.

### Why doesn't updating the PO price fix this permanently?

Updating the PO price fixes that one PO. A rate card can cover hundreds of items or lanes, each needing its own PO update whenever the contract changes. Without a process that triggers on every contract amendment, PO prices drift out of sync with the contract again over time.

### Is this a problem specific to Global Shop Solutions?

No. Three-way matching works the same way in most ERPs built around a purchase order and receipt: it checks the invoice against the PO, not against the contract behind the PO. The gap described here applies broadly, not to this ERP alone.

### What contract terms most commonly cause this kind of drift?

Rate cards, volume tiers, rebate clauses, not-to-exceed caps, and surcharge expiration conditions are the recurring categories. Each is a term that lives in the contract document rather than in a PO field, which is why matching does not test against it.

### Should a manufacturer add a module to Global Shop Solutions to fix this?

That depends on whether the contract terms have already been translated into checkable rules. Adding a module before that translation is done enforces whatever rules were guessed, not the actual contract, so the translation step has to come first regardless of the tooling decision.

### How far back should a review of paid invoices go?

Leakage already embedded in 12 to 18 months of historical spend is the typical window a retrospective review covers, since that range usually spans enough billing cycles to surface rate, tier, and surcharge drift without going so far back that contracts have changed entirely.

### Does this affect freight invoices differently than professional services invoices?

The mechanism is the same across categories, though the contract term differs: freight commonly carries fuel surcharges and accessorial schedules, while professional services and contract labor commonly carry not-to-exceed caps and rate cards. Both fail the same way, against a PO that never reflects the underlying document.

### Is this general information or legal advice?

This is general information about how invoice matching works in Global Shop Solutions. It is not legal advice on any specific contract, and a contract dispute should be reviewed by qualified counsel.

### Is contract complexity quietly draining your operating margin?

A small systematic drift between your negotiated contracts and your actual vendor billing compounds quietly across a year of invoices. Stop guessing at your exposure and run a targeted audit.

**[Take the Free Screener → https://valuexpa.com/margin-drift-screener](https://valuexpa.com/margin-drift-screener)**

## Executive Summary

Global Shop Solutions enforces the controls a shop-floor ERP is built for: purchase order existence, quantity received, and unit price against the PO line. Those checks stop a vendor from billing for units that were never ordered or never received. They do not stop a vendor from billing the wrong rate on units that were both ordered and received. The mechanism behind that gap is structural, not a bug to be patched. A rate card, a volume tier, a rebate clause, a not-to-exceed cap, and a surcharge expiration date are all contract terms. They live in a document the ERP never ingests. Three-way matching was never designed to read that document, so it does not test against it, no matter how well the ERP is configured. What changes this is either a control layer that reads the contract and checks each invoice line against it going forward, or a retrospective review of paid invoices against those same contract terms to find what already slipped through. Manufacturers on Global Shop Solutions typically need both answers: a quantified picture of what has already leaked, and a decision on what ongoing check closes the gap for the next invoice.

## 1. What does Global Shop Solutions actually check on an incoming invoice?

Global Shop Solutions runs three-way matching: it confirms a purchase order exists, confirms the receipt logged against it, and confirms the invoice's unit price matches the price recorded on that PO line. That is a control against phantom charges and quantity errors. It is not a control against a rate that was correct when the PO was cut but wrong under the current contract, because the PO price field and the contract's rate card are two different records that the. The match runs at the line level, tying invoice quantity to receipt quantity and invoice price to PO price. If a vendor bills for 500 units and only 400 were received, the mismatch holds the invoice for review. If the unit price on the invoice differs from the unit price on the PO, that too triggers a hold. Both checks assume the PO price is correct. Neither checks whether the PO price itself reflects the current contract. If a rate card was renegotiated and the PO template was never updated, matching passes every invoice at the old, wrong rate, because the invoice agrees with the PO and the PO is what the system trusts. This is the boundary of what three-way matching does anywhere, not a Global Shop Solutions shortcoming specifically. The control was designed to prevent billing for goods not ordered or not received. Extending it to test a rate card, a tier, or a rebate clause is a separate function the module does not perform.

## 2. Why doesn't matching catch a rate card change?

Matching compares the invoice to the purchase order, and the purchase order to nothing else. A rate card lives in a contract document, not in a PO field, so a renegotiated rate never propagates into the match unless someone manually edits every affected PO. Until that edit happens, the invoice, the PO, and the match all agree with each other while all three disagree with the actual contract in force. A rate card sets price by category, region, or service level, and it usually changes on a schedule the AP team does not track line by line. When a carrier or staffing vendor updates rates, the change arrives as a letter or an amendment, not as a system feed. Someone has to translate that document into an updated PO price or a new item record. Until they do, every invoice referencing the old PO price clears the match cleanly. The invoice is internally consistent with the PO. It is just consistent with the wrong number. The fix is not a matching rule; it is a step upstream of matching that checks the invoice against the current rate card directly, independent of whatever price sits on the PO.

## 3. Can Global Shop Solutions catch a not-to-exceed overrun?

Not directly. A not-to-exceed cap is a ceiling on total billing across a project or period, and the ERP has no field that tracks cumulative spend against that ceiling across multiple invoices tied to the same engagement. Each invoice matches its own PO line correctly. Nothing in the system sums the series and flags the point where the running total crosses the cap the contract sets. NTE caps are common on IT projects, professional services engagements, and contract labor assignments where the vendor bills incrementally against a total ceiling. The cap is a contract term about the sum of many invoices, not a limit on any single one. Three-way matching evaluates each invoice against its own PO line in isolation. It has no mechanism for tracking a running total across a project and comparing that total to a cap defined in a separate contract document. A vendor can bill correctly against each individual PO release and still overrun the project ceiling, because no invoice in the series is wrong by itself. Catching this requires tracking cumulative billing against the cap outside the invoice-by-invoice match, which is a different kind of check than the ERP runs.

## 4. What about rebates and volume tiers?

Rebate clauses and volume tiers reward spend the buyer has already committed by contract, and claiming them requires someone to track cumulative purchases against the tier threshold and file for the rebate before it expires. Global Shop Solutions records the purchases. It does not track them against a tier schedule, and it does not generate a claim when a threshold is crossed, so an earned rebate goes unclaimed unless a person is watching for it. A volume tier drops the unit rate once cumulative purchases cross a threshold, often measured quarterly or annually. A rebate clause pays money back on top of that once the threshold is met, frequently on a claim deadline the buyer has to hit. Both are cumulative, contract-level terms, structurally similar to a not-to-exceed cap but running in the opposite direction: the buyer is owed money instead of capped on spend. The ERP has no tier table tied to the contract and no trigger that fires when a threshold is crossed. Someone in AP or procurement has to track the running total by hand, know the deadline, and file the claim. Miss any one of those steps and the rebate lapses unclaimed, with no error, hold, or exception raised anywhere in the system.

## 5. Does a surcharge get checked against its own expiration date?

No. A fuel surcharge, a temporary accessorial, or a peak-season fee is added to a PO or an item record as a flat adjustment, and matching checks that the invoice reflects that adjustment correctly. It does not check whether the surcharge's own expiration condition, a date or an index threshold, has already passed. The surcharge keeps billing after its trigger has lapsed because nothing in the match tests the trigger itself. Carriers and service vendors often apply a surcharge tied to a condition: a fuel index above a level, a labor shortage period, a named peak season. The condition has a start and, usually, an end. Once that surcharge is set up as a line item or a percentage adjustment on a PO, matching treats it like any other price component. It checks that the invoice charges the amount configured, not whether the configured amount should still apply. If the index drops back below the trigger level or the peak season ends, the surcharge keeps billing until someone notices and removes it manually. The invoice matches the PO the whole time it is wrong, because the PO was never updated to reflect the surcharge's own expiration.

## 6. What has to happen outside the ERP to close these gaps?

Two separate things, and they answer different questions. A retrospective review reads 12 to 18 months of paid invoices against the actual contract terms to find what has already leaked, and it produces a dollar figure. A forward control reads each new invoice against the same contract terms before or as it posts, and it prevents the next instance of the same drift type from recurring. Both approaches need the same starting input: the contract terms themselves, pulled out of PDFs and spreadsheets and turned into something checkable line by line. Neither the retrospective review nor the forward control can run without that translation step done first. A manufacturer deciding between the two is really deciding what they need first. Margin drift across a full diagnostic typically runs 1% to 3% of service vendor spend, a figure that only a review of historical invoices against contract terms can establish for a given company. A forward control cannot tell you what has already leaked; it can only stop the next occurrence once the rules exist to check against. Two approaches to the same gap, answering different questions. | Approach | Question it answers | What it needs | | --- | --- | --- | | Retrospective review | How much has already leaked, and where | 12 to 18 months of paid invoices plus the underlying contracts | | Forward control | Will the next invoice be checked before it posts | Contract terms translated into rules a system can apply invoice by invoice | | Neither | Nothing answered | Matching alone, unchanged | For the wider pattern this sits inside, start with the [margin drift](/insights/best-invoice-validation-software-smb) guide. See also [the six categories drift hides in](/insights/indirect-spend-audit-categories) and [what is margin erosion? causes and prevention for manufacturers](/insights/what-is-margin-erosion-causes-and-prevention-for).

## Common questions

### Does Global Shop Solutions do three-way matching?

Yes. It matches the invoice against the purchase order and the receipt, confirming quantity received and unit price against the PO line. That stops billing for goods never ordered or never received. It does not check the PO price against the current contract rate.

### Can Global Shop Solutions catch a duplicate invoice?

Duplicate detection depends on how the invoice number and vendor are keyed in the AP module and how consistently vendors format their invoice numbers. It catches exact duplicates reliably. It is less reliable against a resubmitted invoice with a slightly altered number or date, which still requires a manual check.

### Why doesn't updating the PO price fix this permanently?

Updating the PO price fixes that one PO. A rate card can cover hundreds of items or lanes, each needing its own PO update whenever the contract changes. Without a process that triggers on every contract amendment, PO prices drift out of sync with the contract again over time.

### Is this a problem specific to Global Shop Solutions?

No. Three-way matching works the same way in most ERPs built around a purchase order and receipt: it checks the invoice against the PO, not against the contract behind the PO. The gap described here applies broadly, not to this ERP alone.

### What contract terms most commonly cause this kind of drift?

Rate cards, volume tiers, rebate clauses, not-to-exceed caps, and surcharge expiration conditions are the recurring categories. Each is a term that lives in the contract document rather than in a PO field, which is why matching does not test against it.

---

ValueXPA runs a fixed-scope Margin Drift Diagnostic that validates every service vendor invoice against contract terms, for $100M+ US industrial manufacturers and distributors. Two to four weeks. The client retains 100% of recoveries. https://valuexpa.com/contact-us