Process maps of procure to pay usually show a clean sequence of boxes and hide the thing that actually determines how the cycle performs, which is who owns each step and where the baton changes hands. A map drawn with swimlanes for purchasing, receiving and payables shows immediately that one step sits in a lane nobody staffed.
Three lanes, not one line
Purchasing owns the request, the approval and the order. Receiving owns recording what arrived. Payables owns the invoice, the match, the approval and the payment. Drawing it this way makes the two handoffs visible as boundaries rather than as arrows, and boundaries are where things are dropped.
The lane that is usually empty
Receiving. In most organisations nobody is formally responsible for recording deliveries: it is done by whoever is at the door, if they remember, or batched later by somebody in an office who was not there. Drawing the lane and finding it unstaffed is often the most useful five minutes of a mapping exercise.
What to write on each handoff
What is passed, in what form, and how long it takes. The gap between a delivery arriving and its receipt being recorded is usually the largest unmeasured delay in the whole cycle, and simply putting a number on it in the map tends to produce action where general discussion has not.
Questions people ask about procure to pay process map
How detailed should the map be?
One page with three lanes. Detail beyond that describes system screens and dates as soon as the software changes.
Should exceptions be on the map?
Yes, at least the four main branches with their owners. A map showing only the clean path describes the minority of the effort.
Who should draw it?
All three lanes together, which is often the first time they have discussed the handoffs explicitly.