# What invoice controls does Plex not have? > Plex Manufacturing Cloud checks the PO and the shop floor transaction. It has no field for a rate card, a volume tier, or a surcharge expiration date. Source: https://valuexpa.com/insights/what-invoice-controls-does-plex-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. Plex Manufacturing Cloud was built to run a plant floor: work orders, routings, quality holds, MRP. Invoice matching sits downstream of that, tied to the purchase order and the receipt. That design is a strength for production and a limit for services buying. A PO line has a quantity and a unit price. A freight surcharge schedule, a labor rate card with tiered NTE caps, a rebate clause tied to annual volume: none of those have a native home in the PO record Plex matches against. ## Executive Summary Plex enforces three-way matching: purchase order, receipt, invoice. That control catches a quantity mismatch or a price that deviates from the PO line. It does not catch a contract term that never made it onto the PO in the first place, which is most of what governs service vendor spend. The mechanism is the issue, not the vendor. Freight accessorials, staffing rate escalations, maintenance NTE caps, and rebate triggers live in separate contract documents, often PDFs, that nobody keys into a PO line item. Plex has no field built to hold a rate card, a volume tier, or a surcharge expiration condition, so it cannot test an invoice against a term it never stored. The fix is not a Plex configuration change. It is a separate pass that reads the contract, builds the rule the PO field never captured, and checks invoices against it. That pass can run as a one-time diagnostic against 12 to 18 months of paid invoices, or continuously going forward. Either way, the gap exists on the current release and should be planned around, not assumed away. ## 1. Does Plex check invoices against a rate card? **No. Plex matches an invoice price against the price recorded on the purchase order line, not against a separate rate card document. If the PO was cut at the correct contract rate, the match holds. If the vendor's rate card changed, or the PO carried a stale price, Plex has no independent rate card record to compare the invoice against, so a rate that drifted from contract terms passes the match cleanly.** A rate card is a standalone document: a table of prices by service level, region, or tier, usually issued once a year and referenced in the master agreement rather than typed into every PO. Plex has no object designed to store that table or to attach it to a vendor as a standing reference. This means the control depends entirely on the PO being right at the moment it was created. A buyer who cut the PO before a rate increase took effect, or before a tier change, has no downstream check that catches the mismatch later. The invoice matches the PO. The PO no longer matches the contract. For categories bought against a published rate schedule, freight is the clearest example, this is a structural gap rather than a configuration option. Closing it means keeping the rate card outside Plex and checking invoices against it separately. ## 2. Can Plex track a volume tier or rebate threshold? **Plex has no native mechanism that accumulates spend against a vendor across a contract year and tests it against a tier threshold or triggers a rebate calculation. Its purchasing and inventory modules track quantity and cost at the transaction level, order by order, not as a running total measured against a contractual volume commitment that determines a rebate or a lower rate once crossed.** Volume tiers and rebate clauses are forward-looking by design: cross a threshold and the rate changes, or a rebate accrues, for spend going forward or retroactively for the period. Testing for that requires a running total compared against a contract-defined trigger, evaluated on a cadence the ERP was not built to track. Plex records each purchase as its own transaction. Nothing in the standard workflow sums a vendor's trailing spend and flags a threshold crossing, and nothing recalculates the rate once a tier is reached. A vendor could cross a committed volume mid-year and continue billing at the lower tier's old rate indefinitely, with no exception raised anywhere in Plex. The rebate side has the same shape. An earned rebate has to be tracked against the clause that created it and reconciled against what actually posted as a credit. Plex has no field for the clause and no process that reconciles against it. ## 3. Does Plex catch a surcharge that should have expired? **No. A fuel surcharge, a temporary staffing premium, or an expedite fee usually carries a start condition and an end condition written into the contract or a rider. Plex's invoice matching tests the invoice against the PO and the receipt; it has no field for a surcharge's expiration date or the condition that triggers its removal, so a surcharge that should have dropped off continues to pass the match.** A surcharge is added for a reason: a fuel index crossing a level, a rush order, a temporary labor shortage. The contract states when it applies and, just as often, the condition under which it stops. Neither condition is a field Plex's PO or invoice screens carry. Once a surcharge line is established on a recurring PO or a standing vendor relationship, it tends to keep billing at the same rate structure until someone manually notices and removes it. Plex's three-way match tests quantity and price against the PO, not against a calendar date or an index value external to the transaction. Catching this requires reading the contract's trigger condition and checking each invoice against it directly, a step that happens outside the ERP entirely. ## 4. What does Plex's three-way match actually verify? **Plex's three-way match compares the purchase order, the goods receipt or service confirmation, and the invoice for agreement on quantity and unit price. It confirms that what was ordered, what was received, and what was billed line up with each other. It does not evaluate whether the price on the PO itself reflects the current contract, because the contract is not a document Plex references during the match.** This is the control doing exactly what it was designed to do. For a manufacturer buying raw materials and components against negotiated purchase prices, matching PO to receipt to invoice closes the loop that matters most: did we get what we ordered, at the price we agreed to on that order. ### A. What the match confirms Quantity ordered equals quantity received equals quantity invoiced, within tolerance. Unit price on the invoice equals unit price on the PO. A variance outside tolerance triggers a hold for review before payment releases. ### B. What the match does not touch Whether the PO price itself is still the contract price. Whether a rate card, tier, or rebate clause outside the PO changed the correct price. Whether a surcharge's trigger condition still applies. Those questions require a document the match never opens: the contract. ## 5. Which service categories are most exposed to this gap in Plex? **The categories most exposed are the ones priced by a document Plex never stores: a rate card, a labor agreement, a maintenance contract with an NTE cap. Freight and 3PL, contract labor and staffing, and maintenance and repair all typically carry pricing logic that lives in a contract PDF rather than a PO field, which is exactly the condition under which Plex's three-way match has nothing to test against.** None of these categories are unusual for a manufacturer to buy. They are simply priced by documents that sit a layer above the transaction Plex was designed to control. - **Freight and 3PL:** Rate schedules, fuel surcharge tables, and accessorial fee lists sit outside the PO and change on a cadence the PO does not track. - **Contract labor and staffing:** Bill rates, overtime rules, and NTE caps by role are set in a staffing agreement, not typed into a recurring PO line. - **Maintenance and repair:** Service contracts often carry a not-to-exceed cap per visit or per year that the PO match never checks against. - **IT and professional services:** Statement-of-work terms, including milestone-based pricing and rate escalators, live outside the PO Plex reconciles against. ## 6. How do you close the gap without waiting on a Plex release? **You close it by treating contract terms as a separate dataset from the PO, read once from the contract documents and checked against invoices independent of Plex's own match logic. That can be a one-time review of 12 to 18 months of paid invoices to find what already slipped through, a forward-looking control to catch it going forward, or both. Waiting for a Plex feature to appear is not a plan; the gap is structural, not a missing checkbox.** The practical starting point is the invoice history already sitting in Plex, exported and checked against the rate cards, labor agreements, and service contracts that actually govern those vendors. That review does not require touching Plex configuration at all; it runs alongside the existing system. A build-it-yourself version of this in a spreadsheet is possible for a single vendor and a short time window. It gets harder fast once rate cards update, contracts renew, and the number of vendor categories grows past what one person can track by hand. Whichever path is chosen, the work is the same: read the contract, extract the term the PO never captured, and test invoices against it directly rather than against Plex's own match. 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 upgrading Plex or adding a module fix this? No. The gap is in what the PO and invoice match tests, not in a missing report or dashboard. No standard Plex module stores a rate card, a volume tier, or a surcharge expiration condition as a field the match references, so an upgrade path within Plex does not close it. ### Is this specific to Plex, or true of other manufacturing ERPs? The same PO-and-receipt match logic is common across manufacturing ERPs built around production, not services procurement. The details of what each system stores differ, but the structural gap between a PO field and a contract clause is not unique to Plex. ### Can a Plex customization add rate card fields? A custom field can hold a number, but the match logic still has to be built to reference it, update it on schedule, and flag a mismatch. That is a build project with ongoing maintenance, not a configuration toggle, and it duplicates work a dedicated audit does without touching the ERP. ### How far back can a review of Plex invoice history go? A typical diagnostic reviews 12 to 18 months of historical spend, across ValueXPA diagnostics, since that window usually covers enough billing cycles to surface a recurring rate or surcharge issue without requiring data past normal retention. ### Does this mean Plex is a bad ERP for a manufacturer? No. Plex is built for production control, and three-way matching against a PO is the right check for materials and components. The gap only shows up in service vendor categories priced by contract terms the PO was never designed to hold. ### What size of company should worry about this gap? It matters most for manufacturers above $50M in revenue, where service vendor spend across freight, labor, maintenance and IT categories is large enough that a rate or surcharge drift compounds meaningfully over a contract year. ### Should we fix this ourselves or bring in outside help? Either is possible. A spreadsheet-based check works for a small number of vendors and a short window; it gets difficult to maintain once contracts renew and categories multiply. The tradeoff is covered in the build-vs-buy comparison for this exact decision. ### Does three-way matching in Plex prevent duplicate payments? Three-way matching primarily checks quantity and price agreement across the PO, receipt, and invoice. Duplicate payment detection is a related but separate check, and its effectiveness depends on how invoice numbering and vendor master data are maintained, not solely on the match itself. ### What is the first step if we suspect this gap has already cost us money? Start with the invoice history already in Plex. A review that checks paid invoices against actual contract terms, rate cards, and surcharge conditions will show whether drift already occurred, independent of any change to the ERP itself. ### 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 Plex enforces three-way matching: purchase order, receipt, invoice. That control catches a quantity mismatch or a price that deviates from the PO line. It does not catch a contract term that never made it onto the PO in the first place, which is most of what governs service vendor spend. The mechanism is the issue, not the vendor. Freight accessorials, staffing rate escalations, maintenance NTE caps, and rebate triggers live in separate contract documents, often PDFs, that nobody keys into a PO line item. Plex has no field built to hold a rate card, a volume tier, or a surcharge expiration condition, so it cannot test an invoice against a term it never stored. The fix is not a Plex configuration change. It is a separate pass that reads the contract, builds the rule the PO field never captured, and checks invoices against it. That pass can run as a one-time diagnostic against 12 to 18 months of paid invoices, or continuously going forward. Either way, the gap exists on the current release and should be planned around, not assumed away. ## 1. Does Plex check invoices against a rate card? No. Plex matches an invoice price against the price recorded on the purchase order line, not against a separate rate card document. If the PO was cut at the correct contract rate, the match holds. If the vendor's rate card changed, or the PO carried a stale price, Plex has no independent rate card record to compare the invoice against, so a rate that drifted from contract terms passes the match cleanly. A rate card is a standalone document: a table of prices by service level, region, or tier, usually issued once a year and referenced in the master agreement rather than typed into every PO. Plex has no object designed to store that table or to attach it to a vendor as a standing reference. This means the control depends entirely on the PO being right at the moment it was created. A buyer who cut the PO before a rate increase took effect, or before a tier change, has no downstream check that catches the mismatch later. The invoice matches the PO. The PO no longer matches the contract. For categories bought against a published rate schedule, freight is the clearest example, this is a structural gap rather than a configuration option. Closing it means keeping the rate card outside Plex and checking invoices against it separately. ## 2. Can Plex track a volume tier or rebate threshold? Plex has no native mechanism that accumulates spend against a vendor across a contract year and tests it against a tier threshold or triggers a rebate calculation. Its purchasing and inventory modules track quantity and cost at the transaction level, order by order, not as a running total measured against a contractual volume commitment that determines a rebate or a lower rate once crossed. Volume tiers and rebate clauses are forward-looking by design: cross a threshold and the rate changes, or a rebate accrues, for spend going forward or retroactively for the period. Testing for that requires a running total compared against a contract-defined trigger, evaluated on a cadence the ERP was not built to track. Plex records each purchase as its own transaction. Nothing in the standard workflow sums a vendor's trailing spend and flags a threshold crossing, and nothing recalculates the rate once a tier is reached. A vendor could cross a committed volume mid-year and continue billing at the lower tier's old rate indefinitely, with no exception raised anywhere in Plex. The rebate side has the same shape. An earned rebate has to be tracked against the clause that created it and reconciled against what actually posted as a credit. Plex has no field for the clause and no process that reconciles against it. ## 3. Does Plex catch a surcharge that should have expired? No. A fuel surcharge, a temporary staffing premium, or an expedite fee usually carries a start condition and an end condition written into the contract or a rider. Plex's invoice matching tests the invoice against the PO and the receipt; it has no field for a surcharge's expiration date or the condition that triggers its removal, so a surcharge that should have dropped off continues to pass the match. A surcharge is added for a reason: a fuel index crossing a level, a rush order, a temporary labor shortage. The contract states when it applies and, just as often, the condition under which it stops. Neither condition is a field Plex's PO or invoice screens carry. Once a surcharge line is established on a recurring PO or a standing vendor relationship, it tends to keep billing at the same rate structure until someone manually notices and removes it. Plex's three-way match tests quantity and price against the PO, not against a calendar date or an index value external to the transaction. Catching this requires reading the contract's trigger condition and checking each invoice against it directly, a step that happens outside the ERP entirely. ## 4. What does Plex's three-way match actually verify? Plex's three-way match compares the purchase order, the goods receipt or service confirmation, and the invoice for agreement on quantity and unit price. It confirms that what was ordered, what was received, and what was billed line up with each other. It does not evaluate whether the price on the PO itself reflects the current contract, because the contract is not a document Plex references during the match. This is the control doing exactly what it was designed to do. For a manufacturer buying raw materials and components against negotiated purchase prices, matching PO to receipt to invoice closes the loop that matters most: did we get what we ordered, at the price we agreed to on that order. ### A. What the match confirms Quantity ordered equals quantity received equals quantity invoiced, within tolerance. Unit price on the invoice equals unit price on the PO. A variance outside tolerance triggers a hold for review before payment releases. ### B. What the match does not touch Whether the PO price itself is still the contract price. Whether a rate card, tier, or rebate clause outside the PO changed the correct price. Whether a surcharge's trigger condition still applies. Those questions require a document the match never opens: the contract. ## 5. Which service categories are most exposed to this gap in Plex? The categories most exposed are the ones priced by a document Plex never stores: a rate card, a labor agreement, a maintenance contract with an NTE cap. Freight and 3PL, contract labor and staffing, and maintenance and repair all typically carry pricing logic that lives in a contract PDF rather than a PO field, which is exactly the condition under which Plex's three-way match has nothing to test against. None of these categories are unusual for a manufacturer to buy. They are simply priced by documents that sit a layer above the transaction Plex was designed to control. - Freight and 3PL: Rate schedules, fuel surcharge tables, and accessorial fee lists sit outside the PO and change on a cadence the PO does not track. - Contract labor and staffing: Bill rates, overtime rules, and NTE caps by role are set in a staffing agreement, not typed into a recurring PO line. - Maintenance and repair: Service contracts often carry a not-to-exceed cap per visit or per year that the PO match never checks against. - IT and professional services: Statement-of-work terms, including milestone-based pricing and rate escalators, live outside the PO Plex reconciles against. ## 6. How do you close the gap without waiting on a Plex release? You close it by treating contract terms as a separate dataset from the PO, read once from the contract documents and checked against invoices independent of Plex's own match logic. That can be a one-time review of 12 to 18 months of paid invoices to find what already slipped through, a forward-looking control to catch it going forward, or both. Waiting for a Plex feature to appear is not a plan; the gap is structural, not a missing checkbox. The practical starting point is the invoice history already sitting in Plex, exported and checked against the rate cards, labor agreements, and service contracts that actually govern those vendors. That review does not require touching Plex configuration at all; it runs alongside the existing system. A build-it-yourself version of this in a spreadsheet is possible for a single vendor and a short time window. It gets harder fast once rate cards update, contracts renew, and the number of vendor categories grows past what one person can track by hand. Whichever path is chosen, the work is the same: read the contract, extract the term the PO never captured, and test invoices against it directly rather than against Plex's own match. 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 upgrading Plex or adding a module fix this? No. The gap is in what the PO and invoice match tests, not in a missing report or dashboard. No standard Plex module stores a rate card, a volume tier, or a surcharge expiration condition as a field the match references, so an upgrade path within Plex does not close it. ### Is this specific to Plex, or true of other manufacturing ERPs? The same PO-and-receipt match logic is common across manufacturing ERPs built around production, not services procurement. The details of what each system stores differ, but the structural gap between a PO field and a contract clause is not unique to Plex. ### Can a Plex customization add rate card fields? A custom field can hold a number, but the match logic still has to be built to reference it, update it on schedule, and flag a mismatch. That is a build project with ongoing maintenance, not a configuration toggle, and it duplicates work a dedicated audit does without touching the ERP. ### How far back can a review of Plex invoice history go? A typical diagnostic reviews 12 to 18 months of historical spend, across ValueXPA diagnostics, since that window usually covers enough billing cycles to surface a recurring rate or surcharge issue without requiring data past normal retention. ### Does this mean Plex is a bad ERP for a manufacturer? No. Plex is built for production control, and three-way matching against a PO is the right check for materials and components. The gap only shows up in service vendor categories priced by contract terms the PO was never designed to hold. --- 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