What is procure-to-pay? The P2P process, step by step

The plant manager messages procurement on WhatsApp: the packing line needs four new conveyor belts by Friday. Procurement calls a supplier they used last year, agrees a price on the phone, and the belts arrive on Thursday. Three weeks later, an invoice for Rp 86,500,000 lands in AP.

There is no purchase order to check it against. Nobody recorded what arrived. The budget owner never approved the spend, and the bank account on the invoice doesn’t match the one in the vendor master. Before AP can pay, someone has to rebuild the whole purchase from chat messages.

Every step that should have happened was skipped, and each one would have taken minutes at the time. That chain of steps is procure-to-pay. This guide explains each one and who owns it, the difference between a requisition and a purchase order, a worked budget check, where the process breaks and how to tighten it.

What is procure-to-pay?

Procure-to-pay (P2P) is the end-to-end process a company uses to buy goods and services: from identifying a need, through approval, ordering, receiving and invoicing, to paying the supplier and recording it in the books.

It spans two teams that often work apart. Procurement owns the front half: choosing vendors, agreeing prices and placing orders. Accounts payable (AP) owns the back half: checking invoices, paying them and recording the payment. P2P is the single process that connects them, so each step hands a complete record to the next.

You may also see source-to-pay, which adds the strategic sourcing work before any purchase: tenders, contracts and supplier selection. On the sales side, the mirror image of P2P is order-to-cash.

The procure-to-pay process, step by step

1. Choose the vendor. The buyer picks from approved vendors, catalogue items or contract prices, or collects quotes and compares them. A new vendor is onboarded and verified before anyone can order from it.
2. Raise a purchase requisition. The person who needs something asks for it formally: what, how many, why and which cost centre or project pays for it.
3. Approve it. The request goes through your approval matrix, by amount, cost centre, project or entity, with the budget in view.
4. Issue the purchase order. The approved request becomes a PO sent to the vendor, with a number, lines, prices, delivery dates and payment terms.
5. Receive the goods or services. Whoever receives them records what arrived against the PO lines, including partial deliveries and rejected items.
6. Capture the invoice. The vendor’s invoice is entered and linked to its PO.
7. Match. The invoice is checked against the PO and the receipt, usually by 3-way matching, within agreed tolerances. Mismatches go to an exception queue.
8. Pay. Matched, approved invoices go into a payment run scheduled by due date, to a verified bank account, with checks that stop duplicate payments.
9. Record. The invoice and payment are posted to the ledger, and the AP ageing shows what is still owed.

Who owns each step

Step	Owner	Document
Vendor selection	Procurement	Approved vendor list, quotes
Requisition	Requester	Purchase requisition (PR)
Approval	Budget owner, approvers	Approval record
Order	Procurement	Purchase order (PO)
Receipt	Warehouse or requester	Goods receipt, or BAST for services
Invoice and matching	AP	Invoice and faktur pajak
Payment	Finance	Payment run and bank file

Each document comes from a different person. That separation is the control: nobody can create a commitment, confirm it was delivered and approve its payment alone.

Purchase requisition vs purchase order

The two are easy to confuse, and many companies use one form for both.

• A purchase requisition (PR) is internal. It asks permission to spend. It doesn’t commit the company to anything, and it may not yet name the final vendor or price.
• A purchase order (PO) is external. It goes to the vendor and commits the company to buy specific items at a stated price and on stated terms. It’s the document the receipt and the invoice are later checked against.

Put simply, the PR is the question (“may we buy this?”) and the PO is the answer to the vendor (“we are buying this, on these terms”).

A worked example: checking the budget before the commitment

Back to the conveyor belts. If the request had been raised properly, the approver would have seen the maintenance budget for the quarter:

Maintenance budget, Q4	Amount
Budget	Rp 250,000,000
Spent (invoices posted)	Rp 148,000,000
Committed (open POs)	Rp 31,500,000
Available	Rp 70,500,000
This request	Rp 86,500,000
Over budget by	Rp 16,000,000

Look only at the ledger and Rp 102,000,000 seems to be left, so the request fits. Count the purchase orders already issued but not yet invoiced, and it is Rp 16,000,000 over. That’s the decision the approver needs to make, before the order is placed: move budget, reduce the order or defer part of it.

This is the quiet advantage of a proper P2P process. Purchase orders show finance what the company has committed to before the invoices arrive, so the budget is checked against the real position, not last month’s.

Where procure-to-pay breaks down

• Buying outside the process. Orders placed by phone or chat mean the invoice is the first document finance sees.
• POs raised after the invoice. A purchase order created to make the invoice pass the system controls nothing.
• Receipts nobody records. Without a receipt, AP either waits or pays on trust.
• Approvals that stall. When approval takes a week, people find ways around it.
• A messy vendor master. The same vendor twice, bank details changed by email and nobody checking either.
• Invoices from every channel, keyed by hand. Email, paper and WhatsApp, each one typed in before anything can be matched.
• Payments by memory. Invoices paid when the vendor calls, which means some early, some late and discounts missed.

Procure-to-pay in Indonesia

• Record tax status at vendor onboarding. Capture the NPWP and whether the vendor is a PKP (registered for VAT), since only a PKP can issue a faktur pajak.
• BAST for services. For services, the receipt is usually a berita acara serah terima (BAST) confirming the work was handed over. Treat it like a goods receipt in matching.
• Check the faktur pajak with the invoice. Input VAT (PPN masukan) can only be credited on a complete and correct faktur pajak, so check it against the PO and invoice in the matching step, not at month-end.
• Expect withholding. For many services, PPh 23 is withheld from the payment, so the amount transferred is less than the invoice total. Build that into the payment step, along with the bukti potong the vendor will ask for.
• The right PT issues the PO. In a group with several companies, the PO should come from the entity that will be invoiced, so the invoice and faktur pajak carry the right name and NPWP.

Signs your P2P process needs work

You probably need to look at your process if any of these sound familiar:

• Finance learns about a purchase when the invoice arrives.
• Purchase orders are raised after the invoice, to get it through the system.
• Nobody can say what has been committed against a budget this month.
• AP pays invoices without a recorded receipt.
• Vendor bank details are changed on the strength of an email.
• Invoices are paid late, or early, because nobody tracks due dates.
• Requesters ask finance where their purchase is every week.

If the invoice is the first document finance sees, you don’t have a procure-to-pay process. You have a pay process.

How to tighten procure-to-pay this quarter

1. Trace five recent purchases. Follow each from the first request to the payment, and note every step that happened in chat, email or someone’s head.
2. Agree a “no PO, no pay” rule. Decide which categories always need a PO and list the exceptions, such as utilities, rent and subscriptions. Send invoices without a PO through a stricter approval chain.
3. Count commitments in the budget. Check every request against what is spent plus what is on order.
4. Make receipts easy to record. The people who receive goods should be able to confirm them in a minute, from where they are.
5. Clean the vendor master. Merge duplicates, verify bank accounts and require a second person to approve every bank detail change.
6. Capture invoices in one place. One inbox or portal, with each invoice linked to its PO.
7. Pay by calendar. Build payment runs from due dates and early-payment discounts, not from who called last.
8. Measure it. Track the share of spend with a PO before the invoice, the first-time match rate and the share of invoices paid on time.

---

How Procapy helps

Proca to Pay runs the whole procure-to-pay cycle inside Procapy. Spend starts from approved vendors, catalogue items and contract prices, and new vendors are onboarded with bank-account and document verification before they can be used. Purchase requests are raised in Procapy rather than in a chat message, and ProcAI checks each one against policy, budget and the vendor list before it can be submitted. ProcApprove then routes it through your delegation-of-authority matrix, and approvers act from their phone with the budget on the same screen.

Approved requests become purchase orders with no re-entry, receipts are recorded against PO lines and open commitments are visible to finance before the invoice arrives. Invoices are forwarded, uploaded or submitted by vendors, and ProcAI reads them and links each one to its PO. Procapy compares invoice, PO and receipt line by line within the tolerances you set and flags duplicate invoices, changed bank accounts and unknown vendors before approval. Cleared invoices go into payment runs built by due date, entity and bank, and are posted to Dynamics, SAP, Xero, QuickBooks or ABSS with the full audit trail. Invoices without a PO still go through capture, approval, fraud checks and payment, and you decide which categories or amounts must have one.

Most teams are live in under two weeks. Book a walkthrough and bring your delegation-of-authority document, and we’ll configure your first approval chain live.