What is the procure-to-pay process?

Procure-to-pay (P2P) is the full cycle from identifying a need to actually paying for it: a requisition (internal request), a purchase order (formal authorization sent to a supplier) once approved, delivery of the goods or services, an invoice, matching, and finally payment. Each step exists to keep the business from paying for something it never actually ordered or received.

By Zuny Fester, Head of Operations and Marketing

Reviewed by Zuny Fester

Published September 14, 2026Last reviewed September 14, 2026Editorial policy

Part of the accounts payable and invoice processing guide.

Step 1	Requisition — an internal request for goods or services, not yet sent to a vendor
Step 2	Purchase order — a formal authorization, created once the requisition is approved
Step 3	Receipt — the goods or services actually arrive
Step 4	Invoice — the vendor bills for what was delivered
Step 5	Payment — the invoice is matched and paid, closing the cycle

Where a requisition and a purchase order actually differ

The two terms get used loosely, but Oracle's own procurement documentation draws the line clearly: a requisition is a request for goods or services — internal, not yet binding — and "if approved, a purchase order is created to fulfill the requisition." The purchase order is what actually goes to a supplier as "a formal authorization to purchase goods or services." A requisition can be rejected or changed with no external consequence; a purchase order, once sent, is a commitment.

What happens between the order and the payment

Oracle's own procure-to-pay process documentation frames the remaining steps as: placing the order, receiving confirmation the order is being processed, the shipment and invoice arriving, and finally payment. In practice, that middle stretch — order sent, goods or services actually delivered, invoice received — is where a two-way or three-way match happens, comparing what was ordered against what arrived and what's being billed before anything gets paid.

Why the sequence matters, not just the steps

The order of P2P's steps is itself the control: nothing should be paid for that wasn't first requested, authorized, and actually delivered. A workflow that lets an invoice trigger payment without a preceding purchase order and receipt skips the two checkpoints that catch a wrong price, an undelivered order, or an invoice for something nobody actually requested.

Next step

Map the finance workflow with the most exposure and prove the automation path.

Bring the invoice, contract, payment reconciliation, or customer finance workflow you have to defend at audit. Loopfour can map the trigger, controls, integrations, and approval loop.

Book a workflow review

Checklist

The five P2P checkpoints, and what each one catches

Requisition approved — catches unauthorized or unnecessary spend before a vendor is even involved
Purchase order issued — catches price or quantity discrepancies against what was actually approved
Goods or services received — catches an invoice for something that never actually arrived
Invoice matched — catches a billed amount that doesn't match the order or the receipt
Payment released — the only step that should ever move cash, and only once the prior four hold

Frequently Asked Questions

No — a requisition is an internal request. Nothing is communicated to a vendor and no commitment exists until it's approved and converted into a purchase order, which is what actually goes to the supplier.

It shouldn't happen in a well-controlled process, but it does in practice — a vendor invoicing ahead of a formal PO, or a rush order handled verbally first. When it does, the invoice should still be matched against a retroactively created PO and confirmed receipt before payment, not paid on the invoice alone.

Not necessarily — many organizations set a dollar threshold below which a simplified process (a purchasing card, a pre-approved vendor) skips formal requisition/PO steps. The full cycle is reserved for spend large or risky enough to justify the control overhead.

Sources

Topic

AP & Invoice Processing

Accounts payable and invoice processing is the set of steps a vendor bill goes through between arriving at a company and turning into a payment: capturing what the vendor sent, checking it against wha…

Diagnostic

What causes a three-way match failure between the PO, receipt, and invoice?

A three-way match compares the PO, the receipt (what was actually delivered), and the invoice on quantity, price, and charges. A failure means one of those three disagrees beyond tolerance — usually because the invoice bills a quantity that isn't fully receipted yet, the unit price differs from the PO, or the invoice adds a charge, like freight, the PO never included.

How-to

How do I connect QuickBooks vendor bills to a Loopfour workflow?

Loopfour's QuickBooks integration creates a bill with a single, unconditional API call — there's no upsert-by-document-number the way there is for invoices, so a blind retry after a timeout creates a second bill. Loopfour can also create the vendor first if it doesn't already exist; a bill doesn't require a pre-existing vendor record.

Definition

What is accounts payable?

Accounts payable is the aggregate amount a company owes suppliers for goods or services purchased on credit — a short-term liability on the balance sheet. The same term also names the department or function that processes vendor invoices and issues payment, so "AP" can mean either the liability itself or the team that manages it, depending on context.