Process flow diagrams for payables are usually drawn to explain the function to somebody outside it, which is why they show the clean path and stop. A diagram meant to run the function looks different: the spine is short, the branches are prominent, and every branch has a name against it and a target time. That version is a management tool rather than an illustration.
The spine
Invoice received and identified against the supplier list. Validated for duplicates and arithmetic. Matched against the purchase order and the goods receipt. Approved by the person with authority for that value and cost centre. Coded, scheduled, paid, remittance sent. Most invoices take this route with no individual attention, and that is what a healthy process looks like.
The branches and their owners
No order: whoever owns the spend. Price variance: purchasing. Quantity variance or missing receipt: whoever takes deliveries. Query, dispute or suspected duplicate: a named person with the supplier contact. Four branches, four owners, and each with an age so nothing sits invisibly while everybody assumes it is somebody else's.
What to put on the diagram besides boxes
A target elapsed time per branch, and a note of how many invoices took each one last month. That converts the diagram into evidence: a branch that is growing or slowing becomes a specific problem with a specific owner, which is a much better conversation than a general complaint that payables is slow.
Questions people ask about account payable process flow
How detailed should the diagram be?
One page. If it needs two, it is describing system screens rather than the process, and it will date the first time the software changes.
Where do credit notes go?
Their own short branch. They reverse an obligation rather than creating one, and processes built only for invoices handle them badly.
Who should own the diagram?
Whoever owns the payables control, written with the people doing the work so it describes what happens rather than what should.