The Purchase Order Cycle, End to End (Procure-to-Pay)
The purchase order cycle runs from the moment someone identifies a need to the moment the order is paid and closed — requisition, approval, PO raised, sent to supplier, goods received, three-way match, invoice, payment, close. This guide walks every stage end to end, explains what each one is for and who owns it, shows exactly where each stage breaks when it lives in email and spreadsheets — missed approvals, wrong quantities, unmatched invoices — and how an owned system controls the whole cycle from one view instead of nine disconnected steps.
Quick summary: The purchase order cycle — also called procure-to-pay — is the full sequence a business runs to buy something and settle up: a need is identified, a requisition is raised and approved, a purchase order is created and sent to a supplier, the goods arrive and are receipted, the invoice is matched against the order and the receipt, payment is made, and the order is closed. Each stage exists to control one specific risk — buying the wrong thing, buying without approval, paying for what never arrived. When the cycle lives across email and spreadsheets, the control stages are exactly the ones that break: approvals get skipped, received quantities go unrecorded, and invoices get paid without ever being matched.
Most explanations of the purchase order cycle stop at listing the stages, as if naming them were the same as running them. The stages are the easy part. The hard part — the part that decides whether the cycle actually controls your spend or just documents it after the fact — is the joins between the stages, and those joins are precisely where a business running on email and spreadsheets loses control. A requisition sits unapproved in an inbox. A delivery gets booked on a paper pad that accounts payable never sees. An invoice gets paid because it looked right, not because anything checked it against the order.
This guide walks the whole cycle end to end, stage by stage: what each is for, who owns it, and the specific way it fails when disconnected. The individual stages have their own deeper guides — this page stitches them together rather than repeating them, so you see the cycle as one system instead of nine separate chores.
In this guide
- What the purchase order cycle is
- The nine stages at a glance
- Stage 1: Need identified
- Stage 2: Purchase requisition
- Stage 3: Approval
- Stage 4: Purchase order raised
- Stage 5: PO sent to supplier
- Stage 6: Goods received (GRN)
- Stage 7: Three-way match
- Stage 8: Invoice and payment
- Stage 9: Close the order
- Where the cycle breaks in email and spreadsheets
- How an owned system controls the whole cycle
- FAQ
What the purchase order cycle is
The purchase order cycle is the end-to-end process a business follows to buy goods or services on credit and settle the bill correctly. “Procure-to-pay” (P2P) is the same thing named for its bookends — it starts with procurement, ends with payment. Either way it’s a controlled chain, not a single action: each stage produces a document or a decision the next stage depends on, and the point of running it as a cycle is that no money leaves the business until every earlier stage has confirmed it should.
That framing explains why the cycle has so many steps for what feels like a simple act. Each stage is a control gate answering one question — do we need this? did the right person agree to spend on it? did we tell the supplier exactly what we agreed? did the right goods turn up? does the bill match the order and the delivery? Strip out any one gate and you don’t get a leaner process; you get a specific, predictable way to lose money.
The cycle also has a shape worth noticing: the first half is about committing to spend (need through PO sent), the second about verifying and settling it (receipt through close). The riskiest joins sit at the seam — between what you ordered, what arrived, and what you’re billed. That seam is where most of the money leaks, and the part email and spreadsheets handle worst.
The nine stages at a glance
| # | Stage | What it’s for | Typical owner | Output |
|---|---|---|---|---|
| 1 | Need identified | Establish a real requirement | Requester / dept | A stated need |
| 2 | Requisition | Formalise the ask internally | Requester | Purchase requisition |
| 3 | Approval | Authorise the spend | Budget holder / manager | Approved requisition |
| 4 | PO raised | Turn intent into a binding order | Procurement / buyer | Purchase order |
| 5 | PO sent | Commit the order to the supplier | Procurement | Sent PO, acknowledgement |
| 6 | Goods received | Record what physically arrived | Warehouse / receiving | Goods received note (GRN) |
| 7 | Three-way match | Verify order = receipt = invoice | Accounts payable | Matched (or flagged) invoice |
| 8 | Invoice & payment | Settle the verified bill | Accounts payable / finance | Payment |
| 9 | Close | Reconcile and shut the PO | Procurement / finance | Closed PO |
Read down the “output” column and you can see why the cycle holds together: each stage hands the next a specific artefact. The requisition feeds the approval; the approval feeds the PO; the PO feeds the receipt and the match; the match feeds the payment. The chain is only as strong as its handoffs — and a handoff that relies on someone remembering to forward an email is the weak link the rest of this guide keeps returning to.
Stage 1: Need identified
What it’s for: Establish a genuine requirement before any process starts — a raw material runs low, a reorder point is hit, a project needs a component, equipment fails. This is the trigger.
Who owns it: Whoever has the need — a department, a line manager, a warehouse lead, or a system rule that fires when stock crosses a threshold.
The need stage looks trivial, but it’s where the first quiet waste happens. If nobody can see current stock and open orders in one place, “we need more” gets decided on a hunch: you either order what’s already on its way — because the previous PO is invisible — or you don’t order until you’ve run out, because nothing warned you. This is really a stock-visibility question: a disciplined reorder point turns “someone noticed” into “the system flagged it before it hurt.”
Stage 2: Purchase requisition
What it’s for: Turn an informal need into a formal internal request — the document that says this item, this quantity, for this reason, at roughly this cost — before anyone approaches a supplier. The requisition is an internal ask; it is not yet an order and carries no commitment to anyone outside the business.
Who owns it: The requester.
The distinction between a requisition and the purchase order that follows is the most misunderstood point in the whole cycle, and collapsing the two is where control starts to erode. A requisition is you asking your own organisation for permission to spend; a PO is your organisation telling a supplier to deliver — one internal and reversible, the other external and binding. The full breakdown is in purchase requisition vs purchase order. The key thing for the cycle is that the requisition is where spend gets proposed so the next stage can authorise it. Skip it, and you’ve skipped the place where “should we buy this?” was meant to be asked.
Stage 3: Approval
What it’s for: Authorise the spend before it becomes a commitment. A named budget holder confirms the requisition is justified, affordable, and within their authority — or routes it up if it isn’t. This is the cycle’s first hard control gate.
Who owns it: The budget holder or manager whose budget the spend lands against, usually by value threshold (a team lead up to £X, a director above it).
Approval is the gate email and spreadsheets destroy most reliably, because email has no concept of a required step. A request sent by email can be ignored, missed, actioned by the wrong person, or “approved” with a one-word reply no one can later attach to a specific order. Nothing stops a PO being raised before approval, because the approval and the PO live in different tools that don’t know about each other. The result is maverick spend: orders placed without sign-off, discovered only when the invoice lands. A real approval stage is one where the next stage physically cannot happen until this one is complete — a property email doesn’t have.
Stage 4: Purchase order raised
What it’s for: Convert the approved requisition into a purchase order — a numbered, binding document specifying exactly what’s being bought, at what price, quantity, terms, and delivery. The PO is the reference every later stage matches against, so its accuracy sets the ceiling on how well the rest of the cycle can work.
Who owns it: Procurement, or a designated buyer.
The PO is the backbone document of the cycle: everything downstream — receipt, match, payment, close — is checked against it. That’s why an error here propagates: a wrong quantity on the PO becomes a wrong delivery, which becomes an invoice that “matches” a mistake. When POs are raised in a spreadsheet, three predictable problems appear — numbers get duplicated so two orders share an identity, a PO gets edited after it’s sent so the internal and supplier copies diverge, and there’s no link back to the approval, so you can’t prove the order was sanctioned. Each quietly weakens every match that comes later.
Stage 5: PO sent to supplier
What it’s for: Formally place the order — transmit the PO to the supplier and, ideally, capture their acknowledgement of price, quantity and delivery date. The moment the supplier accepts, you have a commitment on both sides.
Who owns it: Procurement.
Sending hides a real gap: the difference between sent and acknowledged. Fire a PO into a supplier’s inbox and you know you sent it; you don’t know they saw it, agreed the price, or can hit the date. In an email-and-spreadsheet setup there’s usually no record of acknowledgement, so the first confirmation the order is even live is when the goods turn up — or don’t. This is where a PO’s status starts to matter: draft, sent, acknowledged, part-received, closed. Without a live status an order goes invisible the moment it’s sent — the exact problem a purchase order tracking system exists to solve, keeping every open PO and its state in one view instead of scattered across sent-items folders.
Stage 6: Goods received (GRN)
What it’s for: Record what physically arrived, checked against the PO, at the moment of delivery — the goods received note. This is the cycle’s reality check: the first stage dealing with what actually happened rather than what was intended. Quantities are counted, condition checked, shortages and damage noted then and there.
Who owns it: The warehouse or receiving team.
The GRN is half of the money-protection in the whole cycle, because it’s the only record of what you truly got. Captured properly — booked in against the PO, discrepancies logged at the door — the later invoice match has something honest to check against. Captured on a paper pad, a clipboard, or not at all, the match has nothing real to work with and defaults to trusting the paperwork. The disciplines that make this stage reliable — counting before signing, logging shortages immediately, matching each delivery to its PO — are the subject of the goods receiving process guide. For the cycle, the point is timing: the truth about a delivery is only fully knowable when it arrives, and a stage that records it later records a reconstruction, not a fact.
Stage 7: Three-way match
What it’s for: Verify that three documents agree before any money moves — the purchase order (what you ordered), the goods received note (what arrived), and the supplier invoice (what you’re billed). Only when all three line up, within tolerance, should the invoice be cleared for payment.
Who owns it: Accounts payable.
This is the seam of the cycle — where committing meets verifying — and where the largest, most invisible leaks live. The match catches four things at once: price creep versus the order, over-billed quantity versus the order, short delivery billed in full, and invoices for goods that never arrived. The mechanics, tolerances and failure modes are covered in three-way matching. What matters end to end is that this stage is only as good as the two documents feeding it: if stage 6 didn’t produce a real GRN, the “three-way” match quietly collapses into a two-way one — PO against invoice — and goes blind to exactly the delivery errors it exists to catch. It doesn’t fail loudly; it just approves things it shouldn’t.
Stage 8: Invoice and payment
What it’s for: Settle the verified bill. Once the invoice has passed the match, it’s approved for payment on the agreed terms, paid, and recorded. Payment should be the consequence of a passed match — never a decision made on its own.
Who owns it: Accounts payable and finance.
The failure here is subtle because it looks like success: the invoice gets paid, the supplier is happy, nothing appears wrong. But if payment isn’t gated on the match — if an invoice can be paid because it “looked right” or a supplier chased — then every control before it was theatre. Disconnected setups invite this constantly: the invoice arrives by email, someone glances at it, it feels familiar, it gets paid, and it was never held against the PO or the GRN. Duplicate invoices get paid twice; invoices for cancelled orders sail through. The whole earlier cycle existed to make this payment safe — paying outside the match throws that away at the last step.
Stage 9: Close the order
What it’s for: Reconcile and formally close the PO once it’s fully received and paid, so it stops counting as an open commitment — ordered, received and paid all agree and nothing is outstanding.
Who owns it: Procurement or finance.
Closing is the stage everyone forgets, and its absence is why so many businesses can’t answer a simple question: what have we got on order right now? If POs are never closed, your list of “open” orders fills with ghosts — orders long delivered and paid but never marked done, part-deliveries where the balance was quietly cancelled, orders superseded and abandoned. That polluted list then corrupts stage 1 of the next cycle, because you can’t judge what to reorder when you can’t trust what’s already on the way. Closing isn’t housekeeping; it keeps the cycle honest for the next turn.
Where the cycle breaks in email and spreadsheets
Step back and the pattern is unmistakable: the cycle doesn’t break randomly. It breaks at the joins — the handoffs between stages — and worst at the control gates, because email and spreadsheets can store information but cannot enforce a sequence. A spreadsheet will happily hold a PO that was never approved; an inbox will happily lose a requisition. Nothing in either tool can say “you may not do stage 4 until stage 3 is complete,” and that missing enforcement is the whole problem.
Here’s the same cycle read as a list of failure points:
| Stage | How it breaks when disconnected |
|---|---|
| Need | Ordered blind — no view of current stock or open POs, so you double-order or run out |
| Requisition | Skipped entirely; the ask goes straight to a supplier with no internal record |
| Approval | Missed, ignored, or done by the wrong person — no gate stops an unapproved PO |
| PO raised | Duplicate numbers, edited-after-sending, no link to the approval |
| PO sent | Sent but not acknowledged; goes invisible the moment it leaves the outbox |
| Goods received | Booked on paper or not at all; accounts payable never sees what really arrived |
| Three-way match | Collapses to two-way because the GRN isn’t in the system; delivery errors slip |
| Invoice & payment | Paid on a glance, not on a match; duplicates and cancelled-order bills clear |
| Close | POs never closed; the open-order list fills with ghosts and misleads the next cycle |
Notice that no single failure here is dramatic. Each is small, plausible, and individually too minor to chase. That’s exactly why the disconnected cycle is dangerous: the leaks are quiet, they don’t trigger errors, and they never appear as a line in any report. They surface only as a cost of goods that’s stubbornly higher than it should be, a supplier statement that won’t reconcile, or a stockout of something you were sure you’d ordered. The tools didn’t fail — they’re filing cabinets being asked to do the job of a control system.
How an owned system controls the whole cycle
The fix isn’t a better spreadsheet or a tidier inbox — it’s making the whole cycle live on one record, so the joins that break today become impossible to skip. This is the gap OpsMavix builds for: businesses too messy for spreadsheets but not ready for a full ERP, where every stage already exists but lives in a different tool that doesn’t talk to the next one. On one record the cycle stops being nine disconnected chores and becomes one controlled flow:
- The need can fire itself. Stock and open orders sit in one view, so a reorder point raises the requisition before anyone runs out — or double-orders something already on its way.
- Approval is a real gate. The requisition routes to the right budget holder by value, and a PO physically cannot be raised until the approval exists. Maverick spend becomes impossible, not merely discouraged.
- The PO is one authoritative record. Numbered once, linked to its approval, versioned so internal and supplier copies can’t diverge, with a live status from draft to closed.
- The GRN is captured at the door, against the PO. Receiving books goods in on the same record the order lives on, so accounts payable sees what arrived the moment it arrives.
- The three-way match runs itself. Because PO, GRN and invoice share one record, the system holds them against each other within your tolerances. Clean invoices clear; only genuine disagreements reach a human.
- Payment is gated on the match, and close is automatic. Nothing pays before it’s proven, and a fully received-and-paid PO closes itself, keeping the open-order list honest for the next cycle.
The stages don’t change — it’s the same nine. What changes is that the handoffs stop depending on someone remembering. In a disconnected setup the cycle is held together by human diligence at every join, and diligence fails predictably on a busy week. In an owned system the joins are the structure: you can’t raise a PO without an approval, can’t match without a receipt, can’t pay without a match. The control isn’t a chore anyone performs — it’s a property of how the cycle is built. That’s the difference between a process that documents your spend and one that controls it, and it’s the principle behind running a whole wholesale order management system as one connected flow rather than a stack of spreadsheets that each know only their own step.
FAQ
What is the purchase order cycle?
The purchase order cycle, also called procure-to-pay, is the full sequence a business runs to buy goods or services and settle the bill: a need is identified, a requisition is raised and approved, a purchase order is created and sent to a supplier, the goods are received and recorded, the invoice is matched against the order and the receipt, payment is made, and the order is closed. Each stage is a control gate against a specific risk, and the cycle exists so no money leaves the business until every earlier stage has confirmed it should.
What are the stages of the procure-to-pay process?
The common stages are: need identified, purchase requisition, approval, purchase order raised, PO sent to supplier, goods received (on a goods received note), three-way match, invoice and payment, and close. Some businesses merge or split a few — combining need and requisition, or adding supplier selection — but the logic is the same: propose the spend, authorise it, commit it to a supplier, verify what arrived, check the bill against both, pay, and close.
What is the difference between a requisition and a purchase order?
A purchase requisition is an internal request to spend — one employee asking their own organisation for permission to buy. A purchase order is an external, binding document that tells a supplier to deliver. The requisition comes first and triggers the approval; the PO comes after approval and creates the commitment. Collapsing the two removes the approval gate, which is why the distinction matters for controlling spend.
Where does the purchase order cycle usually break down?
At the joins between stages, not within them, and worst at the control gates. The most common failures are approvals being skipped because email can’t enforce a required step, goods receipts never reaching accounts payable so the invoice match goes blind, and invoices being paid on a glance rather than on a verified three-way match. Each failure is small and invisible, which is why disconnected cycles leak quietly rather than fail loudly.
Why does three-way matching depend on the rest of the cycle?
Three-way matching checks the purchase order, the goods received note and the invoice against each other, so it only works if the earlier stages produced accurate documents. If the PO carried a wrong quantity, or goods receipt was never recorded where accounts payable can see it, the match has nothing honest to check against and quietly collapses into a weaker PO-versus-invoice check — going blind to the short and missing deliveries it exists to catch.
Do small businesses need the full purchase order cycle?
The stages don’t disappear at small scale — every business still identifies needs, orders, receives, checks bills and pays — but the formality can be right-sized, with one person owning several stages. The risk is running it entirely on memory and email, because that’s where approvals get skipped and invoices get paid unchecked. The goal isn’t more bureaucracy; it’s making sure each control gate actually happens, which an owned system enforces without adding manual steps.