The story
Two ways to check, one limit to approve.
An invoice arrives, by post or email. Accounts payable captures it in the ERP and asks the first question: is there a purchase order? If yes, the invoice can be checked against the order and the goods receipt, the three-way match. That match is the first control step, drawn in blue: the invoice, the order and the receipt must agree before anyone approves anything. If there is no order, there is nothing to match against, and the requester, the person who ordered the service, confirms that it was received.
Both routes meet at the second gateway: is the amount above the approval limit? Below it, accounts payable releases the invoice for payment straight away. Above it, an approver looks at it. That approval is the second control step, the four-eyes principle for larger amounts. The third gateway records the approver's answer: approved invoices are released and the payment is scheduled; rejected ones go back to the requester, who clarifies with the supplier, and the invoice is returned.
Three lanes: accounts payable, who captures, matches and releases; the approver, who decides on larger amounts; and the requester, who confirms receipts and clarifies disputes. The limit itself is not in the diagram. It is a number that changes; the gateway that asks about it does not.
This is a fictional example model. A real accounts payable process would add duplicate checks, tax checks, cost centre assignment, several approval levels and payment runs. The example keeps the two things most organisations argue about: which invoices need a match, and which need a second signature.
The diagram
The model as BPMN 2.0.
Three gateways in a row of nine columns. The no branch of Above limit? runs straight along the accounts payable lane to Release for payment; everything that dips into the approver's lane is above the limit. Two blue tasks, one per control.
Elements used
What is in the model, and why.
Twelve nodes, the most of the eight examples, and still only one system. Invoice approval is a process of decisions, not of tools.
Lanes: Accounts payable, Approver, Requester
Three roles. The requester is in the model because invoices without an order cannot be checked without them. The approver is a separate lane because the four-eyes principle only works if the second pair of eyes belongs to someone else.
Gateways: Order found? Above limit? Approved?
Three exclusive gateways. The first is answered by the ERP, the second by a rule, the third by a person. Reading the three questions in a row is reading the organisation's accounts payable policy.
Control steps: Three-way match, Approve invoice
Two blue tasks. The match is a control done by accounts payable with the ERP; the approval is a control done by a person without a system. Both carry the documentation "Control step" in the .bpmn file.
System: ERP
Capture, match and release all happen in the ERP. The approver and the requester have no system under their tasks: their work arrives as a request and leaves as an answer, which in practice means email.
End events: Payment scheduled, Invoice returned
The good end sits with accounts payable, who schedule the payment. The other end sits with the requester, who sent the invoice back. Two ends, two lanes, two outcomes that can be counted apart.
Where the process waits
What to look at in an invoice model.
Invoices wait for people who have other jobs. The approver and the requester both appear in the model for a few steps each, and those steps are where the days go.
Invoices without an order
Confirm receipt depends on a requester who may be travelling, on leave or unsure what the invoice refers to. Every invoice on the no branch of the first gateway is a reminder waiting to be sent.
The approver's inbox
Above the limit, invoices wait for one person. If the limit is low, the inbox is full of invoices that do not need judgement. The second gateway is where that conversation starts.
Matches that fail
The three-way match is drawn as one task that always succeeds. In practice quantities differ, prices differ, and the invoice waits in a clarification loop that this model does not draw.
Returned invoices come back
Invoice returned is an end event here. The supplier will send a corrected invoice, and the process starts again from the top. Whether the second run remembers the first is a question for the ERP.
Request the file
The model as a .bpmn file.
The file is a fictional example model in BPMN 2.0 XML. It opens in standard BPMN tools such as Camunda Modeler, Signavio or ADONIS, with lanes, the three gateways, both control steps and the diagram layout. It is sent by email on request; nothing is downloaded from this page.
The other cross-industry example: employee onboarding. How control steps are described per step in an SOP or compliance analysis: process documentation. The symbols in detail: the BPMN guide.