Accounts payable process flowchart (full AP cycle)

What the accounts payable process flowchart (full ap cycle) process is

Accounts payable is a function, not a queue of invoices. It owns everything between a supplier document arriving on some channel and the organisation being able to say, at the end of a period, exactly what it owes and to whom. That span includes work that never appears on a single-invoice diagram: keeping the supplier master file trustworthy, running an exception queue as a managed backlog, building and approving a payment proposal, releasing money at the bank, reconciling what the supplier thinks you owe against what your ledger says, and accruing for invoices that have not been processed yet.

This template is deliberately wider than one invoice and deliberately narrower than procurement. It is not an invoice approval map: the per-invoice path of capture, duplicate check, three-way match, coding and threshold approval is compressed here into a single match decision and a single budget holder decision, and the invoice approval process template covers that path in detail. It is also not a buying process: requisitions, sourcing, purchase order issue and goods receipt happen before this chart starts, and the purchase requisition and purchase order templates take over there. The depth on this page sits after approval, in the payment run and the period close, which is where AP stops being a processing team and starts being a cash and control function.

Most AP functions break in five predictable places, and all five are visible on this map. Invoices arrive on channels nobody funnelled into intake, so the duplicate check never sees them. Supplier bank details are changed on the strength of an email. Exceptions are logged into a queue with no owner and no age, and quietly become next month's unrecorded liability. The payment proposal is built from whoever is chasing hardest rather than from due dates and settlement terms. And the accrual at period end misses the invoices still sitting in the exception queue. The chart runs across five lanes (Supplier, AP clerk, Budget holder, Financial controller and Treasury) and six phases, so each of those failure points has a named owner rather than belonging to "finance".

What this flowchart covers

In this template

• Five swimlanes for the whole AP function rather than the invoice alone: Supplier, AP clerk, Budget holder, Financial controller and Treasury, across six phases: Intake, Validation, Coding and approval, Exception queue, Payment run and Period close.
• Multi-channel intake that funnels every arrival route into one queue before any check runs, followed by capture into the AP system, so no channel can bypass the controls that come next.
• Supplier master data as a control step: the "Supplier and bank details verified?" decision, with a "New details" branch into "Confirm bank change by callback" before the invoice goes any further.
• A duplicate check placed before any matching or coding effort, with a "Duplicate blocked and logged" exit so suspected duplicates stop there instead of being silently deleted.
• The PO split at "Purchase order referenced?": PO invoices run through "PO, receipt and invoice agree?", non-PO invoices go to the budget holder's "Non-PO invoice approved?" decision, and both the variance and disputed branches feed the same exception queue, where a query is logged, the supplier issues a credit note or corrected invoice, and "Query resolved?" either returns the invoice to posting or ends it at "Invoice rejected and returned".
• The payment cycle and close that a single-invoice map never reaches: "Prepare payment proposal", the financial controller's "Payment run approved?" decision with an "Amend" loop back to the proposal, execution at the bank by Treasury, remittance advice from AP, supplier statement reconciliation, and "Accrue unprocessed invoices and close".

When to use this template

• Writing or refreshing an accounts payable policy or SOP that has to cover the function end to end, including payment runs and period close, not just invoice approval.
• Standing up or restructuring a shared service centre, where the hand-offs from AP to the controller and to treasury need to be explicit rather than assumed.
• Preparing for an audit or internal control walkthrough of the payment cycle, where the question is who posts, who approves the run and who releases the money at the bank.
• Reviewing controls after a duplicate payment, a mispayment or an attempted bank detail change, when you need to show where the check sits and who performs it.
• Scoping AP automation, e-invoicing or an ERP migration, where the intake channels, exception reason codes and payment calendar have to be agreed before anything is configured.

How it works

1. List every channel an invoice can arrive on

   Write down all of them: the shared mailbox, the supplier portal, EDI, post, and invoices sent straight to a budget holder or a site. Any route that does not feed the intake step also skips the duplicate check, so either connect it or close it. Note which channels are automated and which need a person, because that is where the backlog forms.

2. Fix the supplier master data rule

   State who may create or amend a supplier record, who verifies a bank detail change and how. Call the supplier on a number already held in the master file, never one taken from the invoice or the request, and keep the person who keys the change separate from the person who approves it. Record who verified, when and against which contact.

3. Set the matching tolerance and the non-PO route

   Put your real price and quantity tolerance on the "PO, receipt and invoice agree?" decision, and state which spend requires a purchase order. Then decide what happens to a non-PO invoice that should have had one, so it is a documented exception rather than something the budget holder quietly approves.

4. Give the exception queue reason codes and an age

   Replace the single query step with your own reason codes, for example price variance, no goods receipt, no PO, disputed delivery, or missing supplier details. Give each code an owner and agree a chase and escalation point in days. A queue without owners and ages is where invoices go to be forgotten and where period-end surprises come from.

5. Define the payment calendar and who approves the run

   Set how often payment runs happen, how the proposal is selected (due date, payment terms, settlement discounts about to lapse) and what is excluded. Then name the approver of the proposal and the person who releases it at the bank, and keep those roles apart from the person who prepared it and from anyone who can amend supplier bank details.

6. Agree what is accrued at period end

   Decide what the financial controller accrues for: goods and services received but not yet invoiced, plus everything still open in the exception queue. Agree who supplies that list, when in the close timetable it is produced and how the accrual is reversed in the next period, so the queue is reflected in the accounts rather than hidden in it.

7. Walk the map through and keep one approved version

   Review the chart with an AP clerk, a budget holder, the controller and treasury, and correct it to what they actually do rather than what the policy says. Then keep the agreed version under version control and link it from your AP policy, so people work from the current diagram instead of a screenshot in an old training deck.

Frequently asked questions

What are the steps in the accounts payable process?

A complete cycle runs: receive the invoice on any intake channel and capture it into the AP system; confirm the supplier exists on the approved master file and verify any new or changed bank details; check for duplicates; determine whether a purchase order is referenced; match PO invoices against the order and the goods receipt, or send non-PO invoices to the budget holder for coding and approval; route variances and disputes into an exception queue for resolution with the supplier; post approved invoices to the ledger; prepare a payment proposal; obtain approval of the payment run; execute the payment and send remittance advice; reconcile supplier statements; and accrue for invoices not yet processed at period end.

What is the difference between the accounts payable process and invoice approval?

Invoice approval is one stage inside accounts payable. It covers a single document from receipt to being cleared for payment: capture, duplicate check, matching or coding, and approval by the right person for the value. The accounts payable process is the function around that stage. It also covers keeping the supplier master file trustworthy, managing the exception queue as a backlog with owners and ageing, grouping approved invoices into a payment proposal, getting the run approved and executed, reconciling supplier statements, and accruing for what has not been processed. If you only need the approval path in detail, use an invoice approval flowchart; if you need to show how the whole function runs and where cash actually leaves, use this one.

How should accounts payable handle a change of supplier bank details?

Treat it as a control step, not an administrative update. Verify the request by calling the supplier on a number already held in your master file, never a number given in the request itself, and speak to a known contact rather than whoever sent the email. Keep the person who keys the change separate from the person who approves it, record who verified it and against which contact, and hold payments to that supplier until the change is confirmed. Requests to redirect payments are a recurring fraud pattern, and they typically arrive as a plausible email from a real supplier's address or a close imitation of it, which is why the verification has to run outside the channel the request came in on.

Who should approve a payment run?

Someone other than the person who prepared it, and someone other than the person who can amend supplier bank details. In most organisations the AP clerk builds the payment proposal, a financial controller or finance director approves it against the delegation of authority, and treasury releases the file at the bank, often under dual control with a second bank authoriser. The approver needs to see the total per bank account and currency, the exclusions and anything unusual such as a new supplier or a first payment, rather than just a payment count. Keeping those three roles apart is the segregation of duties an auditor will look for when walking the payment cycle.

Why does accounts payable accrue for unprocessed invoices at month end?

Because accrual accounting recognises an expense in the period the goods or services were received, not the period the invoice happened to be processed. At close there are always two populations that would otherwise be missed: items received but not yet invoiced, and invoices already in the building but still sitting in the exception queue or awaiting approval. The controller accrues for both so the period's costs and liabilities are complete, and reverses the accrual when the invoices post. This is why the exception queue matters beyond AP: an unowned, unaged queue makes the accrual an estimate rather than a list.