Procure to Pay Process

Procure to pay is the end-to-end path a purchase takes inside a business, from the moment somebody realizes they need something to the moment the supplier is paid and the transaction is recorded. It joins two departments that often barely speak to each other, procurement and accounts payable, and most of the pain in the middle comes from the handoff between them. This guide explains what procure to pay is, walks the full cycle step by step, sorts out how it differs from source to pay and from accounts payable, and shows where automation actually pays for itself. Written for US finance, AP, and procurement teams.

What is procure to pay?

Procure to pay, often shortened to P2P, is the complete business process of buying goods or services and paying for them. It runs from identifying a need, through requisition, approval, purchase order, and receipt of the goods, to invoice processing and vendor payment. The name describes the span: it starts at procurement and ends at payment, with the accounting record as the closing act.

The point of treating it as one process, rather than as a procurement process bolted onto an AP process, is control. When requisitions, purchase orders, receipts, and invoices all live in the same chain, you can prove that every dollar you paid was requested by someone with authority, ordered at an agreed price, actually delivered, and billed once. Break the chain anywhere and you get the classic failures: maverick spending, duplicate payments, and invoices nobody can approve because nobody remembers ordering the thing.

What is the procure to pay process?

The procure to pay process is the sequence of steps and controls that carry a purchase from request to payment. In most US companies it covers need identification, requisition and approval, purchase order issue, goods or service receipt, invoice receipt, invoice matching and approval, payment, and finally recording and reporting. Each step produces a document that the next step checks against.

That document trail is the process. A requisition proves someone asked. A purchase order proves what was agreed and at what price. A goods receipt proves it arrived. An invoice claims payment is due. The match between the last three is the control that decides whether money moves. Everything else, the software, the workflows, the approval matrices, exists to make that chain fast and hard to fake.

What are the steps in the procure to pay cycle?

The procure to pay cycle has eight core steps: identify the need, raise and approve a requisition, issue a purchase order, receive the goods or services, receive the supplier invoice, match the invoice against the PO and receipt, approve and schedule payment, then pay the vendor and record the transaction. Larger organizations add supplier selection and contract steps at the front.

Here is what each step actually involves.

1. Need identification. A team realizes it needs laptops, freight, legal hours, or raw material. In a mature process this is checked against a budget before anything else happens, because the cheapest purchase to control is the one that never gets made.

2. Requisition and approval. The requester submits a purchase requisition describing what they want, how much, and why. It routes to a budget owner. This is the first and most valuable control in the whole cycle, since it stops unnecessary spend before a commitment exists.

3. Purchase order issued. Procurement converts the approved requisition into a purchase order and sends it to the supplier. The PO is a binding offer that fixes quantity, price, and terms. Once the supplier accepts, you have an auditable record of what you agreed to pay, which is what makes invoice checking possible later. Extracting and tracking those PO fields cleanly matters, which is why purchase order data extraction is a real workflow of its own.

4. Goods or service receipt. The order arrives and someone records what was actually received. Short shipments, damaged units, and partial deliveries get noted here. Skipping this step is why so many companies pay for things that never showed up.

5. Invoice received. The supplier bills you, usually as a PDF by email. This is the moment the process crosses from procurement into accounts payable, and it is where most of the manual labor lives, because the invoice arrives as a document rather than as data.

6. Invoice matching and approval. AP compares the invoice against the purchase order and the goods receipt. If quantities and prices agree within tolerance, it passes. If not, it becomes an exception someone has to resolve. Our explainer on three-way matching covers exactly how this check works and where the tolerances sit.

7. Payment. The approved invoice is scheduled and paid by ACH, check, card, or wire, according to the payment terms. Well-run teams time this to capture early payment discounts without paying anyone sooner than they must.

8. Record and report. The payment posts to the general ledger, the payable clears, and the data feeds accruals, cash forecasting, and spend analysis. The accounts payable process covers this back half in more detail.

Is procure to pay the same as accounts payable?

No. Accounts payable is one part of procure to pay, not a synonym for it. Procure to pay spans the entire cycle from need identification and purchasing through to payment. Accounts payable covers only the back half: receiving the supplier invoice, matching and approving it, paying it, and recording it. Every AP task sits inside P2P, but P2P also owns requisitions, purchase orders, and receiving.

The distinction matters because it tells you where a problem really lives. If AP is drowning in invoice exceptions, the root cause is usually upstream: purchase orders raised after the fact, receipts never recorded, prices agreed verbally. Fixing that inside AP is treating a symptom. The teams that get invoice exception rates down do it by tightening requisition and receiving discipline, then letting the match do its job.

What is P2P in procure to pay?

P2P is simply the abbreviation for procure to pay. You will also see it written as purchase to pay, and occasionally as PTP. All three refer to the same end-to-end cycle from requisition to vendor payment. Be careful in technical contexts, where P2P more commonly means peer to peer, an unrelated concept.

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

Source to pay is broader. It includes everything in procure to pay and adds the sourcing activities that come before any purchase is made: identifying suppliers, running a request for proposal, negotiating, and contracting. Procure to pay starts once a supplier and price already exist and someone needs to buy something.

The same logic separates procure to pay from accounts payable. Each process is a subset of the one before it.

Who is responsible for the procure to pay process?

Ownership is shared, which is why P2P breaks so often. Procurement owns requisitions, supplier relationships, and purchase orders. Operations or the receiving team records goods receipts. Accounts payable owns invoice processing, matching, and payment. Finance leadership, usually the controller or CFO, owns the process end to end and the controls that hold it together.

In practice, the handoffs are where the value leaks. A purchase order raised without a budget check, or a delivery signed for but never entered into the system, creates work in AP weeks later, and by then the person who could explain it has moved on. Companies that assign a single process owner across the whole cycle, rather than three department heads defending their segments, resolve exceptions considerably faster.

What are the most common procure to pay problems?

The recurring failures are maverick spending outside the PO process, missing or late goods receipts, invoices that arrive as unstructured PDFs and have to be keyed by hand, duplicate payments, price and quantity mismatches that stall in exception queues, and no visibility into committed spend until the invoice lands. Nearly all of them trace back to a document that was never captured as data.

Manual invoice entry is the specific bottleneck most teams feel. An invoice arrives as a PDF or a scan, and someone retypes the vendor, dates, line items, and totals into the accounting system before the match can even run. Manual keying carries roughly a one in ten error rate, and industry estimates commonly put the fully loaded cost of processing an invoice by hand at around $12 to $15. Our breakdown of the cost to process an invoice works through where that money goes.

How do you automate the procure to pay process?

You automate P2P by removing manual data entry and manual routing at each handoff: electronic requisitions with approval rules, purchase orders generated from approved requisitions, receipts captured at the dock, AI extraction that turns supplier invoices into structured data, automatic three-way matching against tolerances, and scheduled electronic payment. The invoice capture step is usually the highest-return place to start.

The reason is arithmetic. Matching, approval routing, and payment are all rules-based and cheap to automate once the invoice exists as clean data. Until then, every downstream step waits on a human transcribing a PDF. AI-based invoice data extraction software reads any vendor layout without a template and returns vendor, invoice number, dates, tax, totals, and the complete line-item table as columns, typically at 95 to 99 percent field accuracy. That single change is what lets the match run automatically.

The upstream half deserves the same treatment. Requisitions and approvals belong in a system rather than in email, and teams that issue and track purchase orders in one place stop discovering commitments only when the bill arrives. On the AP side, accounts payable automation software handles approval routing and payment once the data is clean, and if you run QuickBooks or NetSuite, QuickBooks AP automation and NetSuite AP automation explain exactly where each system's native bill capture stops and what you need to add.

What does a fully automated procure to pay cycle look like?

In a mature cycle, a requester picks an item from a catalog, the requisition routes automatically against budget, an approved PO issues to the supplier without anyone retyping it, the receipt is scanned at delivery, the supplier's invoice is read by AI on arrival and matched against the PO and receipt within tolerance, and the payment schedules itself. A person only sees the transactions that fail the match.

That last sentence is the whole goal, and it has a name: touchless processing. Best-in-class AP teams currently reach a touchless rate near 49 percent, meaning roughly half of invoices complete without human intervention, while typical teams sit well below that. Our guide to touchless invoice processing explains how the rate is measured and what pushes it up. The realistic target is not zero people. It is people spending their time on the exceptions that actually need judgment, instead of on typing.

How do you measure procure to pay performance?

Track cost per invoice, invoice cycle time from receipt to approval, touchless or straight-through processing rate, invoice exception rate, PO coverage as a percentage of total spend, days payable outstanding, and the share of early payment discounts captured. Measured together, they show whether the process is fast, controlled, and cash-efficient rather than just one of the three.

PO coverage is the metric procurement teams underuse. If only 60 percent of spend flows through purchase orders, then 40 percent of your invoices arrive with nothing to match against, and no amount of AP automation will fix that. Raise PO coverage first and the exception queue shrinks on its own. Our accounts payable KPIs guide lists the formulas and typical benchmarks for the rest, and days payable outstanding covers the cash side.

Where to start if your P2P process is manual

Start where the labor is. In almost every team we see, that is invoice capture: the step where a PDF becomes data. Automating it does not require replacing your ERP, changing your approval matrix, or running a procurement transformation program. You point an extraction tool at the invoices, get structured line-level data back, and the matching and approval steps that were waiting on a human suddenly have something to work with.

From there the sequence is straightforward. Get PO coverage up so invoices have something to match against. Record receipts consistently. Set sensible matching tolerances so trivial variances do not create exceptions. Then automate approval routing and payment. Each step compounds, because the controls only work when the data underneath them is complete. If you want to see what clean extraction produces, upload an invoice to the tool at the top of this page, or read how invoice data capture software reads any vendor layout without a template.