Freight and 3PL Controls in Plex

Executive Summary

Plex enforces three-way matching: purchase order, receipt, and invoice have to agree before an AP clerk can post a freight bill without an override. That catches quantity and unit-price mismatches against what was ordered. It does not catch a mismatch between a carrier's rate card and the rate actually billed, because the rate card usually lives outside Plex as a contract document, not as a rule Plex evaluates line by line.

Freight invoices carry cost structure a purchase order rarely encodes: fuel surcharge tables that move weekly, accessorial charges for detention or liftgate service, minimum weight breaks. Plex's PO-based match tests whether the invoice agrees with the PO. It does not test whether the PO's own freight terms, or a standing carrier agreement referenced by neither, were followed.

The fix is not replacing Plex. It is adding a control that reads the carrier contract and checks the invoice against it, either as a review step before payment or as a periodic audit against paid invoices. Plex remains the system of record; the contract logic sits alongside it.

1. What does Plex check on a freight invoice before it posts?

Plex's accounts payable module runs a three-way match: it compares the purchase order, the goods receipt, and the vendor invoice, and blocks posting when quantities or unit prices disagree beyond a configured tolerance. For a freight invoice, this confirms the billed line matches what was ordered and received in Plex. It does not evaluate whether the freight rate itself, the fuel surcharge applied, or an accessorial charge conforms to the carrier's underlying contract, because none of that lives inside the.

The three-way match is a control against the purchase order, not against a contract. A freight PO in Plex typically carries a line item, a quantity, and a unit cost entered at order time. When the carrier's invoice arrives, Plex checks that the invoiced amount lines up with what the PO recorded.

That is a real control, and it stops a class of errors: billing for freight that was never ordered, or a unit price typed incorrectly at receipt. But the PO line itself is only as accurate as whatever rate was keyed in when the order was created, and Plex has no independent check on that rate against the carrier's rate card.

Surcharges compound the gap. A fuel surcharge is usually a percentage applied on top of the base rate, tied to a published index that moves weekly. The Producer Price Index for gasoline (US Bureau of Labor Statistics, series WPU0571, read September 6, 2026) showed a July 2026 index value of 302.759, up 37.1% year over year, illustrating how fast the underlying fuel cost can move against a surcharge table.

Plex has no mechanism that recalculates what a surcharge should be for a given week and compares it to what was billed.

2. Where does Plex's PO-based match fall short on accessorial charges?

Accessorial charges (detention, liftgate service, residential delivery, redelivery fees) are typically billed after the fact, once a shipment has already moved, and they rarely have a corresponding PO line. Plex's three-way match requires a PO and receipt to compare against; an accessorial charge with no PO line has nothing to match to, so it either posts on a manual override or routes to a generic exception queue with no reference to what the carrier contract actually permits.

A detention charge, for example, gets applied when a driver waits past a free time allowance at a dock. The carrier's contract states the free time and the per-hour rate after it. None of that arrives in Plex until the invoice does, and by then the PO for the original shipment has already closed.

AP staff handling these exceptions are working from the invoice alone, without the contract's accessorial schedule open next to it. Whether the free time was calculated correctly, or the per-hour rate matches the contract rather than a default rate the carrier applied, is not something the three-way match tests.

The same applies to minimum weight breaks and fuel surcharge tiers that step at specific thresholds. These are contract terms, not PO terms, and Plex's matching engine was not built to hold a second document, the carrier agreement, in memory while it evaluates an invoice line.

3. Can Plex enforce a minimum volume commitment or rebate clause?

Plex has no native construct for a minimum volume commitment or an earned rebate tied to freight spend. These clauses require tracking cumulative volume or spend against a carrier across a period and comparing it to a threshold in the contract, then confirming a rebate or true-up was applied. Plex's AP and purchasing modules track transactions individually; nothing in the standard configuration aggregates spend against a contract threshold or flags when a rebate should have posted and did not.

A rebate clause pays back a percentage once volume crosses a stated tier within a period, often a quarter or a year. Confirming that happened requires two things at once: a running total of shipments or spend with that carrier, and the tier structure from the contract.

Plex can report total spend by vendor over a date range, which supplies half of what is needed. It cannot hold the tier structure as a rule and alert when a threshold is crossed, because that structure is not part of its purchasing or AP data model.

The result is that a rebate due under contract has to be caught by someone manually cross-referencing a spend report against a contract term, on a schedule someone remembers to run. If nobody runs it, or runs it late, the rebate is easy to miss.

4. Does Plex flag a stale or duplicate freight rate automatically?

Plex checks for duplicate invoice numbers from the same vendor, a standard AP control that catches exact duplicate submissions. It does not check whether a rate used on a freight PO is stale, meaning it reflects last year's contracted rate after a rate card update took effect, because Plex has no scheduled process that re-validates standing rates against a current contract version.

Duplicate detection in Plex works off invoice number and vendor combination. Submit the same invoice twice with the same number, and the second attempt is flagged. This is useful and catches a real error type, but it is a narrow check: it says nothing about whether the rate on a legitimate, non-duplicate invoice is correct.

A stale rate is different from a duplicate. It happens when a carrier contract renews with new rates, and the PO template, price list, or vendor record inside Plex is not updated to match. Every subsequent freight PO created from that template carries the old rate forward, and every invoice against it matches cleanly, because Plex is comparing the invoice to its own stale PO, not to the current contract.

The Producer Price Index for general freight trucking, long-distance truckload (US Bureau of Labor Statistics, series PCU484121484121, read September 6, 2026) showed a July 2026 index value of 195.575, up 8.1% year over year, indicating base freight rates have moved materially within a typical contract cycle. A rate card control needs to catch that movement being reflected, or not reflected, in what Plex is actually billing against.

5. What would a working freight rate control look like alongside Plex?

A working control reads the current carrier contract, including the rate card, surcharge table, and accessorial schedule, as a structured rule set, then checks each invoice line against it before or shortly after payment. Plex supplies the transaction data: invoice amount, PO reference, vendor, ship date. The contract logic has to be maintained separately, because Plex's data model does not represent a rate card as a first-class object.

Neither approach requires replacing Plex. Both require the carrier contract to exist somewhere as a structured, checkable rule set rather than a signed document referenced only when a dispute arises.

The arithmetic that makes this worth doing is the reader's own: take annual freight and 3PL spend, multiply by the share moving through PO-based Plex transactions rather than one-off accessorial billing, and that is the base a rate card control would review. The BLS Producer Price Index for truck transportation of freight (series WPU3012, read September 6, 2026) showed a July 2026 value of 170.984, up 10.9% year over year, a reminder that a rate card left unchecked for a year is being checked against a cost base that has already moved.

A. Pre-payment review

Routing freight invoices through a review step before they post in Plex, where the reviewer or a rule set checks the invoice against the current rate card and surcharge table, catches drift before cash leaves. This requires the current contract to be available in a usable form, not buried in a PDF nobody has opened since signing.

B. Periodic post-payment audit

Where a pre-payment step is not practical for volume reasons, a periodic audit against paid freight invoices, run against the same contract terms, recovers what a pre-payment check would have prevented. This is retrospective by design and works against the 12 to 18 months of historical spend most companies have not reviewed.

6. Should a $100M+ manufacturer on Plex run a diagnostic or build the control in-house?

The answer depends on whether the current carrier contracts and rate cards are already organized in a form a rule set could reference. If they are not, a diagnostic that reviews existing freight spend against contract terms surfaces the gap and quantifies it before anyone commits to building or buying ongoing enforcement. Building the check first, without knowing which contracts and terms actually drive drift, risks enforcing rules nobody has validated yet.

A manufacturer above $100M in revenue running Plex for production and AP has usually accumulated years of freight invoices without a systematic check against carrier contracts, simply because Plex was never the tool for that check. That backlog is where a diagnostic starts: reviewing invoice history against the contracts that were actually in force at the time.

Margin drift across a full diagnostic typically runs 1% to 3% of service vendor spend, across ValueXPA diagnostics, and that finding spans every category the diagnostic covers, not freight alone. What a diagnostic adds specific to freight is a clear picture of which contract terms Plex's matching never tested: the rate card, the surcharge table, the accessorial schedule, the rebate tier.

That picture is what makes a build-or-buy decision for ongoing enforcement a real decision instead of a guess. Building a rate card check against rules nobody has validated risks encoding the wrong rules with confidence.

For the wider pattern this sits inside, start with the margin drift guide. See also diagnostic or software: what to buy first and build vs. buy: can you do contract-to-invoice matching in excel?.

7. Frequently Asked Questions (People Also Ask)

Does Plex integrate directly with freight rate cards from carriers?

Not natively. Plex's purchasing and AP modules record a rate on a PO or price list, but there is no built-in feed that pulls a carrier's current rate card and reconciles it against those records. Any comparison to the actual contracted rate card has to happen outside Plex or through a custom integration your team builds and maintains.

Will Plex block payment on a freight invoice that violates a not-to-exceed cap?

Only if the cap is represented as the PO's unit price or quantity limit and the invoice exceeds Plex's configured tolerance for that match. A not-to-exceed clause defined only in the carrier contract, and not entered as a PO limit in Plex, will not trigger a block.

Can Plex track accumulated freight spend against a carrier's rebate tier?

Plex can report total spend by vendor over a date range, which is the raw data a rebate calculation needs. It does not hold the rebate tier structure as a rule or alert automatically when a threshold is crossed. Someone has to run that comparison manually against the contract.

Is Plex's three-way match enough to catch freight overbilling on its own?

It catches overbilling relative to what was entered on the purchase order, which stops some errors. It does not catch overbilling relative to the carrier's actual contracted rate card, fuel surcharge table, or accessorial schedule, because those live outside the PO Plex is matching against.

What freight invoice data does Plex actually retain that a later audit can use?

Plex retains the PO, receipt, invoice amount, vendor, and posting date for each transaction, which is sufficient to reconstruct what was billed and when. It does not retain the carrier contract terms themselves, so an audit still needs the contract documents from that period to check the transactions against.

Does upgrading to a newer Plex module fix the freight contract matching gap?

No Plex module, current or planned, is documented as evaluating a carrier rate card, surcharge table, or accessorial schedule as a rule set against invoices. The gap is structural to how Plex's data model represents a PO, not a version limitation.

Should we build a custom Plex integration for freight contract checking, or run a diagnostic first?

A diagnostic first tells you which contract terms are actually driving drift in your invoice history, so any integration you later build enforces validated rules rather than guessed ones. Building first risks encoding the wrong checks with confidence.

Are fuel surcharges the main freight cost that Plex fails to check?

Fuel surcharges are one contract term Plex's PO-based match does not evaluate, alongside accessorial charges, rebate tiers, and minimum weight breaks. Each requires the carrier contract as a reference, which is not part of Plex's data model for a purchase order.