Procure to Pay Process: The End-to-End P2P Cycle in 8 Steps

People search for this when they've just been asked to "explain P2P", when an ERP consultant has drawn eight boxes on a whiteboard, or when accounts payable and procurement are arguing about whose job a stuck invoice is. The cycle is the same in a plant running SAP or Oracle, a business running a mid-market ERP with spreadsheets alongside it, and a buying team that still works from email and chat. What changes is which document is missing and what that missing document costs you. This guide walks the end-to-end procure to pay process step by step, with the owner, the document and the control at each step.

The procure to pay cycle at a glance

Read the cycle left to right. Each step creates a document the next step is checked against. If a step is skipped, the match at the end has nothing honest to match to.

1. 1

   Identify the need

   A person or a reorder rule says something must be bought.

2. 2

   Purchase requisition

   The need is written down, with quantity, date and a suggested vendor.

3. 3

   Approval

   The right person accepts the spend before anyone promises a supplier.

4. 4

   Sourcing

   Quotes, a rate contract or an auction set the price.

5. 5

   Purchase order

   The buyer sends a numbered order the vendor can accept.

6. 6

   Goods receipt

   Stores record what actually arrived.

7. 7

   Invoice and match

   Accounts compare the invoice with the order and the receipt.

8. 8

   Payment

   The vendor is paid, and the order is closed.

It's called a cycle because the last step closes the first: the payment closes the PO that the requisition opened. A PO that's never received or never paid is an open loop.

The SAP transaction codes are only labels for the same documents. Oracle, Microsoft Dynamics, NetSuite and other ERPs use the equivalent screens. A company that does not run SAP still has a requisition, an order, a receipt and an invoice. If one of those four is missing, you do not have a procure to pay process. You have a habit of paying bills.

8 steps of the procure to pay process

1. Identify the need

Owner: requester, stores or planner · Output: a stated need · Control: quantity, specification, need-by date and delivery location written down.

Someone notices stock is low, a machine needs a spare, or a project needs a service. In a plant this is often a storekeeper or a maintenance engineer. In an office it is whoever is about to buy something on a card. The failure here is buying before anyone has said what 'done' looks like: quantity, specification, need-by date, and where it must be delivered. Direct material and indirect buys follow the same cycle with different owners — see direct vs indirect procurement.

2. Purchase requisition

Owner: requester · Output: purchase requisition (PR number) · Control: no PR, no PO.

The need becomes a purchase requisition. It's internal, so no vendor has been promised anything yet. A useful PR states the item, quantity, unit, required date, delivery location, a suggested vendor if there is one, and the cost centre or GL code. In many factories the same request is called a purchase indent, with the same fields. The common failure is a one-line request ("steel sheet, urgent") that leaves the buyer to guess the grade, the thickness and the site. A blank you can copy is the purchase requisition form.

3. Approval

Owner: budget holder · Output: approval record · Control: approval limits by amount and category.

The requisition waits until someone who may spend that money says yes. Approval is not a courtesy. It is the moment the company accepts the spend. Route it by amount and by category: a storekeeper can pass a small repeat buy, a plant head passes a larger one, finance passes anything that hits a capital budget. The document is the approval record (who, when, and any condition). The failure is an approver who is always travelling, so people stop raising PRs and the invoice arrives first. Write the limits down as an approval workflow so the rule doesn't live in one person's head.

4. Sourcing

Owner: buyer · Output: RFQ, quotes, comparison (or a contract call-off) · Control: like-for-like comparison of landed cost.

If a rate contract, framework agreement or catalogue already fixes the price, sourcing means "pick that rate and move on". If nothing fixes it, the buyer sends an RFQ (see the RFQ template and quotation request email), collects quotes and lines them up on a comparative statement. With a clear specification and three or more qualified suppliers, a reverse auction does the same job in one sitting. The failure is comparing unit prices that leave out freight, duties, tax treatment or payment terms, then calling the cheapest line the winner. Compare landed cost instead.

5. Purchase order

Owner: buyer · Output: purchase order with a PO number · Control: PO issued before goods or services are delivered.

The buyer issues a purchase order with items, quantity, unit price, currency, Incoterms or delivery place, delivery date and payment terms, all under one PO number. Once the vendor accepts it, it's the commercial commitment. Put the tax treatment on the PO (sales tax, VAT or GST, plus any tax ID or commodity code your jurisdiction needs) so the invoice isn't the first time anyone writes it down. For repeat buys, a blanket purchase order with releases saves a fresh PO each time. The failure is a PO raised after the goods have arrived, which means the price was never really agreed. Template: purchase order format.

6. Goods receipt

Owner: stores / receiving (or the service requester for services) · Output: goods receipt note or service acceptance · Control: counted, not copied, quantity.

The shipment arrives with a packing list or delivery note. Stores count and inspect, then write a goods receipt note for what they actually accept. Short shipments, damage and the wrong grade get recorded here, not in an email a week later. For services, the equivalent is a service receipt or acceptance from the person who saw the work done. The failure is a GRN that copies the PO quantity instead of the counted quantity. The match then passes and you pay for goods you don't have.

7. Invoice and three-way match

Owner: accounts payable · Output: matched (or held) invoice · Control: three-way matching within set tolerances.

The supplier's invoice should quote the PO number. Accounts payable compares three documents: the PO (what was ordered), the GRN (what was received) and the invoice (what is being billed). Quantity, price and tax must agree within the tolerance you've set. A mismatch becomes a query, not a payment. The failure is releasing invoices unchecked to hit a payment deadline, which teaches vendors that nobody checks. See the matching section below for two-, three- and four-way match.

8. Payment

Owner: accounts payable / treasury · Output: payment and remittance advice · Control: pay only matched, approved invoices, to verified bank details.

Treasury pays the matched, approved invoice on its due date and sends a remittance (payment) advice listing the invoices and PO numbers it covers. The PO is then closed, or left partly open if more is still to come. The failure is a payment that can't be tied back to a PO, so the next dispute starts from a bank statement instead of a document. In some countries late payment to small suppliers carries statutory interest. Know the rule for each supplier's jurisdiction (see the tax and payment terms section).

End-to-end procure to pay: before step 1 and after step 8

What does "end-to-end procure to pay" mean? It means the eight steps plus the setup that makes them work and the accounting that closes them out. Most stuck invoices trace back to something outside the eight boxes: a supplier set up with the wrong bank details, a contract price nobody loaded, or a receipt that never reached the books before month-end.

Before step 1 (set-up):

• Supplier onboarding and vendor master. Legal name, tax registration, bank details, payment terms and an approved category on file before the first PO. Bank details are verified out-of-band (a call-back to a known contact), never from an email alone. See the vendor onboarding checklist.
• Contracts, rate contracts and catalogues. Agreed prices loaded where the requester and buyer will see them, so step 4 is a call-off, not a new negotiation.
• Approval matrix and budgets. Who may approve what, by amount and category, and which cost centres or projects are open.

After step 8 (close-out):

• Accruals for goods received but not invoiced (GRNI). Receipts with no invoice yet are still a liability at month-end.
• Open-PO review. Close or cancel POs that will never be delivered, so committed spend reflects reality.
• Spend reporting and supplier performance. Payment and receipt data feeds spend analysis, supplier scorecards and the next sourcing round. That's where procure to pay hands back to source to pay.

A simple test: if you can follow one purchase from a verified supplier record, through the PR, PO, GRN and matched invoice, to a payment and a closed PO in the period's books, without asking three people, you have an end-to-end procure to pay process.

Documents in the P2P cycle

You do not need every document on every buy. A rate-contract release can skip a fresh RFQ. You do need to know which document you skipped, and why the match can still be done.

• Purchase requisition. Internal request; not a promise to a vendor.
• RFQ and quotation. The ask, and each vendor's priced reply.
• Comparative statement. The sheet that shows why one quote won.
• Purchase order. The external commitment, with a PO number.
• Delivery note / packing list. What the vendor says is on the truck. In India this is often a delivery challan.
• Goods receipt note (or service acceptance). What stores, or the service owner, accepted.
• Supplier invoice. What the vendor is billing, including sales tax, VAT or GST where it applies.
• Credit / debit note. The correction when the invoice and the receipt disagree.
• Remittance (payment) advice. Which invoices this bank transfer covers.

Two-way, three-way and four-way match

Matching is the control at the heart of procure to pay. The question is how many documents have to agree before an invoice can be paid.

Tolerances. Set a price and quantity tolerance per category, as a percentage, an absolute amount or both, so a rounding difference doesn't block payment while a real overcharge does. Write the tolerance down, keep it small, and review the invoices that pass only because of it.

Services. Without a GRN, "receipt" means a service acceptance or timesheet approved by the person who saw the work. Without it, a services invoice is only two-way matched against the PO.

Non-PO invoices. Some invoices legitimately have no PO, such as utilities and some statutory fees. Keep a short, named list of those categories, route them to a budget holder for approval, and report them separately. Anything else that arrives without a PO is an exception, not a category.

Holds and exceptions. A failed match should land in a queue with a reason (price, quantity, missing GRN, missing PO, duplicate) and an owner. The share of invoices landing there is your exception rate, and the share that never does is your first-pass match rate. Both are in the KPI section.

Procure to pay example

Illustrative numbers only, not market prices.

A fabrication shop needs 5,000 kg of 2 mm mild-steel sheet for a job starting in three weeks. The storekeeper raises a purchase requisition with the quantity, the grade from the drawing, the thickness, the plant to deliver to and a need-by date. The plant manager approves it the same day because it fits inside the monthly steel budget.

There's no contract price for this thickness, so the buyer sends the same specification to three mills and stockholders. One quotes USD 1.18/kg ex-works, one USD 1.15/kg delivered, and one USD 1.12/kg but wants 100% payment in advance and can't confirm the mill certificate. Compared on landed cost and risk, the USD 1.15 delivered quote is the one they can use. The buyer issues PO-2026-1184 for 5,000 kg at USD 1.15, a net value of USD 5,750, plus sales tax, VAT or GST at the rate that applies in the buyer's jurisdiction, with payment due 30 days after goods receipt.

The truck arrives with a delivery note for 5,000 kg. Stores weigh the load, accept 4,800 kg, and record 200 kg of wet, rusted sheet as rejected on the GRN. The supplier's invoice still says 5,000 kg, so three-way match puts it on hold. The supplier issues a credit note for 200 kg, the corrected net amount is USD 5,520 (4,800 × 1.15) plus tax at the applicable rate, and accounts payable releases payment inside the 30-day term. Whether the tax is recoverable depends on local rules and on holding a valid invoice for goods actually received. This is a buying example, not tax advice.

Without the GRN, the shop would have paid for 200 kg it never used. Without the PO, there would've been no agreed USD 1.15 to hold the invoice against.

The same worked example in ₹ with GST is in the GST input tax credit guide.

Tax, e-invoicing and payment terms by country

The cycle is the same everywhere. Local rules change what has to appear on the documents and how fast you have to pay. Check four things for each country you buy in:

• Indirect tax on the PO and invoice. Sales tax, VAT or GST, with the rate and any tax ID or commodity code your jurisdiction requires. Put it on the PO so the invoice matches it, and check whether input tax is recoverable before calling a quote "cheapest".
• E-invoicing. A growing number of countries require invoices to be issued or registered through a government or approved platform. Confirm the current rule for the supplier's country before you reject an invoice format, or demand one a small supplier isn't required to use.
• Withholding tax. Some payments require you to deduct tax at source. If that applies, the PO should say so, so the supplier's receivable matches what you actually pay.
• Statutory payment terms. Several jurisdictions cap payment terms or charge interest on late payment to suppliers, especially small ones. Keep the supplier's size and country on the vendor record so a "we pay everyone in 90 days" policy doesn't break a local law.

Roles and controls in procure to pay

Segregation of duties is the reason for the right-hand column. No one person should be able to create a vendor, order from it, receive the goods and pay it. In a small team, where one person wears two hats, add a compensating control such as a second approver on payments or a monthly review of vendor-master changes.

Core controls to name in your P2P policy: no PO, no pay (with a named non-PO list) · approval limits by amount and category · counted goods receipts · three-way match with written tolerances · duplicate-invoice check (same supplier, number and amount) · verified bank-detail changes · open-PO and GRNI review at month-end.

Who needs to see the open cycle. Stores needs the open PO before the truck arrives, or the GRN gets written from the delivery note and corrected later. Accounts needs the GRN before the invoice is due, or they either hold a correct bill or pay a wrong one. The requester needs the PO number, or they raise a second requisition for the same steel. None of that needs a new system. It needs the PO number, the open quantity and the match exception visible to those three people without an export.

If you are drawing the cycle for a new plant, start with those four documents — requisition, order, receipt, invoice — and name the person who creates each one. Add sourcing, approval and payment around them. A flowchart with twelve boxes and no names is a poster. A flowchart with four documents and an owner on each box is a process you can audit on Friday.

P2P vs S2P vs O2C

P2P vs S2P: source to pay is procure to pay plus the work before the requisition: spend analysis, supplier selection and the contract (see source to pay). P2P vs O2C: order to cash is the same deal from the supplier's side, because your purchase order is their sales order (see procure to pay vs order to cash). This page stays on the buyer's cycle.

P2P KPIs to track

Pick a few and define them once. A borrowed target from another company is useless if they count 'managed' differently from you.

• PR-to-PO cycle time. From approved requisition to the PO the vendor receives. Report catalogue / contract buys separately from buys that needed quotes, because one blended number hides both.
• End-to-end P2P cycle time. From approved requisition to payment. Split it at the goods receipt so you can see whether the delay is in buying or in paying.
• First-pass match rate. Share of invoices that match the PO and GRN without a hold. A low rate usually points to a bad PO or a copied GRN, not a "vendor problem".
• Touchless (straight-through) invoice rate. Share of invoices captured, matched and approved for payment with no manual touch. It's the automation KPI. Only count invoices that were actually checked, not ones auto-approved under a loose tolerance.
• Invoice exception rate and reasons. Share of invoices that land on hold, broken down by price, quantity, missing GRN, missing PO and duplicate. The reason mix tells you which step to fix.
• Spend on PO (PO compliance). Value of invoices that had a PO before the invoice, divided by supplier spend. It's the practical cousin of spend under management.
• On-time payment rate and days payable outstanding. How many invoices are paid by their due date, and how long you take on average. Watch both next to any statutory payment terms, not only against a cash target.
• Cost per PO / per invoice. Procurement and AP cost in a month divided by POs or invoices processed. It shows whether tiny POs are worth the handling or belong on a card or catalogue.
• Maverick spend. Spend with no PO, or off an existing contract, as a share of spend procurement can influence. See maverick spend and how to reduce maverick spend.

Common P2P problems and controls

• Invoice before PO. Do not start the match. Raise the PO only if you would have approved the buy anyway, and mark it as after-the-fact so it stays visible.
• GRN copied from the PO. Stores should enter a counted quantity. A GRN that always equals the PO is not a control.
• One-line requisitions. Send them back. The buyer cannot source a specification that was never written.
• Approvers who do not open the tool. A limit that matches how the company actually decides is better than a perfect matrix nobody uses.
• Chat or email as the system of record. A message can start a need. The PR, PO and GRN still have to exist, or the payment has no file.
• Paying unchecked invoices to hit a deadline. Pay what matched and chase the rest. A bad invoice paid on time is still a bad invoice. If a statutory payment term applies, fix the match speed, not the control.
• Non-PO invoices creeping up. Keep the allowed non-PO list short and named. Report everything else back to the requester's manager.
• Duplicate invoices. The same invoice sent by email and post, or re-sent with a changed number. Check supplier + amount + date + invoice number before payment.
• Unverified bank-detail changes. A "please update our bank account" email is the classic payment-fraud route. Verify by calling a known contact before changing the vendor master.

Manual vs automated procure to pay

On paper the eight steps are the same either way. Manually, each step is a different file: a form in stores, a sheet of quotes, a PO in the ERP, a GRN in a register, an invoice in a mailbox. Someone retypes the lines between them, and the retyping is where the quantity changes. Automation means the PO is created from the approved requisition, the GRN is booked against that PO, and the invoice is held when it does not match. It does not remove the need for a person to count the goods or to decide which quote is acceptable.

In an ERP the names are familiar: purchase requisition, purchase order, goods receipt, invoice verification and payment run, whatever your ERP calls them. A tool in front of the ERP is doing the same cycle if a buyer can see one record from the request to the payment. If they have to export to Excel to know whether the GRN happened, the cycle is still manual.

What to automate first. Automate in the order the errors happen, not the order of the flowchart:

1. PR → PO without retyping. The approved requisition becomes the PO lines. Most quantity and price drift starts here.
2. Approval routing by amount and category, with delegation when an approver is away.
3. Goods receipt against the open PO, on a phone or tablet at the dock, so the GRN exists before the invoice arrives.
4. Invoice capture and automatic three-way match with your written tolerances, sending exceptions to a named owner.
5. Payment run from matched invoices only, with remittance advice that lists PO and invoice numbers.
6. One record visible to requester, buyer, stores and AP from request to payment.

Automation doesn't remove the person who counts the goods or decides which quote is acceptable. It removes retyping and lost handoffs, and those show up in your first-pass match and touchless rates.

How Procupy handles this

Procupy keeps the procure to pay documents on one record. A person raises the requisition, the approval route runs on amount and role, and the purchase order goes to the vendor with the lines and the tax that were approved. Stores book the goods receipt against that PO. Accounts match the invoice to the order and the receipt before anyone is paid. A vendor can join a sourcing event from a link with a name and a phone number, and the price they win is the price on the PO. When a quantity is short or a payment is late, you are looking at that record, not at three inboxes.