# Where do contract terms live if you use Plex? > Plex enforces the routing and work order data it holds. Contract terms like NTE caps and rebate tiers usually live outside it, in separate files. Source: https://valuexpa.com/insights/where-do-contract-terms-live-if-you-use-plex 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 was built for shop floor execution: work orders, routings, quality records, MES data tied to production. It was not built to be a contract repository. That distinction matters more than it sounds. If a rate card, a volume tier, or a not-to-exceed cap lives in a PDF outside Plex, nothing in Plex checks an incoming invoice against it. The invoice clears. The drift does not. ## Executive Summary Plex holds structured production and transactional data well: purchase orders, receipts, supplier records tied to a part number or work order. What it does not natively hold is the unstructured contract language that actually governs a service vendor invoice: a rebate clause tied to annual spend, a surcharge schedule tied to a fuel index, an NTE cap tied to a labor category, a volume tier that steps a rate down after a threshold. That language typically sits in a signed PDF, a vendor's rate sheet, or a spreadsheet an AP or procurement team maintains separately. Plex's three-way match tests an invoice against a purchase order and a receipt. It does not test the invoice against the rate the contract actually promised for that quantity, that tier, that month. The mechanism causing drift is simple: two systems of record for one relationship, and no automatic link between them. Closing that gap means either building the link manually, clause by clause, or running an audit that reconstructs the mapping and hands back the rules Plex should have been checking against. ## 1. What does Plex actually store about a vendor relationship? **Plex stores the transactional side of a vendor relationship: the purchase order, the goods or service receipt, the supplier record tied to a part number or work order, and the invoice line submitted against that PO. It does not store the contract document itself. The rate card, the rebate schedule, the surcharge formula and the NTE cap that govern whether a given invoice line is correct sit outside the system, wherever the vendor's signed agreement was filed.** This is not a gap unique to Plex. Most ERPs built around production and inventory control follow the same pattern: they track what was ordered and what was received, not what was promised. The purchase order captures a quantity and a price at the moment of entry. But a service contract's terms often change after that moment. A volume tier steps a rate down once cumulative spend crosses a threshold. A rebate accrues over a quarter and gets invoiced separately. A surcharge floats with a published index. None of that logic lives in the PO record, because none of it was true when the PO was cut. ## 2. Why doesn't three-way matching catch a contract violation? **Three-way matching checks that the invoice quantity and price agree with the purchase order and the receipt. It confirms internal consistency between three documents Plex already holds. It does not test whether the price on the purchase order itself still reflects the contract, because the contract's rate table, tier structure and cap conditions were never entered into Plex as a rule the match could check against.** Consider a maintenance contract with a not-to-exceed cap on labor hours per callout. If the PO was cut for a flat service fee and the invoice matches that fee, three-way matching passes. Whether the vendor actually stayed under the labor cap that made the fee valid is a separate question the match never asks. The same holds for a rebate clause. If a vendor owes a rebate after a spend threshold and never issues the credit memo, nothing in the PO-to-invoice comparison flags the missing credit. The match confirms the invoice matches what was billed, not what was owed. ## 3. Where should a manufacturer actually keep contract terms? **There is no single right repository. What matters is that rate cards, rebate clauses, surcharge schedules and NTE caps are extracted from the source PDF into a structured form, a table or rule set, that someone or something checks every invoice against before payment. Whether that structured form lives in a shared drive, a contract management tool, or a rules engine matters less than whether the checking actually happens on every invoice.** One option is manual extraction: an AP or procurement analyst reads the contract, builds a spreadsheet of rates and tiers, and updates it when the contract renews. This works at small vendor count. It degrades as complexity grows, because the spreadsheet is only as current as the last person who remembered to edit it. The other option is a structured audit: a review of every active service contract, matched line by line against a period of invoices, producing a documented rule set: this vendor's rate card, this vendor's rebate trigger, this vendor's cap. That rule set can then feed a forward control, manual or software-based. ### A. Manual extraction An AP or procurement analyst reads the contract, builds a spreadsheet of rates and tiers, and updates it when the contract renews. This works at small volume. It degrades as vendor count and contract complexity grow, because the spreadsheet is only as current as the last person who remembered to edit it. ### B. Structured audit A one-time review of every active service contract, matched line by line against a period of invoices, produces a documented set of rules: this vendor's rate card, this vendor's rebate trigger, this vendor's cap. That rule set can then feed a forward control, whether manual or software-based. ## 4. Can Plex be configured to enforce a rate card directly? **Plex can enforce a price once that price is entered as the standard cost or PO price for a part or service line. It enforces what is configured, not what the contract intends. A rate card with volume tiers, a surcharge tied to a floating index, or a rebate accrual requires logic beyond a static price field, and configuring that logic inside Plex means building and maintaining it as a custom extension.** That is a real option for a manufacturer with the internal IT capacity to build and maintain custom logic inside Plex. It is also an ongoing cost: every contract renewal, every renegotiated tier, every new surcharge index means someone revisits the configuration. For a manufacturer without that dedicated capacity, the practical alternative is keeping the rule set outside Plex, current, and checked against every invoice by a person or a separate control before the invoice is approved. ## 5. What happens to spend that predates a fix? **Fixing the gap going forward does nothing to the invoices already paid. If a rebate clause went unclaimed for a year, or a surcharge kept applying after its trigger condition lapsed, that leakage sits in historical spend that a forward control never reaches. Recovering it requires a retrospective review of past invoices against the same contract terms, run separately from whatever prevention gets put in place.** This is why a diagnostic and a forward control answer different questions. One looks backward across 12 to 18 months of paid invoices, across ValueXPA diagnostics, to find money already lost. The other looks forward at the next invoice. A manufacturer solving only the forward problem, by configuring Plex or adding a rules layer, leaves the historical leakage unaddressed. Both problems are real. Neither substitutes for the other. ## 6. Should you fix this inside Plex or run a separate audit first? **Configure Plex to enforce a rule only once you know what the rule should be. Building custom price logic against a guessed rate card enforces the wrong rate card. An audit that reconstructs actual contract terms against actual invoice history gives you the verified rule set first, and that rule set is what makes any later configuration work worth doing.** The order matters because the cost of being wrong compounds. A configuration built against an assumed rate table has to be rebuilt once the real table surfaces, and until then it is quietly enforcing the wrong number on every invoice that passes through it. The reverse order costs nothing extra. A diagnostic that maps contract terms to invoice history produces the rule set as a byproduct, whether or not the manufacturer later chooses to encode it inside Plex, a spreadsheet, or a separate system. 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 Plex have a contract management module? Plex is built around production, inventory and supplier transaction data, not contract document storage. Some manufacturers attach vendor agreements as reference files, but Plex does not parse contract clauses or check invoices against rate tiers, rebate triggers or surcharge formulas automatically. ### Can Plex catch a duplicate payment to the same vendor? Plex's matching logic can flag an invoice that duplicates a PO or receipt already recorded in the system. Whether it catches a duplicate depends on how consistently the vendor's invoice numbers and references are entered, which is a data discipline question as much as a system capability. ### What's the difference between a PO price and a contract rate? A PO price is whatever was entered when the purchase order was created. A contract rate is what the signed agreement actually specifies, including any tier, cap or rebate condition. The two only match if someone kept the PO updated every time the contract terms changed. ### Do we need to migrate off Plex to fix this? No. The gap is about where contract terms are tracked and checked, not about the ERP itself. A manufacturer can keep Plex for production and transactional data while adding a separate structured rule set, manual or software-based, for contract enforcement. ### Who inside a company typically owns this rule set? It varies. In some manufacturers, procurement owns the contract file and AP owns invoice review, with no single owner of the mapping between the two. That split ownership is itself part of why the rule set often goes stale. ### Is this specific to Plex, or true of other ERPs too? The same gap shows up across ERPs built for production and transactional control rather than contract management, including Infor CloudSuite SyteLine. The specific fields and modules differ, but the underlying separation between contract terms and transactional data is common. ### How far back should a review of past invoices go? A useful starting point is 12 to 18 months of historical spend, across ValueXPA diagnostics, since that window typically covers at least one full cycle of most contract terms, including annual rebates and periodic rate resets. ### Does this only matter for large vendor contracts? Contract complexity, not size alone, is what creates the gap. A smaller vendor with a tiered rate card or a floating surcharge can carry the same unenforced terms as a larger one. The relevant question is whether the contract has conditions beyond a flat price. ### 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 holds structured production and transactional data well: purchase orders, receipts, supplier records tied to a part number or work order. What it does not natively hold is the unstructured contract language that actually governs a service vendor invoice: a rebate clause tied to annual spend, a surcharge schedule tied to a fuel index, an NTE cap tied to a labor category, a volume tier that steps a rate down after a threshold. That language typically sits in a signed PDF, a vendor's rate sheet, or a spreadsheet an AP or procurement team maintains separately. Plex's three-way match tests an invoice against a purchase order and a receipt. It does not test the invoice against the rate the contract actually promised for that quantity, that tier, that month. The mechanism causing drift is simple: two systems of record for one relationship, and no automatic link between them. Closing that gap means either building the link manually, clause by clause, or running an audit that reconstructs the mapping and hands back the rules Plex should have been checking against. ## 1. What does Plex actually store about a vendor relationship? Plex stores the transactional side of a vendor relationship: the purchase order, the goods or service receipt, the supplier record tied to a part number or work order, and the invoice line submitted against that PO. It does not store the contract document itself. The rate card, the rebate schedule, the surcharge formula and the NTE cap that govern whether a given invoice line is correct sit outside the system, wherever the vendor's signed agreement was filed. This is not a gap unique to Plex. Most ERPs built around production and inventory control follow the same pattern: they track what was ordered and what was received, not what was promised. The purchase order captures a quantity and a price at the moment of entry. But a service contract's terms often change after that moment. A volume tier steps a rate down once cumulative spend crosses a threshold. A rebate accrues over a quarter and gets invoiced separately. A surcharge floats with a published index. None of that logic lives in the PO record, because none of it was true when the PO was cut. ## 2. Why doesn't three-way matching catch a contract violation? Three-way matching checks that the invoice quantity and price agree with the purchase order and the receipt. It confirms internal consistency between three documents Plex already holds. It does not test whether the price on the purchase order itself still reflects the contract, because the contract's rate table, tier structure and cap conditions were never entered into Plex as a rule the match could check against. Consider a maintenance contract with a not-to-exceed cap on labor hours per callout. If the PO was cut for a flat service fee and the invoice matches that fee, three-way matching passes. Whether the vendor actually stayed under the labor cap that made the fee valid is a separate question the match never asks. The same holds for a rebate clause. If a vendor owes a rebate after a spend threshold and never issues the credit memo, nothing in the PO-to-invoice comparison flags the missing credit. The match confirms the invoice matches what was billed, not what was owed. ## 3. Where should a manufacturer actually keep contract terms? There is no single right repository. What matters is that rate cards, rebate clauses, surcharge schedules and NTE caps are extracted from the source PDF into a structured form, a table or rule set, that someone or something checks every invoice against before payment. Whether that structured form lives in a shared drive, a contract management tool, or a rules engine matters less than whether the checking actually happens on every invoice. One option is manual extraction: an AP or procurement analyst reads the contract, builds a spreadsheet of rates and tiers, and updates it when the contract renews. This works at small vendor count. It degrades as complexity grows, because the spreadsheet is only as current as the last person who remembered to edit it. The other option is a structured audit: a review of every active service contract, matched line by line against a period of invoices, producing a documented rule set: this vendor's rate card, this vendor's rebate trigger, this vendor's cap. That rule set can then feed a forward control, manual or software-based. ### A. Manual extraction An AP or procurement analyst reads the contract, builds a spreadsheet of rates and tiers, and updates it when the contract renews. This works at small volume. It degrades as vendor count and contract complexity grow, because the spreadsheet is only as current as the last person who remembered to edit it. ### B. Structured audit A one-time review of every active service contract, matched line by line against a period of invoices, produces a documented set of rules: this vendor's rate card, this vendor's rebate trigger, this vendor's cap. That rule set can then feed a forward control, whether manual or software-based. ## 4. Can Plex be configured to enforce a rate card directly? Plex can enforce a price once that price is entered as the standard cost or PO price for a part or service line. It enforces what is configured, not what the contract intends. A rate card with volume tiers, a surcharge tied to a floating index, or a rebate accrual requires logic beyond a static price field, and configuring that logic inside Plex means building and maintaining it as a custom extension. That is a real option for a manufacturer with the internal IT capacity to build and maintain custom logic inside Plex. It is also an ongoing cost: every contract renewal, every renegotiated tier, every new surcharge index means someone revisits the configuration. For a manufacturer without that dedicated capacity, the practical alternative is keeping the rule set outside Plex, current, and checked against every invoice by a person or a separate control before the invoice is approved. ## 5. What happens to spend that predates a fix? Fixing the gap going forward does nothing to the invoices already paid. If a rebate clause went unclaimed for a year, or a surcharge kept applying after its trigger condition lapsed, that leakage sits in historical spend that a forward control never reaches. Recovering it requires a retrospective review of past invoices against the same contract terms, run separately from whatever prevention gets put in place. This is why a diagnostic and a forward control answer different questions. One looks backward across 12 to 18 months of paid invoices, across ValueXPA diagnostics, to find money already lost. The other looks forward at the next invoice. A manufacturer solving only the forward problem, by configuring Plex or adding a rules layer, leaves the historical leakage unaddressed. Both problems are real. Neither substitutes for the other. ## 6. Should you fix this inside Plex or run a separate audit first? Configure Plex to enforce a rule only once you know what the rule should be. Building custom price logic against a guessed rate card enforces the wrong rate card. An audit that reconstructs actual contract terms against actual invoice history gives you the verified rule set first, and that rule set is what makes any later configuration work worth doing. The order matters because the cost of being wrong compounds. A configuration built against an assumed rate table has to be rebuilt once the real table surfaces, and until then it is quietly enforcing the wrong number on every invoice that passes through it. The reverse order costs nothing extra. A diagnostic that maps contract terms to invoice history produces the rule set as a byproduct, whether or not the manufacturer later chooses to encode it inside Plex, a spreadsheet, or a separate system. 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 Plex have a contract management module? Plex is built around production, inventory and supplier transaction data, not contract document storage. Some manufacturers attach vendor agreements as reference files, but Plex does not parse contract clauses or check invoices against rate tiers, rebate triggers or surcharge formulas automatically. ### Can Plex catch a duplicate payment to the same vendor? Plex's matching logic can flag an invoice that duplicates a PO or receipt already recorded in the system. Whether it catches a duplicate depends on how consistently the vendor's invoice numbers and references are entered, which is a data discipline question as much as a system capability. ### What's the difference between a PO price and a contract rate? A PO price is whatever was entered when the purchase order was created. A contract rate is what the signed agreement actually specifies, including any tier, cap or rebate condition. The two only match if someone kept the PO updated every time the contract terms changed. ### Do we need to migrate off Plex to fix this? No. The gap is about where contract terms are tracked and checked, not about the ERP itself. A manufacturer can keep Plex for production and transactional data while adding a separate structured rule set, manual or software-based, for contract enforcement. ### Who inside a company typically owns this rule set? It varies. In some manufacturers, procurement owns the contract file and AP owns invoice review, with no single owner of the mapping between the two. That split ownership is itself part of why the rule set often goes stale. --- 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