Procure to pay process: steps, controls and automation points

The procure to pay (P2P) process is everything between deciding to buy something and paying the supplier for it: requisition, approval, purchase order, receipt, invoice, matching and payment. It joins procurement and accounts payable into one flow. Done well, the company buys only what was approved, pays only for what arrived, and can show who authorized each step.

#The steps

Not every purchase uses every step. Office supplies bought from a catalog may skip sourcing. A utility bill has no PO or receipt. A sensible P2P policy says which path applies by category and value.

#Steps 1 to 4: the buying side

#Requisition and approval

Most problems that surface in AP start here. A purchase made without a requisition becomes a non-PO invoice, with no match and no pre-approved budget. A requisition with no cost center can't be coded later.

The form should capture what's needed, quantity, estimated cost, cost center or project, delivery date and a preferred supplier if there is one. Approval rules usually vary by amount, category and department, and capital items often need a different approver from operating expense.

#Supplier selection and onboarding

New suppliers are a control point. Before the first PO, collect the legal name, tax ID, address, bank details and any compliance documents your policy needs. Verify bank details with the supplier through a contact you already know, never from an email. Record who set up the supplier and who approved it. Those should be two different people.

The onboarding checklist itself (documents, bank verification, sanctions and tax checks, approvals) is covered in our vendor onboarding checklist.

#Purchase order

The PO is your contract with the supplier for this transaction. It fixes items, quantities, prices, delivery dates and payment terms. Get it to the supplier before the work or shipment begins. A PO raised after the invoice arrives is a retroactive approval, and it weakens every control downstream.

The PO is also the anchor for the other purchasing documents: the requisition above it, the goods receipt and the supplier invoice below it. A purchase order system keeps those linked, and ours is a short version of what purchase order automation covers in full, including approvals and PO matching.

#Steps 5 to 10: the paying side

#Receiving

Warehouse staff or requesters confirm that goods arrived in the right quantity and condition. For services, the requester confirms the work was done. Late or missing receipts are the most common cause of matching exceptions, and our guide to three-way matching explains why.

#Invoice capture, matching and posting

Invoices arrive by email, supplier portal, EDI or e-invoice. They're read, validated, matched to the PO and receipt, approved if needed and posted to the ledger. Accounts payable automation covers this part of the cycle in depth, and our invoice processing guide walks through extraction and validation.

#Payment and reconciliation

Approved bills go into a payment run, grouped by due date and payment method. Release needs its own approval. Afterward, bank lines are matched to payments and the ledger is reconciled. Spend data from the whole cycle feeds budget reviews and supplier negotiations.

#Controls that matter

P2P is a classic fraud target because it moves money out of the company. A few controls do most of the work.

Start with segregation of duties. No single person should be able to complete the whole chain. At a minimum, separate these roles:

Small teams can't always separate every role. Where you can't, add a compensating control, such as a second person reviewing a weekly exceptions report.

The rest of the list:

• A PO is required above a set value, with a "no PO, no pay" policy and a defined exception path.
• Match tolerances are agreed by procurement and finance, and every override is logged.
• Vendor bank detail changes are verified outside the invoice email.
• Duplicate invoice detection runs on supplier, invoice number and amount.
• Approval limits are enforced in the system, not by habit.
• Dormant suppliers and unusual payments get reviewed regularly.

Key point: The cheapest control in P2P is "no PO, no pay." It forces buying through the process and makes matching possible. Allow exceptions for categories such as utilities, but name them explicitly.

#KPIs to track

Pick a handful and define each precisely. A KPI nobody can reproduce isn't worth reporting.

Report these by supplier group or category, not only as a blended average.

#Where automation fits

Automation works best on steps with structured data and clear rules, and worst on steps that need negotiation or judgment.

Here's the build order we usually recommend:

1. Start with invoice capture, validation and matching. The data is in documents and the benefits are easy to measure.
2. Add approval routing with your authority matrix encoded.
3. Add receiving reminders and exception owners.
4. Connect requisitions and POs so the front end feeds the match.
5. Layer in reporting and supplier onboarding.

Buy a P2P suite or build around your ERP? It depends on process complexity, your ERP and volume. Suites suit standard flows. Custom workflows suit unusual approval logic, several ERPs or data that must stay in your environment. See the procure-to-pay blueprint for how we structure the connected build, and finance operations for the wider service.

#Common failure points

• Purchases outside the process. Employees buy on a card or ask a supplier directly, and the invoice arrives with no PO.
• POs raised after the fact. At that point the PO is paperwork, not a control.
• Receiving treated as an afterthought. No receipt, no match.
• Master data drift. Duplicate suppliers, stale bank details and inconsistent item descriptions confuse people and models alike.
• An approval matrix that's out of date. People leave and roles change, but the routing doesn't.
• Automating a broken process. Fix the policy first, then encode it.

If you want to map your P2P flow and find where automation pays back, talk to us. Bring your approval matrix and a recent month of invoices, and we'll show where the exceptions come from.

#Frequently asked questions

#What is the procure to pay process?

It's the end-to-end cycle from requisition through purchase order, receipt, invoice, matching and payment. It connects procurement and accounts payable so that purchases are approved, goods are confirmed and suppliers are paid correctly. Each step produces a record that supports audit.

#What is procure to pay automation?

It's the use of workflow software and AI to run repeatable P2P steps: routing requisitions, generating POs, reading invoices, matching them to POs and receipts, and posting to the ERP. People still approve spend, verify supplier bank details and resolve exceptions.

#What is the difference between P2P and purchase to pay?

The terms are used interchangeably. Some organizations say "purchase to pay" and some "procure to pay." Procure to pay sometimes implies that sourcing and supplier selection are included, so check how your team scopes it.

#Is P2P part of SAP?

SAP supports P2P through its procurement and finance modules, covering requisitions, POs, goods receipts and invoice verification. Other ERPs such as NetSuite and Sage Intacct have equivalent features. Many companies add capture and approval tools in front of their ERP.

#Is procurement going to be replaced by AI?

Unlikely. AI is good at reading documents, suggesting codes and flagging anomalies. Negotiating terms, choosing suppliers and weighing risk remain human work. The practical effect is less manual data handling for procurement and AP staff.

#What controls prevent fraud in the P2P process?

Segregation of duties, a "no PO, no pay" policy, match tolerances with logged overrides, bank detail verification outside the invoice email, duplicate detection and enforced approval limits. Review dormant suppliers and unusual payments regularly.