Procure-to-pay

Procure-to-pay is the full cycle from purchase request through invoice payment, and where its matching controls stop checking against contract terms.

Twitter LinkedIn WhatsApp
Ask AI: ChatGPT Claude Gemini Grok
Procure-to-pay

Procure-to-pay is the full cycle a company runs from requesting a purchase through paying the vendor's invoice: requisition, purchase order, receipt, invoice matching, and payment. Manufacturers above $100M in revenue run this cycle across dozens of service vendor categories at once, often on different rules for each contract, which is exactly where the process stops matching the paper behind it.

1. What are the stages of the procure-to-pay cycle?

Procure-to-pay runs through five stages: a requisition identifies a need, a purchase order commits the company to a price and quantity, the vendor delivers and a receipt confirms it, the invoice arrives and is matched against the PO and receipt, and payment is released. Each stage produces a record, and those records are what three-way matching compares before an invoice is approved for payment.

The cycle is designed to prevent paying for something that was never ordered or never received.

  1. Requisition: An internal request identifies what is needed and why.
  2. Purchase order: A PO commits the company to a vendor, price, and quantity.
  3. Receipt: Goods or services are confirmed as delivered.
  4. Invoice match: The invoice is checked against the PO and receipt.
  5. Payment: Funds are released once the match clears.

2. What does three-way matching actually check?

Three-way matching compares the invoice to the purchase order and the receipt: does the quantity billed match what was ordered and received, and does the price match what the PO recorded. It confirms internal consistency across documents the P2P system itself generated. It does not test whether the PO's price was correct against the contract, or whether a surcharge, tier, or rebate clause applies.

If the PO carried the wrong rate, matching confirms the invoice against a wrong number.

3. Why does procure-to-pay miss contract-level drift?

The contract terms that govern price, a rate card, a volume tier, an NTE cap, a rebate clause, typically live in a signed PDF outside the ERP, not as structured data the P2P system can check. Procure-to-pay was built to reconcile internal documents against each other, not to interpret contract language. An invoice can match its PO and receipt perfectly while still charging outside the contract's own terms.

This is why margin drift accumulates inside a P2P system that appears to be functioning normally.

See margin drift for the full definition of that gap.

4. How is contract-level drift found once it is inside P2P?

Finding it requires matching invoices directly against the contract, category by category: rate card, volume tier, minimum commitment, NTE cap, index escalation, and rebate terms, rather than against the PO alone. That work spans categories like freight, contract labor, and maintenance, each with its own contract structure and its own way the invoiced amount can diverge from what was signed.

A diagnostic performs this contract-to-invoice match as a separate pass from routine AP review.

For the wider pattern this sits inside, start with the margin drift guide. See also off-contract resources: people billed outside the agreement and unapplied volume rebates in staffing agreements.

5. Frequently Asked Questions (People Also Ask)

Is procure-to-pay the same as accounts payable?

No. Accounts payable is one stage inside procure-to-pay, the invoice-to-payment part. Procure-to-pay also includes requisitioning and purchase ordering, the steps that happen before an invoice ever arrives.

Does three-way matching catch overbilling?

Three-way matching catches billing that disagrees with the purchase order or receipt, such as wrong quantities. It does not catch a PO issued at an incorrect rate, or a surcharge applied outside the contract's own conditions.

Where do contract terms live if not in the P2P system?

Rate cards, volume tiers, rebate clauses, and surcharge schedules are typically signed as separate PDF contracts and are not entered as structured, checkable data inside the ERP or P2P platform.

What is a rate card in the context of procure-to-pay?

A rate card is the contract's schedule of agreed unit prices by service or item. Procure-to-pay checks an invoice against the purchase order price, not directly against the rate card unless that step is added separately.

Can procure-to-pay software be configured to check contract terms?

Some P2P systems can be configured with additional pricing rules, but this requires someone to first extract the contract's rate card, tiers, and caps into structured form. The software enforces whatever rules it is given, not the contract itself.

What is a volume tier and why does P2P miss it?

A volume tier is a contract clause where the unit price changes once purchase volume crosses a threshold. P2P matching checks invoice quantity against the PO, not whether the tier threshold was crossed and the lower price applied.

Why does an invoice that passes P2P matching still overcharge?

Passing match confirms the invoice agrees with the PO and receipt. It says nothing about whether the PO's price agreed with the contract in the first place.

1. What are the stages of the procure-to-pay cycle?

Procure-to-pay runs through five stages: a requisition identifies a need, a purchase order commits the company to a price and quantity, the vendor delivers and a receipt confirms it, the invoice arrives and is matched against the PO and receipt, and payment is released. Each stage produces a record, and those records are what three-way matching compares before an invoice is approved for payment. The cycle is designed to prevent paying for something that was never ordered or never received. 1. Requisition: An internal request identifies what is needed and why. 2. Purchase order: A PO commits the company to a vendor, price, and quantity. 3. Receipt: Goods or services are confirmed as delivered. 4. Invoice match: The invoice is checked against the PO and receipt. 5. Payment: Funds are released once the match clears.

2. What does three-way matching actually check?

Three-way matching compares the invoice to the purchase order and the receipt: does the quantity billed match what was ordered and received, and does the price match what the PO recorded. It confirms internal consistency across documents the P2P system itself generated. It does not test whether the PO's price was correct against the contract, or whether a surcharge, tier, or rebate clause applies. If the PO carried the wrong rate, matching confirms the invoice against a wrong number.

3. Why does procure-to-pay miss contract-level drift?

The contract terms that govern price, a rate card, a volume tier, an NTE cap, a rebate clause, typically live in a signed PDF outside the ERP, not as structured data the P2P system can check. Procure-to-pay was built to reconcile internal documents against each other, not to interpret contract language. An invoice can match its PO and receipt perfectly while still charging outside the contract's own terms. This is why [margin drift](/guides/margin-drift-vs-legitimate-price-increases-how-to-tell-them) accumulates inside a P2P system that appears to be functioning normally. See margin drift for the full definition of that gap.

4. How is contract-level drift found once it is inside P2P?

Finding it requires matching invoices directly against the contract, category by category: rate card, volume tier, minimum commitment, NTE cap, index escalation, and rebate terms, rather than against the PO alone. That work spans categories like freight, contract labor, and maintenance, each with its own contract structure and its own way the invoiced amount can diverge from what was signed. A diagnostic performs this contract-to-invoice match as a separate pass from routine AP review. For the wider pattern this sits inside, start with the [margin drift](/insights/margin-drift-spend-leakage-guide) guide. See also [off-contract resources: people billed outside the agreement](/guides/off-contract-resources-people-billed-outside-the-agreement) and [unapplied volume rebates in staffing agreements](/guides/unapplied-volume-rebates-in-staffing-agreements).

Questions & Answers

Is procure-to-pay the same as accounts payable?

No. Accounts payable is one stage inside procure-to-pay, the invoice-to-payment part. Procure-to-pay also includes requisitioning and purchase ordering, the steps that happen before an invoice ever arrives.

Does three-way matching catch overbilling?

Three-way matching catches billing that disagrees with the purchase order or receipt, such as wrong quantities. It does not catch a PO issued at an incorrect rate, or a surcharge applied outside the contract's own conditions.

Where do contract terms live if not in the P2P system?

Rate cards, volume tiers, rebate clauses, and surcharge schedules are typically signed as separate PDF contracts and are not entered as structured, checkable data inside the ERP or P2P platform.

What is a rate card in the context of procure-to-pay?

A rate card is the contract's schedule of agreed unit prices by service or item. Procure-to-pay checks an invoice against the purchase order price, not directly against the rate card unless that step is added separately.

Can procure-to-pay software be configured to check contract terms?

Some P2P systems can be configured with additional pricing rules, but this requires someone to first extract the contract's rate card, tiers, and caps into structured form. The software enforces whatever rules it is given, not the contract itself.

Margin Drift Resources