# Procure-to-Pay Process: The 7 Steps Explained > The procure-to-pay process runs from purchase requisition to payment. See all 7 steps, the EDI documents behind each, and where three-way match fits. Procure-to-pay is the buy-side process that runs from purchase requisition through to supplier payment. The seven steps are requisition, sourcing, purchase order, order acknowledgment, goods receipt, invoice, and payment. A three-way match between the PO, receipt, and invoice clears each payable before cash goes out the door. **The procure-to-pay process covers everything from an employee requesting an item to your finance team paying the supplier, and it runs on documents at every step: a requisition, a purchase order, an order acknowledgment, a ship notice, a goods receipt, an invoice, and a payment.** If you sit on the selling side, this is the mirror image of your own [order-to-cash cycle](/blog/order-to-cash-automation). Your customer's procure-to-pay is your order-to-cash. The same documents flow between you, just labeled from opposite ends of the transaction. Picture a $9,000 invoice sitting blocked in AP for three weeks. The PO was keyed from an emailed quote, the warehouse never posted the receipt, and the supplier is now calling about payment. No single step in that story failed. Every failure lives in a handoff between steps: a requisition waiting in an inbox, an invoice nobody can match to a receipt, a PO price that drifted from the quote. Each gap adds days and invites error. This guide walks the full P2P cycle step by step, names the EDI transaction behind each one, and shows where the three-way match protects your cash. Key reference points on the process: - APQC's [Process Classification Framework (PCF)](https://www.apqc.org/process-frameworks) places procurement under category 4.2, "Manage Sourcing and Procurement," a free cross-industry model you can benchmark against - The [X12 transaction set catalog](https://x12.org/products/transaction-sets) defines the electronic documents (850, 855, 856, 810, 820) that carry each P2P step between trading partners ## What Is Procure-to-Pay? **Procure-to-pay (P2P) is the end-to-end business process for buying goods and services, from the internal request through to paying the supplier.** It spans procurement and accounts payable, two functions that historically lived in separate systems and separate teams. When they operate as one connected flow, spend stays controlled and invoices get paid on time. P2P is distinct from source-to-pay. Procure-to-pay starts at the requisition, the point where someone has already decided what to buy. Source-to-pay wraps around it and adds the upstream work: market analysis, RFPs, supplier evaluation, negotiation, and contract management. Put simply, source-to-pay decides who you buy from and on what terms. Procure-to-pay executes the buying against those terms. The distinction matters when you scope a project. Automating procure-to-pay tightens requisition approvals, PO issuance, and invoice matching. Source-to-pay reaches into strategic sourcing and supplier relationship management, a bigger effort with a different owner. ## The 7 Steps of the Procure-to-Pay Process Each step produces a document, and each document feeds the next. Break the chain and the whole cycle stalls. 1. **Purchase requisition.** An employee or department raises an internal request to buy something. This is intent, not a commitment. It routes through approval before anything reaches a supplier. See our guide to [what a purchase requisition is and how it differs from a PO](/blog/purchase-requisition) for the full breakdown. 2. **Sourcing and quote (RFQ).** For non-catalog or high-value items, buyers request quotes from one or more suppliers. The supplier returns a price and terms. For repeat purchases against an existing contract or [blanket purchase order](/blog/blanket-purchase-order), this step is already settled. 3. **Purchase order.** Once the requisition is approved and a supplier chosen, procurement issues a purchase order. The PO is the external, legally binding document sent to the supplier. In EDI terms this is the [EDI 850 purchase order](/guides/edi/850-purchase-order). 4. **Order acknowledgment.** The supplier confirms they can fulfill the order at the stated price, quantity, and date, or proposes changes. This is the [EDI 855 purchase order acknowledgment](/guides/edi/855-purchase-order-acknowledgment). An 855 that comes back with a different price or ship date is your earliest warning of a downstream invoice mismatch. 5. **Goods receipt.** The supplier ships, often sending an advance ship notice (the [EDI 856 ASN](/guides/edi/856-ship-notice)) ahead of the truck. When the goods arrive, receiving logs what actually showed up against what the PO said. This receipt becomes one of the three legs of the match. 6. **Supplier invoice.** The supplier bills you, typically via an [EDI 810 invoice](/guides/edi/810-invoice) or a PDF sent to your AP inbox. The invoice states what you owe, referencing the original PO number. 7. **Payment and remittance.** After the invoice clears matching, AP schedules payment on terms and sends remittance detail so the supplier can apply the cash. Electronic payment and remittance travel as the [EDI 820 payment order](/guides/edi/820-payment-order). ## Where the Three-Way Match Fits **Before any invoice gets paid, most organizations run a three-way match: the purchase order, the goods receipt, and the supplier invoice all have to agree on quantity and price within tolerance.** This is the control that stops you from paying for goods you never received or paying more than you agreed. Here is the logic. The PO says you ordered 40 drums of degreaser at $85. The receipt confirms 40 drums arrived. The invoice bills 40 drums at $85. All three agree, so the payable posts and payment is scheduled. If the invoice bills 48 drums, or bills at $92, the match fails and the invoice is blocked for review before a dollar moves. For services or anything with no physical receipt, buyers fall back to a two-way match: PO against invoice only. Our deep dive on [how three-way match works, including 2-way and 4-way variants](/blog/three-way-match) covers the tolerance mechanics and the ERP setup behind it. The match is the single most valuable control in the whole cycle. Skip it and you open the door to duplicate invoices, price creep, and outright invoice fraud. ## P2P vs Source-to-Pay vs Order-to-Cash These three terms get used loosely. They describe different scopes and different sides of the deal. | Process | Scope | Perspective | |---|---|---| | **Procure-to-pay (P2P)** | Requisition through payment | Buyer | | **Source-to-pay (S2P)** | Sourcing and contracting, plus all of P2P | Buyer | | **Order-to-cash (O2C)** | Order receipt through cash collection | Seller | Procure-to-pay and order-to-cash are two views of the same transaction. When your customer issues a PO, that is step three of their P2P and step one of your O2C. Their goods receipt drives their three-way match, which decides whether your invoice gets paid on time. Understanding both sides helps you head off the disputes that stretch your DSO. ## How Automation Removes the Handoffs Manual P2P is a relay race of email attachments and rekeying. A requisition gets approved by reply-all. A buyer types the PO into the ERP. Receiving marks a paper packing slip. AP keys the invoice from a PDF. Each rekey is a chance to introduce the mismatch that later blocks payment. Connected P2P closes those gaps. Requisitions route through defined approval rules instead of inboxes. Approved requisitions convert to POs without retyping. On the receiving side, [ERP integration](/erp-integration) posts goods receipts against the open PO automatically. When the supplier invoice arrives, the system runs the three-way match and only routes exceptions to a human. For the inbound documents that still arrive as PDFs and emails from suppliers who are not EDI-capable, [AI-powered order automation](/ai-order-automation) extracts the line items and matches them to the PO, so your AP team is not keying invoices by hand. If you exchange EDI with trading partners, you can check any 850, 855, or 810 file against the spec with our [free EDI Inspector](/edi-inspector) before it causes a matching failure. And if you are weighing tools to run this whole chain, our guide to [procure-to-pay software](/blog/procure-to-pay-software) compares suites, point solutions, and ERP-native modules. The payoff is a shorter cycle with fewer blocked invoices, captured early-payment discounts, and an audit trail that ties every payment back to an approved requisition. ## Procure-to-Pay KPIs and Benchmarks **Practitioners track P2P health with a small set of metrics, and the commonly cited industry ranges give a rough sense of where you stand.** Treat these as directional, not precise. Published figures vary with what gets counted, so your own trend over time matters more than any single number. For quartile data by industry and revenue band, [APQC's process benchmarking](https://www.apqc.org/process-frameworks) is the standard source. | KPI | What it measures | Commonly cited range | |---|---|---| | Cost per invoice | Fully loaded cost to process one supplier invoice | Roughly $10 to $15 fully manual; $2 to $4 automated | | Cost per PO | Cost to create and issue one purchase order | Commonly cited between $50 and $150 | | PO cycle time | Requisition approval to PO issued | Hours when automated; days when manual | | Invoice cycle time | Invoice receipt to payment approval | Days when automated; weeks when manual | | Touchless rate | Share of invoices processed with zero human touches | Varies widely; near zero in manual shops | | First-pass match rate | Share of invoices that clear the three-way match on the first try | Low rates point to PO or receipt data problems, not AP problems | | Days payable outstanding (DPO) | Average days from invoice receipt to payment | Driven by negotiated terms as much as process speed | One caution on DPO: it is a cash strategy metric as much as a process metric. A high DPO built from blocked invoices is a problem. The same DPO built from negotiated terms is a win. Look at the match rate and cycle time alongside it before drawing conclusions. ## Frequently Asked Questions ### What is the difference between procure-to-pay and source-to-pay? Procure-to-pay starts at the purchase requisition and runs through supplier payment. Source-to-pay adds the upstream sourcing work in front of it: market analysis, RFPs, supplier selection, negotiation, and contract management. Source-to-pay decides who you buy from and on what terms. Procure-to-pay executes the buying. ### Which P2P step should you automate first? Invoice matching. It carries the most manual keying and the most financial risk, since duplicate payments, price creep, and unrecorded receipts all surface there. Get invoices into structured data, match them against POs and receipts automatically, and route only exceptions to a person. Requisition approval routing is a close second: it is cheap to set up and stops maverick spend at the source. ### Which EDI documents map to the P2P process? The buyer issues an EDI 850 purchase order. The supplier returns an EDI 855 acknowledgment and an EDI 856 ship notice. The supplier then bills with an EDI 810 invoice, and the buyer remits with an EDI 820 payment order. These transactions carry the same information as the paper equivalents, just in structured electronic form. ### Is procure-to-pay the same as accounts payable? No. Accounts payable is the final stretch of procure-to-pay, covering invoice receipt, matching, and payment. Procure-to-pay is the wider process that also includes requisitioning, sourcing, purchase orders, and receiving. AP automation is a subset of procure-to-pay automation. ### How does procure-to-pay relate to order-to-cash? They are the same transaction seen from opposite sides. Your procure-to-pay is your supplier's order-to-cash. When you issue a purchase order, that is your third P2P step and your supplier's first O2C step. The documents that flow between the two processes are identical, only the labels differ.