Procure-to-pay process map

What is in this map

26 steps across 6 swimlanes and 6 phases, with 8 decision points.

Swimlanes (who does the work)

Requester, Budget holder, Procurement, Supplier, Accounts payable and Finance

Phases (left to right)

Requisition, Approval, Sourcing and PO, Receipt and invoice, Match and exceptions and Payment and reporting

Why map this process

P2P is the process most often owned by nobody. Procurement owns sourcing, finance owns payment, the requester owns the need, and the parts in between belong to whoever last complained about them. That is why it is worth mapping end to end even though no single team will ever run the whole thing: the map is the only artefact that shows the cycle as one process rather than as four departmental ones that happen to touch.

The exception phase is the reason to draw it at this size. Everyone understands the happy path. What separates a functioning P2P cycle from a painful one is what happens when quantities do not match, when a price differs from the PO, when goods arrive against no order at all, and those branches only make sense next to the path they diverge from.

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. Funds available in the cost centre?

  Owned by Budget holder · Approval

  • Yes → step 4
  • No → step 5

• 4. Above the **delegated authority limit?**

  Owned by Budget holder · Approval

  • Above → step 6
  • Within → step 7

• 7. **Contract or framework** in place?

  Owned by Procurement · Sourcing and PO

  • Yes, call off → step 9
  • No, go to market → step 8

• 13. Purchase order referenced?

  Owned by Accounts payable · Match and exceptions

  • PO quoted → step 14
  • No PO → step 19

• 14. Goods or service receipt recorded?

  Owned by Accounts payable · Match and exceptions

  • Recorded → step 15
  • Missing, chase it → step 11

• 15. Three-way match **within tolerance?**

  Owned by Accounts payable · Match and exceptions

  • Within tolerance → step 22
  • Outside tolerance → step 16

• 18. Exception resolved?

  Owned by Accounts payable · Match and exceptions

  • Resolved, re-match → step 15
  • Still disputed → step 21

• 19. *Retrospective PO* authorised?

  Owned by Budget holder · Match and exceptions

  • Authorised → step 20
  • Refused → step 25

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 a requisition with coded specification

Most of the rework in this cycle is created here. A requisition that names a product without a quantity, a delivery date or a cost centre cannot be turned into a purchase order, and it comes back days later by email rather than through the system, so the return trip never appears in cycle-time reporting. Make the fields mandatory at entry: specification, quantity, need-by date, cost centre, GL code and the contract reference where one exists.

4. Above the **delegated authority limit?**

The delegated authority limit is not the same thing as the budget. Budget says the money was planned; delegation says this person may commit the organisation to it. Publish the schedule as figures by role, state whether the test is the order value or the whole-of-life contract value, and say explicitly what happens to a requirement split into two under-limit orders, because splitting to avoid the next signature is the most common abuse of the control.

7. **Contract or framework** in place?

This is the fork between a call-off and a sourcing exercise. Where an approved contract or framework already covers the requirement the buyer places an order against it and the cycle stays short; where it does not, the requirement goes to market and weeks appear. The risk is the fast path quietly becoming the default, so record the contract reference on the purchase order and report the proportion of spend placed off-contract every quarter.

13. Purchase order referenced?

This is the no-PO-no-pay gate. An invoice with no purchase order has nothing to match against: no agreed price, no commitment in the ledger and no evidence that anybody authorised the spend. The policy only works if there is a defined exception route, otherwise the desk quietly raises a retrospective order to clear the backlog and the control becomes paperwork. Decide which categories are genuinely exempt, such as utilities, rent and statutory fees, and exclude them here rather than case by case.

14. Goods or service receipt recorded?

Receipting is where end-to-end cycles break, because nobody is measured on it. Goods get a receipt on the dock; services frequently get nothing, so the invoice arrives with nothing to match against. This block is an internal failure rather than a supplier one, and returning the invoice to the supplier achieves nothing: the remedy sits with the requester who asked for the work. Give that confirmation a deadline measured from the order's expected completion date, because an unreceipted order is an unrecorded liability as well as a blocked invoice.

15. Three-way match **within tolerance?**

State the tolerance as figures rather than as "minor differences". Most organisations set a percentage and an absolute cap on price and apply whichever is lower, hold quantity to a tighter tolerance than price, and treat carriage, duty and rounding separately because they break the match far more often than the goods do. Anything inside tolerance posts without a human; anything outside becomes an exception with an owner and an age. A tolerance nobody wrote down is applied differently by every clerk.

19. *Retrospective PO* authorised?

A retrospective purchase order is a confession rather than a correction. It should be authorised by the budget holder who would have approved the original requisition, never by accounts payable, and it should be logged against the requesting cost centre so the pattern is visible. Report the number and value monthly by department. The point is not to refuse every one, because some are genuine emergencies, but to make the exception cost somebody a conversation.

24. Update the vendor and spend records

The cycle does not end when the money leaves. Close it in the data: confirm the vendor record still holds the right payment terms and remittance details, record delivery and invoice accuracy against the supplier, and file the spend under the contract it was placed against. What comes out of this is the report that makes the next sourcing round evidence-based: off-contract spend, first-time match rate, retrospective orders and requisition-to-payment cycle time by category.

Making it yours

Do not adapt this in one sitting. Take one phase at a time and check it against reality with the team that owns that lane; the requisition and approval phases usually survive contact, and the match and exception phases usually do not. When a lane turns out to be two roles in your company, split it: a lane that contains two roles is a lane that cannot show a handover, and handovers are what this map exists to expose.

What to watch out for

• Six lanes is close to the readable limit. If you find yourself adding a seventh and eighth, that is usually a sign the map should be split into a sourcing map and a settlement map that share the PO as a boundary object.
• Supplier onboarding is a separate process that this one depends on. Reference it as a single step rather than inlining it, or the map will grow a second beginning.
• The reporting steps at the end are not decoration. They are where the cycle's own metrics come from, and teams that trim them end up with a mapped process they cannot measure.

Frequently asked questions