How Do You Report on Invoice Exceptions in Plex?

Executive Summary

Plex reports invoice exceptions through its AP module by comparing the invoice line to the purchase order and the receipt. When quantity, unit price, or PO reference do not agree, the system holds the invoice and logs the variance to an exception queue that AP can report against by vendor, buyer, or age.

That queue is a real control, and a useful one. It catches the invoice that bills more units than were received, or a unit price that does not match the PO line. It does not catch a surcharge table that reset itself after a contract renegotiation, a volume tier that should have dropped the rate a level, or an NTE cap on a labor invoice that has no PO line at all.

The mechanism problem is structural, not a configuration gap someone forgot to close. Plex's exception engine reasons about what the PO recorded. Contract terms that live outside the PO, rebate percentages, tier thresholds, calibration intervals, exist in a PDF the ERP never reads.

Reporting on those requires comparing the invoice to the contract directly, a separate step from anything Plex's exception queue does today.

1. What exception report does Plex generate natively?

Plex generates a purchase order variance report inside its AP module. It flags any invoice line where quantity, unit price, or PO number fails to match the linked purchase order and receipt record, and routes the invoice to a hold status until someone with approval rights clears it. The report is filterable by vendor, buyer, plant, and exception age, and it sits alongside the standard AP aging views finance already runs.

The report is generated automatically as invoices are entered or received electronically. Plex does not require a separate reconciliation run; the exception surfaces at the point of three-way matching, which is also the point where it is cheapest to catch.

What lands on the report is a variance, not a diagnosis. An invoice that bills 1,050 units against a PO for 1,000 appears the same way whether it is a data entry error, a partial shipment miscount, or an intentional overbill. The AP clerk reading the queue has to investigate each line before it means anything.

This is the correct design for what a three-way match is for. It is a control against receiving and quantity errors, run on every invoice. It was never meant to evaluate whether the price itself, agreed correctly at PO creation, is still the right price by the time the invoice arrives months into a contract term.

2. Which exceptions does the PO variance report actually catch?

The PO variance report catches quantity mismatches, unit price differences against the PO line, missing or invalid PO references, and duplicate invoice numbers against the same vendor. Each of these compares the invoice to a number that was set once, at PO creation, and stays fixed. That is precisely the class of error three-way matching was designed to catch, and Plex does it reliably for any transaction that runs through a purchase order.

Quantity variance is the clearest case: the invoice claims more units shipped than the receipt confirms. Unit price variance catches a vendor who bills above the agreed PO price, assuming the PO price itself was correct when entered.

Duplicate detection compares invoice numbers and amounts against vendor history, which is how repeat payments on the same invoice get flagged before the second check goes out.

All four checks share one property: they test the invoice against a static reference point captured inside Plex. None of them test the invoice against anything that changes over the life of a contract, because a PO number does not carry a rate schedule, a rebate percentage, or a renewal date with it.

3. Which invoice errors never reach the exception queue?

Surcharge schedules that should have expired, volume tier discounts that should have triggered, rebate clauses that go unclaimed, and NTE caps on labor and professional services invoices all sit outside what a PO variance check tests. None of these show up as a quantity or PO-number mismatch, so the invoice clears the three-way match and pays on schedule even when the rate applied contradicts the contract.

A fuel surcharge negotiated at a temporary rate, tied to a diesel price threshold, has no PO field that tracks whether that threshold has since reversed. The invoice matches its PO. It also overcharges.

A volume tier works the same way: a contract that drops the unit rate after a spend threshold does not update the PO price automatically. The PO was cut at the old rate and stays there.

Contract labor and professional services invoices are a separate risk entirely, because many arrive without a PO line at all. An NTE cap that the invoice exceeds has nothing in Plex to compare against, so it never generates an exception in the first place.

4. How do contract terms differ from PO terms in Plex's model?

A PO in Plex captures a price, a quantity, and a vendor at one point in time. A contract captures a set of conditions that change that price over the life of the relationship: tier thresholds, rebate percentages, surcharge expiration dates, and renewal terms. Plex's exception logic reads the first.

It has no field for the second, so a rule inside the contract that should change the invoiced price has no mechanism inside the ERP to enforce it.

The PO field holds a single negotiated price and quantity, fixed at the moment of creation. It is accurate on day one and stays exactly as written until someone manually revises it, regardless of what the underlying contract does next.

The contract holds conditional terms instead: a rate change at a volume threshold, a rebate owed after a spend milestone, a surcharge that expires on a stated date. These conditions live in a signed document, not in a Plex data field, and nothing inside the ERP evaluates them against the invoice as it arrives.

A. What the PO field holds

A single negotiated price and quantity, fixed at the moment of PO creation. It is accurate on day one and stays exactly as written until someone manually revises it, regardless of what the underlying contract does next.

B. What the contract holds

Conditional terms: rate changes at a volume threshold, a rebate owed after a spend milestone, a surcharge that expires on a stated date. These conditions live in a signed PDF, not in a Plex data field, and nothing inside the ERP evaluates them against the invoice as it arrives.

5. Can Plex reporting be extended to test contract terms?

Plex's report writer can be extended with custom fields and workflows, but extending it to test a rate card or a rebate clause means manually encoding every contract's terms into the system as structured data, then maintaining that encoding every time a contract renews or a rate changes. For a handful of vendors this is workable inside a spreadsheet layered on top of Plex exports. Past a few dozen active service contracts, the maintenance burden usually exceeds what the AP.

Building a spreadsheet model that pulls Plex invoice data and checks it against a manually maintained contract terms table is a real option, and some AP teams run exactly this for their highest-spend vendors.

The work is in the upkeep. Every contract renewal, tier change, or surcharge adjustment has to be re-entered by hand, and a missed update makes the check wrong in the direction of understating drift, since the spreadsheet keeps testing the invoice against terms that no longer apply.

Whether to build that layer yourself or bring in a tool built for exactly this comparison is worth answering on its own before configuring anything further in Plex.

6. Where should a manufacturer look to close the exception gap?

Closing the gap between Plex's PO variance report and a full contract-compliance check requires comparing invoices against the actual contract terms, not against the PO, and doing it retrospectively across recent spend as well as going forward on new invoices. That comparison is what a Margin Drift Diagnostic is built to run for a Plex environment specifically, without requiring the AP team to first build and maintain a manual terms table.

A diagnostic run against historical Plex invoice data tests each line against the actual contract, not the PO snapshot, and surfaces where a surcharge, tier, or rebate clause diverged from what was billed.

That is a different exercise from what the PO variance report does, and it is meant to complement it rather than replace it. The variance report still catches the same-day quantity and PO errors it always has; the diagnostic addresses the contract-term drift that accumulates quietly underneath it.

The two together cover what one alone cannot: forward transaction accuracy from Plex, and contract-term accuracy from a process built to read the contract itself.

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 match invoices against contracts automatically?

No. Plex's exception logic compares an invoice to its linked purchase order and receipt record. A contract's rate tiers, rebate clauses, or surcharge terms are not fields Plex evaluates during that match, so an invoice can clear the PO variance check while still contradicting the contract.

Why does an invoice with the wrong surcharge still pass Plex's exception check?

The surcharge amount usually matches whatever was entered on the PO or invoice line, so there is no quantity or price variance against that reference. The problem is that the surcharge itself should have expired or changed, and nothing in the PO record tracks that condition.

Can contract labor invoices generate exceptions in Plex?

Only if they are tied to a purchase order. Many contract labor and professional services invoices arrive without a PO line, which means there is nothing for Plex's three-way match to compare them against, and an NTE overrun on that invoice will not generate an exception.

What is the difference between a PO variance and a contract compliance issue?

A PO variance is a mismatch against a number Plex already has on file: quantity, unit price, or PO number. A contract compliance issue is a mismatch against a condition that lives outside Plex entirely, in the signed contract, such as a rebate threshold or a surcharge expiration date.

Should we build a spreadsheet to check Plex invoices against our contracts?

It is workable for a small number of high-spend vendors, but it requires manually re-entering every contract renewal, rate change, or tier adjustment, and a missed update silently understates drift rather than flagging it.

How far back can contract-term drift be found in Plex invoice history?

This depends on how far back Plex invoice and PO data is retained and exportable, and on how far back the underlying contracts are documented. A diagnostic run against historical data can typically review 12 to 18 months of historical spend, across ValueXPA diagnostics.

Does fixing Plex's exception workflow settings solve this?

No. The exception workflow controls how a flagged invoice routes for approval, not what gets tested. Even a perfectly configured workflow only ever tests the PO variance conditions Plex is built to check, not contract terms outside the PO.

Is a Margin Drift Diagnostic a replacement for Plex's exception report?

No, it is complementary. The PO variance report continues to catch same-day quantity and price errors against the PO. The diagnostic tests invoices against the actual contract terms, which is a separate comparison Plex was not built to run.

What data does a Plex-based diagnostic need to run?

Exported invoice and PO history from Plex, plus the underlying vendor contracts, rate cards, and rebate agreements for the categories under review. The comparison runs outside Plex and does not require changing its configuration.