The Procure-to-Pay Process, Step by Step
Procure-to-pay (P2P) is the full journey from "we need this" to "the supplier is paid" — the eight steps, the controls at each, and where the process leaks when steps are skipped.
Procure-to-pay (P2P) is the end-to-end business process that starts when someone identifies a need and ends when the supplier is paid and the transaction is on the books. It spans two worlds that often don't talk — procurement (requesting, sourcing, ordering, receiving) and finance (matching, approving, paying) — and most of its failures live precisely in the handoffs between them.
The eight steps
- 1. Requisition. Someone states the need — item, quantity, purpose, budget line — and the request enters the system. Verbal needs are not requisitions; they are future disputes.
- 2. Approval. The request routes by threshold: small purchases to the budget holder, larger ones up the chain. The control is that commitment cannot precede approval.
- 3. Sourcing. For routine items, the contracted supplier; above thresholds, competitive quotations compared on the record — or for most organizations, an RFQ to several suppliers with a documented award.
- 4. Purchase order. The formal commitment: items, quantities, prices, terms. The PO is the contract the rest of the process measures against.
- 5. Receiving. Goods counted against the PO by someone other than the requester; services certified against the agreed scope. This step is where paper meets physical truth.
- 6. Matching. The three-way match — PO, receipt, invoice — runs before payment. Mismatches route to humans; matches flow through.
- 7. Payment. Released per terms, referenced to the invoice and PO, through a traceable channel.
- 8. Recording. The transaction lands in the ledger against its budget line — automatically if the system is connected, laboriously if not.
Where P2P leaks, step by step
| Skipped or weak step | The leak it opens |
|---|---|
| No requisition (purchases start with a phone call) | Maverick spend: commitments nobody approved against budgets nobody checked |
| Approval after commitment | The approval becomes theatre — the money is already spent |
| No real sourcing | Loyalty premiums and quotation theatre; prices drift years without challenge |
| No PO, or POs raised after the invoice | Nothing to match against; every invoice is negotiation |
| Receiving by signature instead of count | Short deliveries and substitutions paid in full |
| No match before payment | Paying for the undelivered, the unordered, and the duplicate |
| Payment outside the process | The audit trail breaks exactly where money moves |
| Manual recording | The ledger and the process drift apart; month-end becomes reconciliation archaeology |
Commitment accounting: the step most SMEs miss
An approved PO is money promised. Budgets that only track invoices received will happily approve spending against funds already committed — the classic double-commit overspend. Mature P2P counts open commitments against budget lines from step 4, not step 8.
What "good" looks like
A healthy P2P process in six tests
- Any purchase can be traced requisition → payment in minutes, with every document linked.
- No PO exists without a prior approved requisition; no payment without a match.
- Budget availability shows committed and actual, not just actual.
- Exceptions (emergencies, single-source, over-tolerance) are visible in a report, each with a reason.
- Supplier performance — delivery, quality, price stability — accumulates from the process itself.
- The team follows the process because it is the fastest path, not because a memo said so.
That last test is the design principle: P2P survives only when the compliant path is the convenient one — requisitions from a phone, approvals in a tap, matching automatic. For sector-flavored versions of the same chain, see NGO procurement, SACCO governance, and school term-cycle buying.
What AWRA OpsHub does today
- The full linked chain: procurement request → RFQ → quotation → purchase order → check-in → invoice → payment, each step referencing the last.
- Requisition approval enforced before procurement — an order cannot be raised from a request that has not reached approved status.
- Workflow rules gating on value, so thresholds are real enforcement rather than guidance.
- Approved purchase orders counted as commitment, so budget reflects the order rather than only the invoice.
- Payment held on an order that does not reconcile, across every payment route, with a permissioned and reasoned override rather than a silent bypass.
- An over-receipt guard at the receiving step — receiving more than the order allows is refused before it is written, and short deliveries are surfaced against the order rather than left to be noticed.
- An audit trail that assembles itself across the chain, plus a consolidated payments register.
More we can add to your workspace
- Matching stops one leg short of three-way. Ordered against received is reconciled on the order, with tolerances and an exception queue. The supplier invoice is not: we capture no invoice lines, so nothing compares what you were billed against what arrived.
- An invoice capture or OCR. A vendor invoice is entered, not read.
- A payment run or batch payment approval — payments are recorded individually.
The strength here is that the chain is genuinely linked, which is the thing spreadsheets and disconnected tools cannot give you. The weakness is at the invoice end, where the checks that should be automatic are either manual or only reachable through the API.
Anything above that you need, we can build for you
Everything listed above as something we can add describes what ships in the standard product today — it is a starting point, not a limit on what AWRA OpsHub can do for your organisation. Kenya's eTIMS integration and its maintained payroll engine are both in the product because clients needed them and commissioned them; neither appeared by itself, and the same door is open for whatever you just read about. One qualification so this is worth what it claims: a small number of things on this blog we deliberately leave to a specialist rather than build — a statutory ledger we will not sign our name to, a rule that would decide a tax question for you, a clinical or member-funds record that belongs in a regulated system — and where that is true the post says so in those words. Everything else is a scope, a timeline and a price.
The operational work, which is what most commissions actually are
An extra approval stage in a chain that does not match the standard one, a custom field set on employees or assets that only your sector needs, an expiry that has to block an order rather than send an email, a report your board asks for in a shape nothing produces, or a scanner or weighbridge feeding the goods-in door. These are the commissions we are asked for most often and the smallest ones we quote — and unlike a revenue-authority pipeline, none of them waits on a regulator.
The module-shaped additions, which are the ones readers ask for most often
A price list with real discount authority, a customer-facing quotation that expires, a bill of materials or recipe costing, a staff advance that is issued, acquitted and chased, a member or unit ledger, a matching rule that holds a payment. Each of these is a build rather than a setting, and each has been quoted before — a bigger piece of work than a custom field, with a written spec and a date instead of a roadmap slide.
The report, document or pack nothing currently produces
The board pack in the shape your board actually asks for, a donor or funder layout, an invoice or receipt template carrying what your regulator or your customer expects, a dataset the report builder cannot reach yet. Usually the fastest thing on this list to deliver, because the data is already in the system.
Systems, rails and hardware you already run
The accounting package, CRM, online store, core banking or custom database you intend to keep — connected through our API so a fact is entered once and appears everywhere it is needed. Plus the physical edge: a scanner, a scale, a weighbridge or a till peripheral feeding the door it belongs to.
How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. Nothing here waits on a regulator or a published specification, which is why operational builds are the ones we quote fastest. Tell us the requirement that would otherwise rule us out — that is a better first conversation than a demo.
Tell us what your operation needsRun the whole chain in one system
Requisition to payment with approvals, matching, budget commitments, and a self-assembling [audit trail](/glossary/audit-trail).
See P2P in AWRAFrequently asked questions
What is the difference between procure-to-pay and source-to-pay?
Source-to-pay (S2P) starts earlier — strategic sourcing, supplier selection, and contracting — then contains P2P inside it. P2P assumes suppliers and terms broadly exist and governs the transaction flow. Most organizations build P2P discipline first; S2P maturity follows.
Do small organizations really need all eight steps?
They need all eight decisions — but scaled: below a petty threshold, requisition-approval-order can be one quick record and the match is a stapled receipt. What kills small organizations is not lightweight steps; it is absent ones, usually receiving and matching.
Where should P2P automation start?
At the two ends that hurt most: requisitions-with-approvals (kills maverick spend) and three-way matching (kills payment leaks). Sourcing automation and supplier portals come after the transaction backbone is solid.
How does P2P relate to order-to-cash?
Mirror images: P2P is you buying (money out); order-to-cash (O2C) is you selling (money in) — order, fulfil, invoice, collect. A connected system runs both against the same inventory and ledger, which is what makes the books agree with the warehouse.
