The purchase to pay process (often shortened to P2P, and also called procure to pay) is everything that happens between someone deciding the business needs something and the supplier being paid for it. There are eight steps: requisition, approval, purchase order, goods received, supplier invoice, three-way match, the month-end accrual for goods received but not yet invoiced (GRNI), and payment. Each step is simple on its own. The trouble starts when the steps live in different places: the request in an email, the approval in someone's head, the purchase order in a job or stock system, the delivery docket on a clipboard and the bill in the accounts. Then every hand-off needs someone to retype, chase or reconcile. This guide walks through each step, shows where it usually breaks, and describes what it looks like when the steps are connected.
The eight steps at a glance
- Requisition. Someone asks to buy something and says why, for which job, site or cost centre, and roughly how much.
- Approval. The right person says yes, based on your approval rules (your approval matrix or delegation of authority).
- Purchase order. A PO goes to the supplier with the agreed items, quantities, prices and a PO number the supplier must quote.
- Goods received. The delivery is checked against the PO and recorded, including short deliveries, substitutions and damage.
- Supplier invoice. The bill arrives, by email, PDF, paper or e-invoice, and is captured once.
- Three-way match. The invoice is checked against the PO and what was actually received. Differences go to a person.
- GRNI at month end. Anything received but not yet billed is accrued so the month's costs are complete.
- Payment. Matched, approved bills are paid on their due date, and the payment is recorded against the bill.
When it works, each step happens once, in one place, and anyone can see where a given order is up to. The rest of this guide takes each step in turn.
Step 1: Requisition
What it is: the request to spend. It should capture what is needed, who needs it, the job or cost centre, the preferred supplier and an estimate.
Where it breaks: requests arrive as texts, emails, phone calls or a quote forwarded with "can we get this?". There is no standard form, so the approver gets whatever detail the requester thought to include. Urgent orders skip the request altogether and are placed directly with the supplier.
When it's connected: there is one simple request form that works on a phone and in the office. It pulls the job or cost centre and the supplier from the lists your systems already hold, so nobody types a job number from memory.
Step 2: Approval (approval matrix and delegation of authority)
What it is: a decision by the right person, based on written rules. A delegation of authority says who may commit the business to spending, up to what amount. An approval matrix turns that into routing: which requests go to whom, by amount, site, cost type or job.
Where it breaks: the rules live in people's heads, approvals are a thumbs-up reply to an email, and nobody covers when the approver is on leave. The approver often can't see the job budget or what has already been committed against it, because that information sits in a different system from the request.
When it's connected: each request is routed by the rules you wrote down, the approver sees the budget and committed cost next to the request, and the approval (who, when, under which rule) is stored with the transaction. We cover how to write the rules and then make the systems follow them in approval matrix and delegation of authority, and the cross-system version in purchase order approval workflow when spend crosses several systems.
Step 3: Purchase order
What it is: the commitment to the supplier, with a number they quote on their invoice.
Where it breaks: the approval is in an email, but the PO has to be created somewhere else. Someone retypes it, sometimes into the job system and again into the accounts, sometimes days after the goods were ordered by phone. This is double data entry (the same information typed into two systems; see the glossary), and it is where prices, quantities and supplier codes start to drift apart.
When it's connected: the approved request becomes the PO automatically, in the one system that owns purchase orders, and the other systems receive a copy. If orders start in a job or stock system, that is usually where the PO should live. Our post on Xero purchase orders when orders start in another system looks at that choice in detail.
Step 4: Goods received
What it is: a record that the goods or service actually arrived, what quantity, and in what condition.
Where it breaks: the delivery docket is signed on site and stays in the ute, or receiving is recorded only as "arrived" with no quantity. Part deliveries, back orders and substitutions are not recorded, so the stock system, the PO and the supplier's invoice no longer agree. For services, nobody records that the work was done at all.
When it's connected: receiving is recorded where the goods arrive, against the PO line, with part deliveries handled properly. For services, the person who asked for the work confirms it was done. Stock levels and committed costs update straight away.
Step 5: Supplier invoice
What it is: the supplier's bill, captured once.
Where it breaks: invoices arrive in several inboxes, as attachments, on paper and through supplier portals. Someone keys each one into the accounts. Duplicates slip in when the same invoice is emailed twice or a statement is mistaken for an invoice.
When it's connected: invoices come in through one route, the details are read automatically (by e-invoicing, a capture tool or AI document reading, with a person checking), and each bill is linked to its PO number from the start. Australian e-invoicing through the Peppol network makes this easier, but only if the PO and receipt can be found; see Peppol e-invoices: matching them to POs, jobs and stock.
Step 6: Three-way match
What it is: checking the invoice against the PO (did we agree this price?) and the receipt (did we get this quantity?) before it is approved for payment.
Where it breaks: the PO is in one system, the receipt in another and the invoice in a third, so the match is done by eye with paper dockets, or not done at all. Small price differences get paid because chasing them takes longer than the difference is worth, and nobody agreed what difference is acceptable.
When it's connected: each invoice line is matched to a PO line and a receipt automatically, within tolerances you set in advance. Only the exceptions (wrong price, short delivery, no PO) go to a person, with the evidence attached. Our three-way matching guide explains the match, the tolerances and how exceptions should be handled.
Step 7: GRNI at month end
What it is: goods received not invoiced. When goods have arrived but the supplier hasn't billed yet, the cost belongs in this month, so it is accrued against the receipt and reversed when the bill arrives.
Where it breaks: if receiving isn't recorded properly, or bills aren't matched to receipts, the GRNI balance grows month after month with old lines nobody can explain. Month end turns into a spreadsheet of "did we ever get billed for this?". Margins look better than they are, then suddenly worse when a batch of late bills lands.
When it's connected: GRNI is a short, current list that finance reviews in minutes, because every receipt and every bill is linked to a PO line. Old lines are rare and each one has a reason. Our post what is GRNI? has a worked example and the month-end check, and the month-end checklist for several systems puts it in the wider close.
Step 8: Payment
What it is: paying matched, approved bills on their due date, and recording the payment against the bill.
Where it breaks: the payment run is built from a list of bills with no sign of whether they matched, so disputed bills get paid and good suppliers wait. Payment approval repeats the purchase approval because finance can't see that it already happened.
When it's connected: only matched bills (or exceptions someone has cleared) are offered for payment. The payment approver sees the trail behind each bill: request, approval, PO, receipt and match. Payment is a final check, not a second investigation.
Why the process breaks: the steps live in different systems
Look back over the eight steps and the same four problems come up:
- Information typed in again. The request is retyped as a PO, the PO is retyped into the accounts, the invoice is retyped from a PDF.
- Information that stops before it's needed. The approver can't see the job budget, receiving can't see the PO, accounts payable can't see the receipt.
- Systems that disagree. The stock system, the job system and the accounts each hold a slightly different version of the same order. This is the pattern often called data silos (information stuck in separate systems); see why your systems disagree.
- Numbers that arrive too late. Committed costs and GRNI are only known at month end, after the money is spent.
No single product fixes this when the request starts in a job system, the approval depends on budgets held somewhere else and the bills are paid from the accounts. The gap is between the systems, and that is where it has to be fixed. Our page on problems between your systems explains the wider pattern.
What a connected purchase to pay process looks like
For example, picture a site supervisor who needs a part for a job:
- On Tuesday morning they raise a request on their phone. The job and supplier are picked from lists.
- The project manager gets a notification, sees the job budget and what has already been committed, and approves it from the car park.
- A PO is created in the system that owns orders and emailed to the supplier with its number. The accounts get a copy.
- On Thursday the goods arrive short by two items. The storeperson records the part delivery against the PO.
- The supplier bills for the full quantity. The invoice is read automatically and matched. The short delivery is flagged to accounts payable with the receipt attached, and only that one line waits.
- At month end, GRNI shows the two missing items, and nothing older than a few weeks.
- On the due date the matched bill is paid, and anyone can open the trail from request to payment.
Nothing in that picture needs a new all-in-one system. It needs agreed rules, one owner for each step, and the systems you already have passing information to each other instead of people retyping it.
A real example: Kenomont built a purchase order approval system for a large retirement living provider, and it has been in daily use since 2014. Requests are raised and approved across the business with the history kept alongside each order, which is where email approvals and retyped orders tend to fall apart in any organisation that spends across many sites and teams.
Where to start
- Map how purchasing actually works today, including the workarounds, with the people who do it. Business process mapping is the structured way to do this.
- Write down your approval rules before touching software.
- Decide which system owns each step: where requests start, where POs live, where receiving is recorded, where bills are matched.
- Fix the biggest hand-off first. Usually that's approval to PO, or invoice to match.
- Then automate the joins: approvals routed by your rules, invoice capture, matching with exceptions, and posting to the accounts once.
Steps 1 to 3 are mostly agreement and can be done in-house. Step 5 is where systems need connecting. Our services for this are approval workflow systems, invoice processing and accounts payable automation and document workflow automation. If you work in wholesale or manufacturing, the procure to pay process for wholesalers and manufacturers covers stock and landed costs in more depth.
Frequently asked questions
What is the purchase to pay process?
It is the full cycle from deciding to buy something to paying the supplier: requisition, approval, purchase order, goods received, supplier invoice, three-way match, month-end accrual for goods received not invoiced, and payment. Purchase to pay, procure to pay and P2P all mean the same thing.
What is the difference between a requisition and a purchase order?
A requisition is an internal request to spend money. It doesn't commit the business to anything. A purchase order is the approved commitment sent to the supplier, with a number they quote on their invoice. The requisition becomes a PO once it is approved.
Where does the purchase to pay process usually go wrong?
At the hand-offs: approval to purchase order (the approval is in an email and the PO is retyped later), goods received (part deliveries not recorded), and invoice to match (the PO, receipt and bill are in different systems). Those gaps show up later as unmatched bills and a growing GRNI balance.
Do services need a purchase order and three-way match?
Often yes for larger or ongoing services, such as contractors and maintenance. The "receipt" is a confirmation from the person who asked for the work that it was done. Many businesses set a threshold below which services go straight to a bill with approval.
Do we need new software to fix purchase to pay?
Not always. Many businesses already have the pieces: a job or stock system, an accounting system and perhaps an approvals or bill-capture app. The usual fix is agreeing the rules, deciding which system owns each step and connecting them so information moves without retyping. New software only makes sense when a step has no home at all.
How does AI help in purchase to pay?
AI is useful for reading invoices and delivery dockets and suggesting the PO match and coding, with a person checking. It shouldn't approve spending or pay bills on its own. Our post on AI for dockets, orders and supplier invoices covers what it does well and where it struggles.
If your requests, approvals, orders and bills live in different places and month end is spent reconciling them, book a free initial chat. We'll tell you which hand-off is costing you most and what connecting it would involve.