What does procure to pay mean?
Procure to pay, sometimes shortened to P2P, covers everything between “we need this” and “the cost is in the accounts”. Procurement alone ends when you place an order. Procure to pay keeps going through delivery, invoice and payment.
The reason to see it as one chain is control. Most losses happen at the joins: an order that was never received, an invoice paid twice, a delivery nobody recorded. A purchase is safe only if each step hands over cleanly to the next.
What are the steps?
| Step | Who usually owns it | What happens |
|---|---|---|
| 1. Requisition | Programme or operations staff | A need is written down, with project and budget line |
| 2. Approval | Approver, by authority level | Someone with the right limit agrees |
| 3. Sourcing | Logistics or procurement | Quotations or tender; choose a supplier |
| 4. Purchase order | Procurement | Terms are fixed and the budget commitment is recorded |
| 5. Receipt | Stores or receiving officer | Goods or services are checked against the order |
| 6. Invoice check | Finance | Invoice is compared with order and receipt |
| 7. Payment approval | Authorised payment approver | The payment is agreed |
| 8. Payment | Finance, through the bank | Money leaves the account |
| 9. Posting | Finance | The cost is recorded in the ledger |
Our article on the NGO procurement process, step by step covers steps 1 to 4 in depth.
Why does the order create a commitment?
When you issue a purchase order, the money is promised even though it has not left the bank. That promise is a commitment. If you track only payments, a budget line can look healthy while orders pile up behind it.
Showing commitments against the budget means a project manager sees what is really available. If an order is cancelled, the commitment is released. Our article on why purchase orders matter for budget control explains this further.
Which controls matter most?
The same few controls appear in every good procure-to-pay process:
- Separated duties. The person who raises a request does not approve it. One person does not approve two steps of the same purchase.
- Approval limits. Higher values need higher authority.
- Match before payment. Compare the order, the receipt and the invoice. If they disagree, stop and ask. See three-way match.
- Budget check. A request names the project and budget line.
- Records that link. Every document carries a shared reference.
- Period control. Entries go to the right accounting period, and closed periods are protected.
Where do problems usually happen?
- Orders without requests, created after someone has already agreed with a supplier.
- Receipts that are late or missing, so finance cannot confirm what arrived.
- Invoices that differ from orders, with no note.
- Duplicate invoices, paid twice.
- Stock not updated, because receiving and stores are different jobs.
- Payments with no link to an invoice.
Each problem is a break between two steps. Look at the hand-overs, not at the steps alone.
What is the difference between receiving, stock and payment?
NGOs often mix these up.
- Receiving confirms that what arrived matches the order.
- Stock records what is in the store, where, and in whose custody.
- Payment moves money, after approval.
Each is a separate action with a separate record. A receipt can be perfect while stock is not updated. A payment approval can exist without proof the money left the bank. Say clearly which record you mean when you talk about any of these.
How should you start improving yours?
Take five recent purchases and walk each from request to posting. Mark where records are missing, where one person did two steps, and where documents disagree. Fix the biggest gap first, usually missing receipts or approvals after the order. Then write the chain on one page, with owners and limits, and share it.
Where EMPOBase fits
The EMPOBase procure-to-pay workflow records requisitions, purchase orders, goods receipts, payment approvals and accounting entries against one project. Approval limits are set by your organization, the requester cannot approve their own request, and one person cannot approve two steps. Approved requests post to the ledger exactly once, and purchase orders keep committed funds visible against the budget. EMPOBase does not move stock when a goods received note is recorded, does not make bank transfers and has no settlement or proof-of-payment record. It is not your statutory accounting. See the full procure-to-pay workflow.