ProcureWave Book a demo
PURCHASE ORDERS

The Purchase Order Process: Stages and Flowchart

Twelve stages from need to closure, with the owner, the output and the common failure at every step.

The Purchase Order Process: Stages and Flowchart
Photo by Tima Miroshnichenko on Pexels

Every organisation buys things, and almost every organisation describes the way it buys things as straightforward. Then an invoice arrives that nobody recognises, or a delivery turns up against an order that was never approved, and it becomes clear the process is not as tidy as the diagram suggests. This guide walks the purchase order process from the first sign of a need to the moment the order is closed, naming who owns each stage, what it produces, and the failure that shows up most often.

Key takeaways

  • The purchase order process runs in twelve recognisable stages, from need identified through to PO closed.
  • Every stage has an owner and an output; where either is unclear, that is where the process breaks.
  • Most invoice disputes are caused three or four stages earlier, usually at ordering or goods receipt.
  • Automation pays back fastest on approval routing, matching and open order visibility, not on document design.

What the purchase order process actually is

The purchase order process is the chain of steps that turns a business need into a paid supplier invoice, with a purchase order acting as the control document in the middle. It is deliberately linear because each stage exists to make the next one safe: you approve before you commit, you commit before you receive, and you receive before you pay.

It is worth separating two things that often get muddled. The process is the sequence of activities and handoffs. The policy is the written rule set that governs it, including thresholds, delegated authority and the handful of documented exceptions. If you are drafting or refreshing the written rules, the purchase order procedure guide deals with that document specifically. This article is about the flow itself.

The other thing worth saying early: the process does not disappear when an organisation is small. A two person firm still identifies a need, decides it is affordable, picks a supplier, orders, checks what arrived and pays. The stages are simply compressed into one person's head. Problems begin when the organisation grows past the point where that person can hold all of it, and nobody has written down what they were doing.

The purchase order flowchart, described

Picture the flow as a single vertical line with three decision points branching off it. At the top sits the trigger: a need identified inside the business. The line runs down into a requisition, which feeds a budget check. That is the first diamond on the chart, and it has two exits. If funds are unavailable the requisition returns to the requester for revision, deferral or a business case. If funds are available it continues to approval.

Approval is the second diamond. Rejected requisitions loop back up to the requester with a reason; approved ones move down into supplier selection. From there the line straightens out for a while: the purchase order is created, issued to the supplier, acknowledged, and the goods or services are delivered. Delivery feeds a goods receipt, and the receipt joins the invoice at the third and final diamond, the three-way match.

That last diamond is the one worth drawing carefully. A clean match exits downward to payment and then to order closure, which ends the chart. A failed match exits sideways into an exception loop, where the variance is investigated and resolved by amending the receipt, querying the invoice, or requesting a credit note, and the resolved item rejoins the main line. Almost every purchase order flowchart you will see is this shape; the differences between organisations are in how many approval diamonds sit in the middle and how the exception loop is staffed.

The twelve stages at a glance

The table below sets out the full sequence with the owner, the output and the failure mode that surfaces most frequently at each point. Read the failure column first if you are diagnosing an existing process; it is usually faster than reading the process description itself.

#StageWho does itWhat it producesCommon failure
1Need identifiedRequesting departmentA defined requirementVague specification, or a need invented to spend a budget
2Requisition raisedRequesterPurchase requisitionMissing quantity, date or cost centre, so it stalls in review
3Budget check and approvalBudget holder, financeApproved requisitionApproval by email outside the system, leaving no audit trail
4Supplier selectionProcurementChosen supplier and agreed priceDefault to a familiar supplier, ignoring existing contracts
5PO created and issuedProcurement or systemPurchase order sent to supplierPrices and units copied incorrectly from the quote
6Supplier acknowledgementSupplierOrder confirmationNo reply chased, so a changed date or price goes unnoticed
7Goods or services deliveredSupplierDelivery note or completed workDelivery accepted at the door with no reference to the PO
8Goods receipt recordedGoods-in, or service requesterGoods received noteReceipting delayed for days, or skipped for services entirely
9Invoice receivedSupplier, accounts payableSupplier invoiceInvoice arrives without a PO number and cannot be routed
10Three-way matchAccounts payableMatched, approved invoiceHigh exception volume caused by errors made at stages 5 and 8
11PaymentFinanceSettled invoiceLate payment through query backlog, losing early settlement terms
12PO closedProcurement or systemClosed order, released commitmentOrders left open indefinitely, distorting committed spend

Stages one to four: from need to an approved supplier

The opening stages decide whether the rest of the process has anything sensible to work with. A need is identified by whoever has it: a department running low on consumables, a project needing a contractor, an engineer whose machine has failed. The output should be a requirement clear enough that somebody else could buy it, which is a higher bar than most requisitions clear on the first attempt.

The requisition converts that need into a document, and the quality of the document sets the pace of everything downstream. Quantity, unit of measure, required-by date, cost centre and a usable description are the minimum. Incomplete requisitions do not fail loudly; they sit in a queue while somebody works out what was meant, and the delay is then blamed on procurement.

Budget check and approval follow. These are two separate questions that often get collapsed into one: can we afford it, and should we buy it? The first is a finance test against available funds. The second is a judgement by a budget holder whose delegated limit covers the value. Approving by email or verbally is the single most common control weakness in the whole flow, because it separates the decision from the record.

Supplier selection is where procurement adds most of its value, and it is also where it is most often bypassed. If a contract or framework already covers the item, the choice is made and the job is to apply it. If not, the effort should scale with value and risk: a quick check for low value items, competitive quotes in the middle, and a structured tender at the top.

Stages five to eight: ordering, acknowledgement and receipt

With approval and a supplier in place, the purchase order is created and issued. This is the moment a commercial commitment is made, so accuracy matters more here than anywhere else in the flow. Prices, units of measure, delivery address, delivery date and payment terms transcribed correctly at this stage prevent a queue of exceptions two months later. Transcribed carelessly, they guarantee one.

Acknowledgement is the stage most often skipped. A purchase order that has been sent is an offer; until the supplier confirms it, nothing is agreed. Confirmations that quietly revise a date or a price are counter-offers, and if nobody reads them the difference reappears as an invoice mismatch long after the goods have been consumed. Set an acknowledgement window with your main suppliers and chase silence.

Delivery and goods receipt are two different things, and treating them as one causes a large share of accounts payable pain. Delivery is the supplier's act. Goods receipt is yours: a recorded confirmation of what actually arrived, against which line, on what date. Where the purchase is a service rather than goods, the equivalent is confirmation that the work was completed, and it usually has to be requested from the person who received it rather than captured at a loading bay.

Stages nine to twelve: invoice, match, payment and closure

The supplier invoice arrives and enters accounts payable. The first requirement is simply that it carries a PO number, because without one it cannot be routed and has to be identified by hand. Suppliers will comply if the expectation is set at onboarding and enforced consistently.

The three-way match then compares order, receipt and invoice. A clean match releases the invoice for payment without human involvement, which is the whole point. Exceptions should be triaged rather than queued: small price differences inside an agreed tolerance auto-approved, quantity differences routed to goods-in, and genuine commercial disputes escalated to the buyer who placed the order.

Payment follows the agreed terms, and closure follows payment. Closure is the stage most likely to be forgotten because nothing breaks when it is missed, at least not immediately. What breaks is reporting: committed spend that has already been settled stays on the books, open order lists grow into the hundreds, and accruals at period end become guesswork. The wider discipline of running orders after issue is covered in the purchase order management guide.

Almost no problem in this process originates where it is discovered. A matching exception is usually an ordering error or a missing goods receipt. A late payment is usually an invoice that arrived without a PO number. An angry supplier is usually an order nobody acknowledged. Fix the stage that created the problem, not the stage that surfaced it, or you will spend forever staffing an exception queue that never shrinks.

Best practices that make the process hold

The practices below are the ones that separate a process that survives growth from one that quietly reverts to email and goodwill.

  • No PO, no pay. State it plainly, tell suppliers at onboarding, and apply it. A rule with routine exceptions is not a rule, and every exception teaches people that the process is optional.
  • One owner per stage. Every stage in the table should have a named role accountable for it. Shared ownership means an unattended queue during holidays and handovers.
  • Approve inside the system. Approvals that live in inboxes cannot be audited, reported on or reconstructed when the approver has left.
  • Receipt on the day. Same-day goods receipting is the single highest-leverage habit in the flow, because stages nine to eleven all depend on it being accurate.
  • Set tolerances deliberately. Agree the price and quantity variance you are willing to auto-approve, and use the same figure at receipting and at matching.
  • Review open orders monthly. Age the open PO list, challenge anything past ninety days, and short-close orders that will never be completed.
  • Measure the flow, not the people. Track requisition-to-PO time, acknowledgement rate, match rate and exception causes. Those four numbers tell you where the process is actually failing.

Where automation helps most

Automation is not equally useful at every stage, and buying software to fix a process nobody has agreed on simply produces faster confusion. The stages that repay automation first are the ones with high volume, clear rules and no judgement required.

Approval routing comes first. Rules based on value, category and cost centre send each requisition to the right approver without anyone chasing, and the audit trail is created as a by-product rather than as an extra task. Matching comes second: automated three-way matching with sensible tolerances clears the routine majority silently and presents only the genuine exceptions, with the supporting documents already attached.

Visibility comes third and is easy to underrate. A live view of open orders by age, by supplier and by budget holder turns period end from an archaeology exercise into a report. Platforms such as ProcureWave connect requisition, order, receipt and invoice on one record, so the history of a purchase can be read in one place instead of being reassembled from three systems and a mailbox.

What automation will not do is decide your thresholds, define your approval limits or persuade a department to stop ordering by phone. Those remain design decisions, and they are worth making before the software arrives rather than after. If you are mapping your own flow and want a second opinion on where it is leaking time, get in touch and we will happily talk it through.

Frequently asked questions

What are the stages of the purchase order process?

The usual sequence is: need identified, requisition raised, budget check and approval, supplier selection, PO created and issued, supplier acknowledgement, goods or services delivered, goods receipt recorded, supplier invoice received, three-way match, payment, and finally the PO is closed. Smaller organisations merge a few of these, but none of them disappear; they just happen informally.

What is the difference between the purchase order process and a purchase order policy?

The process is the sequence of steps and handoffs that turns a need into a paid invoice. The policy is the written document that sets the rules the process must follow, such as thresholds, approval limits and exceptions. You need both, and they should describe the same thing. Our purchase order procedure guide covers the written document in detail.

Who raises a purchase order and who approves it?

The requisition is normally raised by the person with the need, such as a department manager, site supervisor or project lead. Approval sits with a budget holder whose limit covers the value, and above certain thresholds a second approver or a procurement review is added. The PO itself is created and issued by procurement or by the system once approval is complete.

What is a three-way match and why does it come so late in the process?

A three-way match compares the purchase order, the goods received note and the supplier invoice before payment is released. It sits late because it is the final control: it can only run once all three documents exist. If earlier stages were done well the match passes silently, which is why most matching problems are really receipting or ordering problems.

When should a purchase order be closed?

Close a PO when every line has been fully received, matched, invoiced and paid, or when the balance will never be delivered. Leaving orders open inflates committed spend and clutters reporting, so most teams review open orders monthly and short-close anything that is finished in practice but not in the system.

Want to see this in your own numbers?

Book a tailored demo and we will show ProcureWave running on scenarios that match your business.

Get in touch