Invoice approval process map

A swimlane map of an invoice from arrival to payment, across the supplier, accounts payable, the budget holder and the finance manager. Six decisions in nineteen steps, because invoice handling is a sequence of gates and the interesting question is always which gate an invoice is stuck behind.

Open this map in the editor

Opens a copy in the editor and saves it in this browser. No account, nothing sent anywhere.

What is in this map

19 steps across 4 swimlanes and 6 phases, with 6 decision points.

Swimlanes (who does the work): Supplier, Accounts payable, Budget holder and Finance manager
Phases (left to right): Capture, Validation, Match and code, Query resolution, Approval and Post and pay

Why map this process

Ask a finance team where invoices get delayed and you will get an answer about approvers being slow. Ask for the data and it is usually split three ways: invoices that failed a match and went into a query, invoices sitting with an approver, and invoices that were never captured properly in the first place. Those are three different problems with three different fixes, and you cannot tell them apart without a map that separates capture, matching, query resolution and approval into distinct phases.

The query loop is the part worth drawing carefully. An invoice that does not match goes back out to the supplier and comes back in: it re-enters the process rather than continuing through it, and that round trip is where the days go. On a map the loop is a visible line going backwards; in a list it is invisible.

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.

Every step in the Invoice approval process process map, in the order the editor numbers them.
#	Step	Shape	Swimlane	Phase	Goes to
1	Invoice received from supplier	Start	Supplier	Capture	2
2	Capture invoice in AP system	Process	Accounts payable	Capture	3
3	Duplicate invoice?	Decision	Accounts payable	Validation	4 (Yes), 5 (No)
4	Block and flag duplicate	Reject	Accounts payable	Validation	End
5	PO referenced on invoice?	Decision	Accounts payable	Match and code	6 (PO invoice), 7 (Non-PO)
6	Three-way match to PO and GRN	Process	Accounts payable	Match and code	8
7	Code to cost centre and GL	Process	Budget holder	Match and code	13
8	Match within tolerance?	Decision	Accounts payable	Match and code	13 (Yes), 9 (No)
9	Raise query with supplier	Exception	Accounts payable	Query resolution	10
10	Supplier corrects or credits invoice	Process	Supplier	Query resolution	11
11	Query resolved?	Decision	Accounts payable	Query resolution	5 (Yes), 12 (No)
12	Return invoice to supplier	Reject	Accounts payable	Query resolution	End
13	Route for approval by value	Process	Accounts payable	Approval	14
14	Budget holder approves?	Decision	Budget holder	Approval	15 (Yes), 9 (No)
15	Over approval threshold?	Decision	Accounts payable	Approval	16 (Yes), 17 (No)
16	Finance manager countersigns	Approval	Finance manager	Approval	17
17	Post invoice to ledger	Registry	Accounts payable	Post and pay	18
18	Schedule in next payment run	Process	Finance manager	Post and pay	19
19	Supplier paid and remittance sent	End	Supplier	Post and pay	End

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. **Duplicate** invoice?

Owned by Accounts payable · Validation
- Yes → step 4
- No → step 5
5. PO referenced on invoice?

Owned by Accounts payable · Match and code
- PO invoice → step 6
- Non-PO → step 7
8. Match within **tolerance?**

Owned by Accounts payable · Match and code
- Yes → step 13
- No → step 9
11. Query resolved?

Owned by Accounts payable · Query resolution
- Yes → step 5
- No → step 12
14. Budget holder **approves?**

Owned by Budget holder · Approval
- Yes → step 15
- No → step 9
15. Over **approval threshold?**

Owned by Accounts payable · Approval
- Yes → step 16
- No → step 17

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. Capture invoice in AP system: Capture supplier, invoice number, invoice date, net, VAT and any PO reference. Scanned, emailed and e-invoicing feeds all land here.
3. **Duplicate** invoice?: Check supplier ID plus invoice number, then gross amount plus invoice date as a second key. Duplicate payments are the most common AP leak.
6. **Three-way match** to PO and GRN: Invoice against purchase order and goods receipt note. Agree a price and quantity tolerance in policy so AP is not judging each case.
11. Query resolved?: Resolved queries re-enter at the PO fork, not the three-way match: a non-PO invoice has no PO or GRN to match against.
15. Over **approval threshold?**: Set the limit in policy, not in people's heads. A common split is budget holder alone up to **5,000** and a finance manager countersignature above it.

Making it yours

Adapt the match phase first. Whether you run a two-way or three-way match is one decision row, and the number of tolerance rules is the number of branches on it. Keep the query-resolution phase as its own set of columns rather than folding it into validation: the moment those two share a phase, you lose the ability to say how long an invoice spent in query versus in checking.

What to watch out for

Do not draw approval as one box. In most companies an invoice needs the budget holder AND, above a threshold, a finance manager: two steps in two lanes, sequential, with a decision between them. One box hides the threshold entirely.
Non-PO invoices are a real branch and usually the majority of the delay. If your map only handles PO-backed invoices, it is describing the easy half.
The payment run has its own calendar. An invoice approved on the 3rd and one approved on the 17th may be paid on the same day; unless the map shows the run as a step with a schedule in the Notes column, approvers have no reason to believe their speed matters.

Frequently asked questions

Should the supplier really have a swimlane on an internal approval map?

Yes, because they act in the middle of it. An invoice that fails a match goes back to the supplier for a credit note or a corrected invoice, and the process cannot proceed until they respond. Without a supplier lane that wait becomes invisible and the delay gets attributed to accounts payable.

How do I show an approval that times out and escalates?

Add a decision after the approval step that branches on whether the deadline passed, with one branch going to an escalation row in the finance manager's lane. Put the actual number of days in the branch label so the rule is legible on the diagram rather than buried in a policy.

Can I reuse this map for expense claims?

The shape rhymes but the controls differ: expenses are validated against a policy rather than matched against a purchase order, and the reimbursement runs through payroll rather than the supplier payment run. The expense approval map is a better starting point; it shares the approval spine and replaces the match phase with policy validation.

Open the map and start editing

The editor loads this chart with the spreadsheet underneath it. Change a cell and the diagram redraws — no drawing, no signup.

Open this map in the editor