Procure-to-pay BPMN diagram example
Procure-to-pay (P2P) is the full purchasing cycle from requisition to supplier payment. It's a strong BPMN example because it spans internal approval and external supplier interaction, and hinges on the classic three-way match.
The process in plain English
An employee raises a purchase requisition. It's approved based on amount and budget. A purchase order goes to the supplier, who delivers the goods. On receipt, finance matches the purchase order, goods receipt and supplier invoice (the three-way match). If they agree, payment is made; if not, the discrepancy is investigated.
Steps and their BPMN elements
| Step | BPMN element | Lane / pool |
|---|---|---|
| Requisition raised | Start event | Requester |
| Approve requisition | User task | Manager |
| Within budget? | Exclusive gateway | Finance |
| Issue purchase order | Service task | Procurement |
| (Supplier delivers goods) | Message flow → Supplier pool | Supplier |
| Record goods receipt | User task | Warehouse |
| Three-way match OK? | Exclusive gateway | Finance |
| Investigate discrepancy | User task | Finance |
| Pay supplier | Service task | Finance |
| Payment complete | End event | — |
Key modelling points
- Model the supplier as a separate pool connected by message flows — a textbook case for two pools.
- The three-way-match gateway is the control point; its "no" branch is where exceptions live.
- Budget and match checks are separate gateways — don't merge unrelated decisions.
Generate your own P2P diagram
Describe your procurement approvals and matching rules to BPMN Studio for an editable BPMN 2.0 diagram. More templates · pools and lanes.
Frequently asked questions
How do you model procure-to-pay in BPMN?
Model P2P as a requisition start event, an approval gateway, a purchase-order service task sent to the supplier (often a separate pool), a goods-receipt task, a three-way-match exclusive gateway comparing PO, receipt and invoice, and a payment task. Mismatches route to an exception-handling path.