Can Plex store vendor contract terms?

Plex holds vendor master data and PO pricing, not full contract terms. Here is what it captures, what it misses, and why that gap creates margin drift.

Twitter LinkedIn WhatsApp
Ask AI: ChatGPT Claude Gemini Grok
Can Plex store vendor contract terms?

Margin drift is the gap between what a vendor contract says and what the invoice actually charges. Plex is a manufacturing ERP built around production, quality, and supply chain execution, and its vendor records reflect that focus.

The question of whether Plex can store contract terms comes up constantly among Plex users trying to catch overbilling. The honest answer depends on which terms you mean, and this page walks through exactly where the line sits.

Executive Summary

Plex stores vendor master records, purchase order pricing, and receiving data well. It was not built to hold a rebate clause, a volume tier trigger, a not-to-exceed cap, or a surcharge schedule as a structured, enforceable rule. Those terms live in contract PDFs outside the ERP, which means nothing in Plex checks an invoice against them automatically.

The mechanism that causes drift is simple: Plex enforces what it can see. A purchase order price is visible and gets matched. A rebate clause sitting in a signed agreement is not visible to the system at all, so it goes unenforced until someone checks it manually.

What changes this is not a Plex configuration change. It is either a dedicated review of vendor spend against the actual contract language, or a system built specifically to read contract terms and test invoices against them. Plex remains the record of what was ordered and received. It was never the record of what was promised.

1. What vendor data does Plex actually store?

Plex stores vendor master records: name, address, tax ID, approved status, and payment terms such as net 30. On the purchasing side it holds purchase order line pricing, quoted unit costs, and receiving quantities that three-way matching checks against the invoice. It does not store a rate card, a rebate schedule, or a surcharge table as a separate, enforceable object tied to that vendor record.

The purchase order is the closest thing Plex has to a contract. It carries a unit price, a quantity, and a delivery date. Three-way matching compares that price and quantity against the receipt and the invoice, and flags a mismatch.

That control works well for direct materials, where a PO is issued for nearly every purchase. It works less well for service spend: freight, contract labor, maintenance, IT services. Those invoices often arrive against a blanket PO or no PO at all, so the price on the PO line is not the price the contract actually sets.

2. Can Plex hold a full rate card or tiered pricing schedule?

Plex does not have a native field for a tiered rate card, a volume-break pricing schedule, or a rebate percentage that changes once spend crosses a threshold. A vendor record can carry one active unit price, but a contract that says the price drops after a volume tier, or that a rebate accrues quarterly, has no structured home in Plex. The terms sit in the PDF, and the ERP has no way to read or test them.

Consider a freight contract with a fuel surcharge table that adjusts monthly against a published index, or an MRO agreement with a rebate that kicks in once annual spend crosses a threshold. Plex has no field designed to hold either condition as a rule.

A buyer or controller can write the terms into a free-text note on the vendor record, but a note is not enforced. Nothing in Plex reads that note and compares it against the invoice amount when the bill arrives. The invoice gets paid against whatever price is on the PO or the last invoice, correct or not.

3. Where do rebate clauses and NTE caps actually live?

Rebate clauses, not-to-exceed caps, and surcharge schedules live in the signed contract, the master service agreement, or a rate sheet attachment, almost always outside Plex as a PDF or spreadsheet. Nothing connects that document to the invoice approval workflow inside the ERP. The terms exist, but they exist in a filing location the AP process never touches during invoice review.

This is not unique to Plex. Every ERP built around production and inventory, rather than procurement contract management, has the same gap. The contract is a legal document managed by procurement or the business owner, and the invoice is a financial transaction processed by AP. The two rarely meet.

The list below names where each term type typically sits, and why that location keeps it out of the invoice check.

  • Rebate clauses: Usually in the master service agreement or a rebate addendum, referenced but not restated on each invoice, so nobody recalculates the accrual at payment time.
  • NTE caps: Often in a statement of work for contract labor or IT services, expressed as a dollar ceiling per period that a PO line does not carry.
  • Surcharge schedules: Typically in a carrier tariff or a freight agreement, tied to a published index that changes independently of anything in Plex.
  • Volume tier triggers: Set in the contract's pricing exhibit, keyed to cumulative annual spend that no single invoice or PO shows in isolation.

4. What happens when a contract term changes but Plex is not updated?

When a contract renews with a new rate, a new NTE cap, or an expired surcharge clause, Plex keeps using whatever price is already on the purchase order or the vendor record until someone manually updates it. There is no link between the contract's effective date and the ERP's pricing field, so a stale rate can persist for months after the underlying agreement changed.

A surcharge that was contractually temporary, tied to a fuel spike or a one-time capacity shortage, is a common example. The clause states an expiration condition. Plex has no mechanism to test that condition against the calendar or the index it references.

The invoice keeps arriving at the old rate, and the PO or standing price in Plex keeps matching it, because matching only confirms internal consistency between the PO and the invoice. It does not test whether the PO price itself is still the contractually correct one.

5. Should you build a workaround inside Plex to hold contract terms?

A workaround, such as a custom field, an attached document, or a maintained spreadsheet cross-referenced by vendor code, can make contract terms visible to someone who goes looking. It does not make them enforced. The gap this page describes is not about storage, it is about testing every invoice against the term automatically, and a manual cross-reference still depends on someone remembering to check it.

Build vs. buy: can you do contract-to-invoice matching in Excel? covers this tradeoff for spreadsheet-based approaches, and the same logic applies to a Plex custom field. Storing the number is the easy part. Testing it against every invoice, every period, without anyone remembering to look, is the part that fails first when volume grows.

The honest framing: a workaround is a filing improvement, not a control. It reduces how long a discrepancy stays hidden after someone investigates. It does not stop the discrepancy from reaching payment in the first place.

6. How does a margin drift review use Plex data differently?

A margin drift review pulls purchase order history, receiving records, and paid invoices out of Plex, then matches that data against the actual contract language rather than against what Plex itself stored as the price. This catches drift Plex's own matching cannot see, because the reference point is the contract, not the PO field the contract was supposed to populate correctly in the first place.

The Margin Drift Diagnostic for Plex works this way: export the transaction history, then interpret the unstructured contract terms living in PDFs outside the ERP; rate cards, rebate clauses, NTE caps, surcharge schedules; and test the paid invoices against those terms directly.

This finds errors that predate the review, embedded in historical spend, not just errors going forward. A rate card audit for Plex users is different work from configuring a field inside Plex, and the distinction matters when deciding where to spend the effort.

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 Plex have a contract management module?

Plex is built around manufacturing execution, quality, and supply chain workflows. It does not include a dedicated contract management module for storing rate cards, rebate clauses, or surcharge schedules as enforceable rules tied to a vendor.

Can I attach a contract PDF to a vendor record in Plex?

Most ERPs, Plex included, allow document attachments at the vendor or purchase order level. An attachment makes the file retrievable. It does not make its terms machine-readable or tested against invoices automatically.

Does three-way matching in Plex catch contract violations?

Three-way matching checks the invoice against the purchase order and the receipt. It confirms internal consistency between those three documents. It does not test a surcharge's expiration condition or a rebate clause, because neither lives in the PO.

Where should NTE caps for contract labor be tracked if not in Plex?

NTE caps typically live in the statement of work. Tracking them against actual billing requires comparing cumulative invoiced amounts to the cap stated in that document, a step outside standard Plex purchasing workflows.

Is this gap specific to Plex, or true of other manufacturing ERPs?

It applies broadly. Margin Drift Diagnostic for Infor CloudSuite SyteLine covers the same structural gap for another shop-floor-focused ERP. Systems built for production and inventory generally treat the PO price as the contract, which is not always accurate.

Can a custom field in Plex hold a rebate percentage?

A custom field can store a number. It does not recalculate the rebate accrual each period or flag when an invoice should reflect it, so the field becomes another manual lookup rather than a control.

How do I find out how much this gap is already costing us?

The only reliable way is to review paid invoices against the actual contract terms directly, which is what a diagnostic engagement does. Plex's own reporting cannot answer this because it never stored the contract terms to compare against.

Does upgrading to a newer Plex module fix this?

No Plex module is documented as adding rate card enforcement, rebate tracking, or surcharge validation as a core capability. The gap is architectural: Plex tracks orders and receipts, not the contract language behind the price.

What is the fastest way to check if we are affected?

Pull a sample of service vendor invoices, contract labor, freight, or maintenance, and compare them line by line against the signed agreement rather than the PO price in Plex. A mismatch on even a few lines suggests the gap is active in your data.

Should we buy contract management software or fix this manually first?

Diagnostic or software: what to buy first walks through this decision. Buying software before knowing which contracts are actually misaligned risks configuring the wrong rules.

Margin Drift Resources