Procure-to-Pay Process: The 7 Steps Explained
Jul 11, 2026
Jul 11, 2026
Convert a purchase order to Excel, CSV, or JSON
Submit your purchase orders
Drop documents here, or click to file
Up to 50 files per batch
Uploading...
The procure-to-pay process, often shortened to P2P, is the end-to-end cycle a business uses to buy goods or services and pay for them. It runs through seven steps: identify the need, raise and approve a requisition, issue a purchase order, receive the goods or services, match and approve the supplier invoice, pay the supplier, and record the transaction. Its job is to connect procurement and accounts payable so nothing is bought without approval and nothing is paid without proof.
Last updated July 2026.
P2P matters because it is where control and cash meet. A tight process stops maverick spend, catches duplicate and wrong invoices before they are paid, and gives finance a clean record of what was ordered, received, and owed. A loose one leaks money in small, repeated ways. The tool above sits inside this cycle: it reads the purchase order and returns the vendor, line items, and totals as clean data, so the PO does not have to be retyped into your ERP to move the process forward.
Every organization words these differently, but the flow is consistent. Each step hands a document and an approval to the next.
| Step | What happens | Document |
|---|---|---|
| 1. Identify the need | A department decides it needs goods or a service | Internal request |
| 2. Requisition and approval | A purchase requisition is raised and approved against budget | Purchase requisition |
| 3. Purchase order | An approved requisition becomes a PO sent to the supplier | Purchase order |
| 4. Goods receipt | The supplier delivers; receiving records what arrived | Goods receipt note |
| 5. Invoice and match | The supplier invoices; AP runs a 3-way match | Supplier invoice |
| 6. Payment | A matched, approved invoice is paid on terms | Remittance |
| 7. Record and reconcile | The transaction is posted and closed for audit | Ledger entry |
Someone in the business identifies that a product or service is required, from office supplies to a software subscription to raw materials for production. This is where spend either follows policy or goes rogue, so mature P2P starts by pointing every need at an approved catalog or a requisition rather than a corporate card.
The need becomes a formal purchase requisition, an internal request that names the item, quantity, estimated cost, and budget line. It is routed for approval before any commitment is made to a supplier. The requisition is the control point: approve it and money can be spent, reject it and nothing leaves the building.
An approved requisition is converted into a purchase order and sent to the supplier. The PO lists the items, quantities, agreed prices, and terms, and once the supplier accepts it, it is a binding commitment to buy. This is the first document that leaves the company.
The supplier delivers, and receiving records what actually arrived against the PO, usually as a goods receipt note. This step exists so that payment can later be tied to proof of delivery, not just to an invoice. Short shipments and damaged goods are caught here.
The supplier sends an invoice, and accounts payable runs a three-way match, comparing the invoice to the purchase order and the goods receipt. If the quantities and prices agree across all three, the invoice is cleared for payment. If they do not, it is held as an exception until the gap is resolved. This is where most overpayments are stopped.
A matched, approved invoice is scheduled and paid according to the agreed terms, often Net 30. Paying on time protects supplier relationships and any early-payment discounts; paying too early gives up working capital. The full flow from PO to payment is covered in the purchase order to invoice process.
The transaction is posted to the ledger, closed against the PO, and kept for audit. A clean record means the next auditor, or the next budget review, can trace exactly what was ordered, received, and paid, with the documents to back it up.
These terms overlap and get used loosely. Purchase-to-pay is a synonym for procure-to-pay, the same requisition-to-payment cycle. Source-to-pay is broader: it adds the upstream sourcing work, supplier discovery, negotiation, and contracting, in front of the P2P cycle. Put simply, source-to-pay decides who you buy from and on what terms; procure-to-pay executes and pays for the buying.
Automation targets the manual, repetitive parts of the cycle: routing requisitions for approval, generating POs, capturing invoice data, and running the three-way match. The single most manual point is data entry, keying POs and invoices off PDFs into the ERP. Capturing that document data automatically, as the tool above does for purchase orders and an invoice OCR tool does for the invoice side, removes the retyping that slows every downstream step and seeds the errors the match later has to catch.
The procure-to-pay process is the end-to-end cycle for buying goods or services and paying for them. It runs from identifying a need, through raising a requisition, issuing a purchase order, receiving the goods, matching and approving the supplier invoice, to paying the supplier and recording the transaction. It links procurement and accounts payable so purchases are controlled and payments are backed by proof.
There are seven core steps: identify the need, raise and approve a purchase requisition, issue a purchase order to the supplier, receive the goods or services, match and approve the supplier invoice with a three-way match, pay the supplier on terms, and record and reconcile the transaction. Each step passes a document and an approval to the next, which is what keeps the cycle auditable.
There is no real difference. Purchase-to-pay and procure-to-pay are two names for the same requisition-to-payment cycle. Both cover raising a requisition, issuing a PO, receiving goods, matching the invoice, and paying the supplier. Some organizations prefer one label, but they describe the identical end-to-end process.
Source-to-pay is broader than procure-to-pay. It adds the upstream sourcing activities, finding suppliers, running RFPs, negotiating, and signing contracts, in front of the buying cycle. Procure-to-pay picks up from an approved need and executes it: requisition, PO, receipt, invoice match, and payment. Source-to-pay decides who and on what terms; procure-to-pay does the buying and paying.
It is where spending is controlled and cash goes out, so a tight process directly protects margin. Clear steps stop unapproved purchases, the three-way match catches duplicate and incorrect invoices before payment, and a clean record makes audits and budget reviews straightforward. A weak P2P process leaks money through small, repeated errors and makes it hard to know what the business actually owes.
Automation handles the repetitive steps: routing requisition approvals, generating purchase orders, capturing PO and invoice data from documents, and running the three-way match against the PO and goods receipt. The biggest manual bottleneck is data entry off PDFs, so automatically extracting purchase order and invoice data removes the retyping that slows the cycle and introduces the errors the match later has to find.
For the pieces of this cycle in depth, see the purchase requisition process, the purchase order process and workflow, and three-way matching in accounts payable. To remove the PO data entry that slows the cycle, see automated purchase order data entry.
PurchaseOrders reads purchase orders and returns structured data. It does not raise requisitions, route approvals, perform the three-way match, or pay suppliers. Those stay in your procurement and AP systems, working from PO data that did not have to be typed in first.