Procure to Pay: The Standard Process, and Why Freight Breaks It

A procure-to-pay process built on purchase orders works reliably for office supplies, raw materials, and professional services. The PO is created, goods arrive, the invoice references the PO, and the 3-way match confirms everything aligns.

For freight, it doesn't.

• Carrier invoices don't reference a PO
• The rate authority is a contract, not an order
• The "goods receipt" is a delivery scan
• Accessorial charges that determine 10 to 15% of the total bill aren't ordered; they're applied after the fact

That's a different P2P problem.

‍

Key Takeaways

• The standard P2P process is built around a single assumption: every invoice references a purchase order. Freight invoices don't, and every step of the standard P2P workflow that depends on that assumption produces exceptions, backlogs, or unvalidated approvals when carrier invoices enter the queue.
• Freight is the highest-exception-rate AP category at most enterprises not because carriers bill incorrectly at higher rates, but because the matching logic built for PO-referenced supplier invoices has no mechanism for validating fuel surcharges, accessorials, and conditional fees against a carrier contract.
• A freight-native P2P workflow replaces the PO-centric model with a contract-centric one: the carrier contract is the rate authority, shipment execution data is the receipt record, and 4-way matching validates each invoice line before payment clears.
• The cost of the freight P2P gap is 1.5 to 2.5% of freight spend per year, amounts that pass through standard P2P matching unverified because the validation infrastructure wasn't built for how carrier invoices work.

What is procure to pay, and what does it assume about invoices?

Procure to pay (P2P) is the end-to-end business process for acquiring goods or services from need identified through payment completed, spanning requisition, purchase order creation, goods receipt, invoice matching, and disbursement.

The entire process is designed around a central assumption: every invoice references a purchase order, and every charge can be validated against it.

That assumption holds for most procurement categories:

• A manufacturer buying raw materials: the supplier invoices against the PO
• A company engaging a services vendor: the invoice references the engagement authorization
• Indirect goods purchases: the PO lines and invoice lines either match or they don't

Freight is different. A carrier invoice doesn't reference a PO. The rate authority is a contract negotiated in an RFP cycle six months ago. The charges include:

• Fuel surcharges indexed to a price that changes weekly
• Accessorial fees applied at the carrier's discretion
• Line items that can only be validated against a contract rate table and a shipment record

Standard P2P infrastructure wasn't designed for any of that.

What are the steps in the procure-to-pay process?

The standard procure-to-pay process moves through six stages: purchase requisition, purchase order creation, goods receipt, invoice receipt, 3-way matching, and payment. Each stage is designed for PO-referenced transactions.

Purchase requisition and PO creation

The P2P cycle begins when a business need is identified and a purchase requisition is raised. It moves through an approval workflow (budget check, category approval, supplier authorization) and becomes a purchase order when approved.

The PO documents:

• Agreed price
• Quantity
• Delivery terms
• Payment conditions

From that point, the supplier knows exactly what to deliver and what to bill.

For freight, this step doesn't exist in the same form. The need to move a shipment is operational, not a discrete procurement event. Carrier selection may have been completed in a quarterly RFP six months earlier. The shipment moves against a standing carrier contract, not a newly created PO.

Goods receipt and three-way matching

When a supplier delivers against a PO, the receiving team confirms the delivery: quantity received, condition, and match to the delivery order. The system creates a goods receipt record. When the invoice arrives, the P2P platform runs a 3-way match:

1. PO amount
2. Goods receipt quantity
3. Invoice amount

If all three align within tolerance, the invoice moves to payment.

For freight, the "goods receipt" is a delivery confirmation scan. It confirms the shipment arrived, but it doesn't confirm:

• The fuel surcharge tier
• The DIM weight calculation
• Whether a residential delivery fee was warranted

A carrier invoice can pass 3-way matching because the shipment happened and the base freight charge is within tolerance, while carrying $200 in accessorial overcharges that nothing in the 3-way match examined.

Invoice processing and payment

Invoices that pass matching move through AP coding and approval routing. This stage runs efficiently when the matching step did the hard validation work upstream.

When it didn't, as is typical for freight invoices, the AP review stage is where overcharges either get caught through manual scrutiny or clear to payment unreviewed.

Why is freight the hardest P2P category for enterprise teams?

Freight is the hardest P2P category because carrier invoices are non-PO transactions with rate complexity, format variability, and validation requirements that standard P2P matching infrastructure wasn't designed to handle.

Most enterprise P2P platforms handle direct and indirect goods procurement well. The exception rate on supplier invoices typically runs 15 to 25% on well-configured platforms. For freight invoices, that rate is often 40 to 60%.

Not because carriers invoice incorrectly at higher rates, but because the matching logic has no mechanism for:

Non-PO charge validation Fuel surcharges, accessorials, and port handling fees appear on carrier invoices without PO references. P2P platforms route them to exception queues by default because there's nothing to match against. The queue fills faster than AP teams can clear it, and the validation of whether each charge was contractually justified rarely happens.

Format heterogeneity A manufacturer with 20 active carriers receives invoices in EDI 210, carrier-specific PDFs, CSV exports, and portal downloads. The freight invoices that arrive in non-standard formats are the ones least likely to be validated and most likely to carry billing errors.

Rate validation requiring external data Confirming whether a fuel surcharge was applied at the correct tier requires:

• The carrier contract's surcharge schedule
• The fuel index for the week of shipment
• The shipment's departure date

None of those data points exist in the P2P platform. The validation is structurally impossible without connecting the invoice to three external data sources.

A missing match anchor Standard 3-way matching connects invoice to PO to receipt. Freight invoices have no PO. The match has one leg, the goods receipt, and it confirms only that the shipment happened, not that the charges for it were correct.

What does a freight-native procure-to-pay workflow look like?

A freight-native P2P workflow replaces the PO-centric model with a contract-centric one: the carrier contract serves as the rate authority, shipment execution data serves as the receipt record, and 4-way matching validates each invoice before payment clears.

Carrier sourcing and contract as rate authority

In freight P2P, the upstream equivalent of requisition and PO creation is the carrier sourcing cycle: RFP or tender, carrier evaluation, rate negotiation, and contract award.

The output isn't a PO. It's a carrier contract with:

• Lane rates
• Accessorial schedules
• Fuel surcharge formulas
• Service terms

Managing that contract as a live rate reference, not just a signed PDF on a shared drive, is a prerequisite for the validation steps that follow.

Freight execution and invoice receipt

When a shipment moves, the execution data needed for invoice validation is generated:

• Carrier assigned
• Departure date
• Origin and destination confirmed
• Weight and dimensions recorded
• Delivery address classification determined

That data lives in the TMS or carrier EDI system, not in the P2P platform.

When the invoice arrives (typically 14 to 30 days after shipment), a freight-capable AP layer ingests it in any format, normalizes the charge data, and connects each line item to the execution record from the shipment it covers.

Freight invoice validation and payment

The validation layer runs 4-way matching for each invoice line against:

Lines that pass all four checks clear to payment. Lines that fail generate a dispute with supporting evidence already compiled: contracted rate versus applied rate, the shipment record confirming the discrepancy, the surcharge schedule showing the correct tier.

The dispute routes to the carrier, not to an AP exception queue waiting for a human to investigate.

‍

How do enterprise teams close the freight P2P gap?

Enterprise teams close the freight P2P gap by running two parallel processing tracks within the same AP environment: the standard P2P workflow for supplier invoices and a freight-specific audit layer for carrier invoices.

The architecture doesn't replace existing P2P infrastructure. It runs alongside it:

• Supplier invoices continue through the P2P platform's standard matching, approval, and payment logic
• Carrier invoices enter the same AP environment but route through the freight validation track, which holds the carrier contract rates, surcharge schedules, and shipment execution data that standard P2P doesn't

The practical result:

• The P2P exception rate on supplier invoices holds at the platform's standard performance
• The freight exception rate drops, not because fewer billing errors exist, but because exceptions are handled by the validation layer rather than queued for manual review
• Overcharges that would have cleared AP on a manual review pass now fail the 4-way match, generate a dispute, and route to recovery

At 1.5 to 2.5% of freight spend recovered through systematic overcharge detection, an enterprise with $25M in annual freight spend recovers $375,000 to $625,000 per year in charges that were clearing the standard P2P process unvalidated.

Freehand's freight audit platform closes the gap by ingesting carrier invoices across EDI, PDF, and email, running 4-way matching against contracted rates and shipment data, and submitting dispute packets autonomously, adding the freight-capable track to your existing P2P environment without replacing it.

‍

Your P2P process works for your suppliers. Does it work for your carriers?

A P2P platform that handles supplier invoices well still has a gap when carrier invoices run on the same matching logic.

The difference isn't a configuration problem. It's a data problem: validating carrier invoices requires contract rates, surcharge schedules, and shipment execution data that standard P2P infrastructure doesn't hold.

Without those data sources in the matching layer, freight invoices either:

• Accumulate in exception queues
• Clear to payment without validation

Both have a cost.

At 1.5 to 2.5% of freight spend on a $25M freight portfolio:

• That's $375,000 to $625,000 per year clearing the P2P process unverified
• Amounts small enough per invoice to appear normal
• Large enough in aggregate to represent a controllable cost that isn't currently controlled

Freehand's freight audit platform adds the freight-capable validation track to your existing P2P environment, ingesting carrier invoices across EDI, PDF, and email, running 4-way matching against contracted rates and shipment data, and surfacing exceptions before payment clears.

‍

Frequently Asked Questions

What is procure to pay (P2P)?

The end-to-end process for acquiring goods or services from purchase need through supplier payment, covering requisition, PO creation, goods receipt, invoice matching, and disbursement. Designed around PO-referenced transactions, which is why freight invoices create structural challenges in standard P2P implementations.

Why do freight invoices create problems in P2P systems?

Freight invoices don't reference a purchase order, arrive in multiple formats, and carry accessorial charges requiring carrier contract and shipment data to validate. The result is high exception rates, manual review backlogs, and billing errors that clear AP undetected because the validation data isn't in the platform.

What is 3-way matching in procure-to-pay?

Validates a supplier invoice against the purchase order and the goods receipt record. For freight invoices, 3-way matching only verifies the base freight amount. It doesn't validate fuel surcharges, accessorials, or conditional fees that require carrier contract data to verify.

What is 4-way matching in freight P2P?

Validates each invoice line against the carrier contract rate, the fuel surcharge schedule for the week of shipment, confirmed shipment execution data, and the authorizing purchase order. Each data source closes a validation gap that 3-way matching misses.

What is the difference between procure-to-pay and source-to-pay?

Procure-to-pay covers the transactional phase from PO creation through payment. Source-to-pay extends upstream to include supplier identification, RFP, and contract negotiation. For freight, source-to-pay encompasses the carrier RFP and contract award; procure-to-pay covers shipment execution through invoice validation and payment.

How much does the freight P2P gap cost enterprise teams?

At 1.5 to 2.5% of freight spend in billing errors passing through standard P2P unvalidated, an enterprise with $25M in annual freight spend loses $375,000 to $625,000 per year. Too small per invoice to flag manually, too systematic to miss with 4-way matching.

What does a freight-native P2P workflow require?

Three data sources that standard P2P doesn't hold: the carrier contract as a queryable rate reference, shipment execution data from the TMS or carrier EDI, and a normalization layer that handles carrier invoice format variability across EDI, PDF, and other formats. Without all three, 4-way matching isn't possible.

‍

‍