The Procure to Pay Process: Stages and Flowchart

The procure to pay process is the chain of steps that turns a request to buy something into a paid supplier invoice. Each stage has its own owner, its own document and its own control, and the handovers between them are where most of the delay and error lives. This guide walks through the flow stage by stage, sets out a flowchart you can map onto your own organisation, and shows what good practice and automation look like at every individual step.

The process at a glance

Procurement covers everything an organisation does to acquire goods and services. Procure to pay is the operational slice of that: the transactional path from a recognised need to a settled payment. If you want the definitions, the strategic context and how procure to pay sits alongside sourcing and supplier management, start with our procure to pay guide. This article assumes you already know what the process is and goes straight into how each stage actually runs.

The useful way to read the flow is as a relay. Nothing in procure to pay is difficult in isolation. Raising a requisition takes a few minutes, approving it takes seconds, checking a delivery takes as long as it takes to count boxes. What makes the end to end cycle stretch to weeks is the baton being dropped between runners: a requisition sitting unread, a purchase order that never reached the supplier, an invoice that cannot be matched because nobody recorded the receipt. Fixing procure to pay is mostly about fixing handovers.

The procure to pay flowchart described

Picture the flowchart as a single vertical spine with two decision diamonds branching off it. At the top sits a rounded start box labelled need identified. An arrow drops into the first rectangle, raise requisition, which feeds a diamond: approved? A no branch loops left, back to the requester for amendment or rejection. A yes branch continues down the spine.

Below the approval diamond the spine splits briefly. High value or non-catalogue items divert right into a sourcing box, where quotes are gathered and a supplier is chosen, before rejoining the spine. Catalogue and contracted items skip straight past. The two paths merge into issue purchase order, which sends an arrow out of the process boundary to the supplier and receives goods or services back.

The next rectangle is record goods receipt, then receive supplier invoice. Those two feed the second diamond, three-way match, which compares the purchase order, the receipt and the invoice. A no branch routes to an exception queue for investigation and returns to the match once resolved. A yes branch drops into approve for payment, then pay supplier, and finally into a rounded end box, record archived. The archive arrow curls back to the top as a dotted feedback line, because every completed cycle is spend data that informs the next one. That loop is why the flow is also described as the procure to pay cycle.

The stages mapped

The table below maps each stage against the five things worth knowing about it: what happens, who does it, the document it produces, the control it carries and the delay it typically adds in a manual process. Typical delays are drawn from organisations running on email and spreadsheets rather than a connected system.

Stage one and two: need and requisition

The process begins when somebody needs something. In a mature organisation that need is tested before it becomes a request: is there stock already, is there a contracted supplier, is this within plan? The output is a purchase requisition, an internal document that names the item, the quantity, the estimated cost, the budget code and the business reason. The requisition never leaves the organisation. Its job is to make the intention to spend visible before the money is committed.

Approval follows immediately. A budget holder confirms the need is genuine, the estimate is reasonable and the budget exists, then signs off within their delegated authority. This is the single most important control in the entire process because it is the last point at which spend can be stopped cheaply. Once a purchase order goes out, the organisation is committed.

It is also the slowest stage in most manual processes. Approvers travel, take leave and receive hundreds of emails, so a request that takes ten seconds to judge can sit for a week. The fix is structural rather than motivational: publish an approval matrix so requesters know exactly who signs what, set value thresholds so small purchases do not need senior attention, and route requests to a named deputy automatically when the primary approver is unavailable.

Stage three and four: sourcing and the purchase order

Not every approved requisition needs sourcing. Catalogue items and goods covered by an existing contract go straight to order. Everything above a set value threshold, or outside any agreement, needs quotes: usually three, compared on total cost rather than headline price, with the choice documented. Sourcing is the stage with the widest variation in duration because it depends on suppliers responding, and it is where the real savings in procurement are made.

The approved and sourced request then becomes a purchase order: the formal, numbered instruction sent to the supplier. Once the supplier accepts it, the order is contractually binding and the budget is committed. That PO number becomes the thread running through everything that follows, so the receipt and the invoice can both be tied back to what was actually agreed. Our purchase order guide covers the document itself in detail.

Stage five and six: receipt, invoice and matching

When goods arrive, somebody must check them against the order and record what was actually received. That record, the goods received note, is the quiet workhorse of the whole process. Without it there is no independent confirmation that the organisation got what it is about to pay for, and the match at the next stage collapses into a two-way comparison that catches far less. Services are harder because there is no pallet to count, so a named person should confirm the milestone or timesheet instead.

Accounts payable then receives the supplier invoice and performs the three-way match. Five elements make that match work:

• Purchase order. What was ordered, at what quantity and what agreed price.
• Goods received note. What actually arrived, and in what condition.
• Supplier invoice. What is being billed, including tax, freight and any adjustments.
• The tolerance. A small permitted variance, often one or two per cent, that lets trivial rounding differences pass without human review.
• The exception path. A defined route, owner and deadline for anything that fails the match, so disputed invoices do not simply age.

Where all three agree, the invoice is approved for payment. Where they do not, the exception is investigated: short delivery, price change, duplicate invoice, or an unrecorded receipt. Most exceptions in practice are not supplier errors but missing internal data, which is why chasing goods receipt discipline pays back faster than chasing suppliers.

Stage seven: payment and the audit record

Approved invoices join a payment run scheduled against agreed terms. Two things matter here. The first is segregation of duties: the person who approves an invoice must not be the person who releases the money, and supplier bank details must only be changed through a verified, separately authorised route. Payment redirection fraud almost always targets this exact point.

The second is timing. Paying too late damages supplier relationships and forfeits early settlement discounts; paying too early costs working capital for nothing. A clean process gives you the choice, because invoices are approved quickly enough that the payment date becomes a deliberate decision rather than an accident of how long the paperwork took.

Finally the record is filed. Requisition, approval, order, receipt, invoice and remittance should be retrievable together against one reference. That bundle is what an auditor asks for, and assembling it after the fact from four systems and three inboxes is where finance teams lose weeks.

Best practice at each stage

Rather than a generic improvement programme, apply a specific discipline to each stage:

Across all of them, measure the process rather than guessing at it. Cycle time per stage, first-time match rate, percentage of spend under purchase order and cost per invoice will tell you within a fortnight where your real bottleneck sits. It is rarely where people assume.

How automation compresses each stage

Automation does not make people work faster. It removes waiting and re-keying, which is where the time actually goes. At the requisition stage, catalogues and templates cut entry to a few clicks and validate the budget code up front. At approval, requests route to the right person by rule, arrive on their phone and escalate on a timer, which typically collapses days into hours and is the largest single saving available.

At sourcing, quote requests go to multiple suppliers at once and responses land in a comparable format. At the purchase order stage the approved request converts into a numbered order with no retyping, and reaches the supplier immediately. Receipts are recorded against the order from a phone at the point of delivery. Invoices are captured, read and matched automatically, so accounts payable only sees genuine exceptions instead of every document. Payment then runs from an approved queue on schedule, and the full audit trail assembles itself as a by-product.

ProcureWave connects those stages so the requisition, the order, the receipt and the invoice all live against one reference and move without anyone re-entering data. The point is not the individual features but the elimination of the handovers described at the start of this guide. If you would like to see the process mapped against how your own organisation buys, talk to our team.

Procure to pay is not complicated, but it is unforgiving of gaps. Know what happens at each stage, who owns it, what document it produces and what control it carries, and you can see exactly where your own process leaks time. Close the handovers first, automate the longest queue next, and the rest of the flow tends to tidy itself up behind you.

Frequently asked questions

What are the stages of the procure to pay process?

Most organisations run six stages: identify the need and raise a requisition, approve it, issue a purchase order, receive the goods or services, match and approve the supplier invoice, then pay and file the record. Larger buys add a sourcing step between approval and the purchase order.

Who owns each stage of procure to pay?

Ownership is shared. The requester and their budget holder own the need and the approval, procurement owns sourcing and the purchase order, the receiving team or site owner confirms delivery, and accounts payable owns matching, payment and the audit record. Problems usually appear at the handovers rather than inside a stage.

Where does the procure to pay process usually slow down?

Two places dominate: waiting for approval on the requisition, and resolving invoice mismatches. Both are queue problems rather than work problems. The invoice itself takes minutes to check; it is the days it spends sitting in an inbox waiting for a decision that create the delay.

What is the difference between the procure to pay process and the procure to pay cycle?

They describe the same flow. Process tends to be used when talking about the discrete stages and who performs them, while cycle emphasises that the flow repeats and feeds data back into the next purchase. In practice the terms are interchangeable.

How much of procure to pay can be automated?

Nearly all of the routing, data entry and checking. Software can move requisitions to approvers, convert an approved request into a purchase order without re-keying, capture invoice data, perform the three-way match and schedule payment. Humans stay in the loop for judgement calls: approving spend, choosing suppliers and clearing genuine exceptions.