Purchase order process map

What is in this map

19 steps across 5 swimlanes and 5 phases, with 4 decision points.

Swimlanes (who does the work)

Requester, Department manager, Finance / AP, Procurement and Supplier

Phases (left to right)

Requisition, Approval, Sourcing, PO and receipt and Invoice and payment

Why map this process

Nearly every purchasing problem is a sequencing problem. Someone orders before the requisition is approved, an invoice arrives for goods no one recorded receiving, a PO is raised after the fact to make the paperwork match. Written as a list, all of those look like discipline failures. Drawn in lanes with the supplier included, they look like what they are: points where the informal path is faster than the mapped one, which is a design problem you can fix.

The three-way match at the end only works if the three documents are created by three different steps in the right order. Putting the PO, the goods receipt and the invoice on one page, each in the lane that produces it, is the shortest way to explain to a new starter why raising a PO after the invoice defeats the entire control.

Every step in the map

This is the spreadsheet behind the diagram. The numbers in “Goes to” are row numbers, which is exactly what the editor’s “Line to” column holds — so you can read the flow here and retype any part of it.

The decision points

Every branch in the map, with the label on each outgoing line. These are the questions the process has to be able to answer.

• 3. Manager **approves** requisition?

  Owned by Department manager · Approval

  • Yes → step 4
  • Revise → step 2

• 4. Budget available?

  Owned by Finance / AP · Approval

  • Yes → step 6
  • No → step 5

• 6. Value over **approval threshold?**

  Owned by Finance / AP · Approval

  • Yes → step 7
  • No → step 8

• 16. **PO, GRN and invoice** match?

  Owned by Finance / AP · Invoice and payment

  • Match → step 18
  • Mismatch → step 17

Notes on specific steps

These notes travel with the map. In the editor they live in the Notes column and appear when you open a box.

2. Raise **purchase requisition**

Capture cost centre, GL code, quantity, need-by date and any preferred supplier here. Requisitions missing coding are the biggest single cause of approval delay.

4. Budget available?

Check committed spend (open requisitions and open POs), not just posted actuals, or the cost centre will look healthier than it is.

6. Value over **approval threshold?**

Set this from your delegation of authority schedule, for example manager up to **5,000** and finance director above it. State the currency.

16. **PO, GRN and invoice** match?

Agree a tolerance before go-live, for example **2 percent or 50** on price and quantity, so trivial variances do not block payment.

Making it yours

The approval threshold is the row to edit first: it is a Decision whose branches send low-value requests straight to the PO phase and high-value ones through additional approval. Put your actual currency thresholds in the Line text column so the branch labels read '< 5,000' and '≥ 5,000' rather than 'Yes' and 'No': a branch label that names the rule is the difference between a diagram people follow and one they interpret.

What to watch out for

• If you drop the supplier lane, the map will suggest that sourcing and delivery are instantaneous. Keep it even if you have no visibility into what the supplier does: an empty-looking lane with two boxes is an accurate statement about where your process loses time.
• Emergency and low-value purchases need a mapped route, not an exception. Every company has one; the ones that have not drawn it have an unmapped process running alongside the mapped one, carrying exactly the spend nobody reviews.
• Receipt is not the same as acceptance. Goods can arrive, be recorded, and later be rejected on inspection; if your map has a single receiving box, the return path has nowhere to attach.

Frequently asked questions