Freight and 3PL Controls in Sage Intacct

Executive Summary

Sage Intacct enforces the controls a general ledger is built to enforce: purchase order matching, approval workflows by dimension, and duplicate invoice detection at the vendor and invoice-number level. These stop a freight invoice from posting twice or bypassing an approver. They do not stop a freight invoice from posting at the wrong price.

The mechanism is structural. Intacct's matching logic compares an invoice to a purchase order and a receipt. A freight contract's rate card, fuel surcharge table, and accessorial schedule live outside that three-way match entirely, usually in a PDF from the carrier or 3PL.

Intacct has no field that tests an invoiced fuel surcharge against the index it was supposed to track, and no rule that flags a surcharge still charging after a contract's step-down date.

What changes this is not a bigger ERP. It is a control layer that reads the contract terms Intacct was never built to hold, and tests each invoice against them before or after the ERP posts it. The diagnostic below shows where that layer needs to sit.

1. What does Sage Intacct actually check on a freight invoice before it posts?

Sage Intacct's AP module checks that a freight invoice has a valid vendor record, ties to an open purchase order or bill within configured tolerance, routes through the approval workflow assigned to its dimension (entity, department, location), and does not duplicate an invoice number already booked to that vendor. These are ledger-integrity checks. They confirm the invoice is a legitimate, non-duplicate document tied to an authorized purchase.

They say nothing about whether the rate, surcharge, or accessorial charge on that.

Three-way matching in Intacct compares quantity and unit price on the invoice against the purchase order and, where configured, a receipt record. For freight, the purchase order usually authorizes a shipment or a blanket lane commitment, not a rate card with fuel index formulas and accessorial tiers. The match confirms the invoice references the right PO.

It does not decompose the invoice into base rate, fuel surcharge, and accessorial lines and test each against a separate reference table.

Approval workflows route the invoice to the right cost center owner based on dimension values set on the transaction. That control catches a freight invoice posted to the wrong entity or missing an approval step. It does not catch a correctly-approved invoice that overcharges, because the approver is checking authorization, not rate accuracy, and Intacct gives them no side-by-side view of the invoice against the carrier's tariff to check it with.

Duplicate detection compares vendor ID and invoice number against invoices already in the system. It is a real control and it works as designed. It has no bearing on whether a single, non-duplicate invoice is priced correctly against contract.

2. Where does the fuel surcharge actually get tested against a real index?

It doesn't, inside Intacct. The platform posts whatever surcharge amount or rate appears on the invoice line; it has no built-in connection to a diesel or freight price index and no field that recalculates what a surcharge should be this week. Testing a surcharge means pulling the invoice's stated basis, usually a index name and lag period from the contract, and checking it separately against a published index before or after the invoice posts.

Fuel surcharges are typically pegged to a published index with a stated lag, for example the prior week's average. Per US EIA data, gasoline PPI (WPU0571) stood at 302.759 in July 2026, up 37.1% year over year (read 2026-09-06). Per BLS PPI, truck transportation of freight (WPU3012) reached 170.984 in July 2026, up 10.9% year over year (read 2026-09-06), and long-distance truckload trucking (PCU484121484121) reached 195.575, up 8.1% year over year (read 2026-09-06).

Contract surcharge schedules that reference an index will move with numbers like these.

Intacct has no native field or workflow that pulls a fuel index and recalculates the surcharge a given invoice should carry. An AP clerk keying the invoice enters the surcharge amount the carrier billed, and Intacct posts it. The invoice looks structurally correct: it matches a PO, it has an approval, it is not a duplicate.

Whether the surcharge itself is calculated on the right index, the right lag, and the right base rate is a separate question the ledger was never built to ask.

3. Can Intacct detect an accessorial charge that was never in the contract?

No. Intacct records whatever line items and amounts appear on the invoice as entered. It has no reference table of contracted accessorial charges, detention fees, or liftgate rates to compare against, so an accessorial charge that was never negotiated, or one billed above its contracted rate, posts cleanly as long as it ties to an open PO and passes approval.

Catching it requires a separate accessorial schedule maintained outside the ERP.

Accessorial charges, detention, liftgate, residential delivery, redelivery fees, are where freight invoices accumulate line items a shipper never explicitly agreed to. A 3PL's rate card typically lists which accessorials apply to which lane and at what rate. That rate card is a document, not a database Intacct reads.

Because Intacct's matching logic operates at the invoice-to-PO level rather than the line-item-to-contract-clause level, an accessorial charge that appears on the invoice simply adds to the total the system checks against the PO's authorized amount, if a PO-level dollar tolerance is even configured. A charge for a fee never contracted, or one billed at a marked-up rate, does not trigger a distinct flag because Intacct has no concept of 'accessorial not in scope' to flag against.

A. What a rate card comparison actually requires

Testing an accessorial charge means holding the carrier's or 3PL's rate card as structured reference data, lane by lane and accessorial by accessorial, and comparing each invoice line to it. That comparison has to happen outside Intacct's native object model, because Intacct has no accessorial-rate entity to populate.

Some AP teams build this in a spreadsheet keyed to vendor and lane. It works at low invoice volume and degrades as the number of carriers, lanes, and contract amendments grows, because every rate change has to be found and re-keyed by hand.

4. Does Intacct's dimension and reporting structure help catch drift after the fact?

Partially. Intacct's dimensions (entity, department, location, and custom dimensions like carrier or lane) let a controller run spend reports that group freight cost by carrier or lane, which is useful for spotting a cost trend worth investigating. But a dimension report shows totals and trends, not a line-by-line variance against contract terms, so it points toward a problem without identifying which invoice or which clause caused it.

A well-configured Intacct instance tags every freight invoice with a carrier dimension and a lane or location dimension. That makes it possible to build a report showing total freight spend by carrier over a period, or spend per lane trending up quarter over quarter. This is real value: it is the kind of signal that tells a controller something is worth investigating.

But the report answers 'is this carrier costing more' not 'is this carrier billing correctly.' A carrier can bill more because volume increased, because a legitimate rate increase took effect, or because a surcharge stopped being tested against its true index and started drifting upward. Intacct's reporting layer aggregates dollars; it does not decompose an invoice into base rate, surcharge, and accessorial components and test each independently. Finding the cause still requires going invoice by invoice against the contract, which is exactly the work the dimension report cannot do for you.

5. What should an AP team building freight controls in Intacct actually build first?

Start with a structured reference table for the contract terms Intacct will never hold: rate cards by lane, the fuel index and lag each carrier's surcharge is pegged to, and the accessorial list with contracted rates. Without that table, no amount of Intacct configuration, tighter tolerances, more approval steps, closer dimension tagging, tests an invoice against the number that actually matters: what the contract says it should cost.

The build order matters because each layer depends on the one before it. First, get the contract terms out of PDFs and into a structured table: carrier, lane, base rate, fuel index name and lag, accessorial list with rates and applicability conditions. Second, decide where the comparison runs: before the invoice posts to Intacct, as a pre-AP check, or after posting, as a periodic reconciliation against the general ledger export.

Third, set a threshold for what counts as a variance worth investigating versus rounding noise from unit conversion or partial shipments.

None of this replaces Intacct's native controls. PO matching, approval workflows, and duplicate detection still need to run, because they catch a different class of error: the wrong vendor, the wrong entity, the same invoice twice. The contract-term comparison catches a different class entirely: the right invoice, correctly approved, priced against the wrong number.

1. Structure the rate card: Convert each active carrier and 3PL contract into a lane-by-lane table with base rate, fuel index reference, and accessorial schedule.
2. Pick the comparison point: Decide whether the contract check runs before the invoice reaches Intacct's approval queue or as a post-posting reconciliation.
3. Set a variance threshold: Define what dollar or percentage gap triggers a review versus what is explained by rounding or partial shipment.
4. Route findings to an owner: Assign who resolves a flagged variance with the carrier, since detection without a resolution path just accumulates a list.

6. Is a bigger ERP module or a transportation management system the fix instead?

Not by itself. A transportation management system manages routing, load tendering, and carrier selection going forward; it is not built to retroactively test 12 to 18 months of invoices already paid against the contract terms in effect when they were billed. Closing that historical gap and building the forward test are two different jobs, and a TMS purchase alone answers only the second one.

A TMS strengthens the forward-looking side: it can enforce carrier selection rules and tender loads against pre-negotiated rates at the point of shipment. That is real prevention. But most freight drift a manufacturer finds sits in invoices already paid, sometimes 12 to 18 months of them, where a surcharge quietly stopped tracking its index or an accessorial crept in above its contracted rate.

A TMS implementation does not audit that historical spend. It also does not, on its own, replace the contract-term reference table described above; it needs the same structured rate and surcharge data to enforce rules going forward that a retrospective check needs to test invoices already paid. The two problems, recovering what already leaked and preventing what leaks next, call for different work, and buying forward-looking software first without knowing which contracts are already drifting means configuring it against rules nobody has verified yet.

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 Sage Intacct do three-way matching for freight invoices?

Yes. Intacct matches an invoice against its purchase order and, where configured, a receipt record, checking quantity and unit price within set tolerances. This confirms the invoice ties to an authorized purchase. It does not test whether the rate, fuel surcharge, or accessorial charge on the invoice matches the carrier contract's actual terms.

Can Intacct flag a fuel surcharge that no longer matches the index it's supposed to track?

No. Intacct posts the surcharge amount as billed on the invoice. It has no native connection to a fuel or freight price index and no calculation that checks the billed surcharge against what the contract's index and lag period would produce. That comparison has to happen outside the ERP, against the index itself.

What is the difference between PO matching and contract compliance for freight?

PO matching confirms an invoice ties to an authorized purchase order at an agreed price and quantity. Contract compliance tests whether that price is itself correct: whether the base rate, fuel surcharge, and accessorial charges match the carrier or 3PL contract's rate card. Intacct performs the first; it has no native mechanism for the second.

Do Intacct's custom dimensions help track freight spend by carrier?

Yes, if configured. A carrier or lane dimension lets a controller report total freight spend grouped by carrier or lane and spot cost trends worth investigating. It reports aggregated dollars, though, not line-by-line variance against contract terms, so it signals where to look without identifying the specific invoice or clause at fault.

Will adding a transportation management system fix Intacct's freight control gap?

A TMS strengthens forward-looking controls like carrier selection and load tendering against pre-negotiated rates. It does not retroactively test invoices already paid against the contracts in effect when they were billed, and it still needs a structured rate and surcharge reference table to enforce rules correctly going forward.

Can duplicate payment detection in Intacct catch freight overbilling?

Duplicate detection compares vendor ID and invoice number against invoices already booked, and it works reliably for that purpose. It has no bearing on whether a single, non-duplicate invoice is priced correctly. A carrier can overbill on a legitimate, non-duplicate invoice and duplicate detection will not flag it.

How should we structure a carrier rate card outside Intacct?

Build a table keyed by carrier and lane, listing base rate, the fuel index name and lag the surcharge references, and the accessorial schedule with contracted rates and applicability conditions. This structured reference is what any invoice-level comparison needs, since Intacct holds no equivalent object natively.

Is this a legal or contract-interpretation question we should route to counsel?

Testing an invoice against a rate card is an operational and financial control question, not a legal one, in most cases. But where a contract term itself is ambiguous or disputed with a carrier, that is a contractual matter. This is general information, not legal advice, and disputed contract language should go to counsel.

What size company should worry about this gap in Intacct?

The gap exists for any Intacct user regardless of size, since it is structural to the platform. Margin drift Diagnostics in this area are built for manufacturers above $100M in revenue, where freight spend volume makes manual, invoice-by-invoice contract checking impractical without a dedicated reference table and process.