# Accounts Payable SOP — [Company name]

Status: [Draft / In review / Approved] · Applies from: [date] · Next review: [date]

Educational template. Adapt it to your entity, jurisdiction, chart of accounts
and auditor before you use it. It is not financial, tax or legal advice.

## Purpose

Run the payables cycle end to end, from a registered invoice through vendor and
purchase-order context, three-way match, approval routing by amount, the payment
run and bank reconciliation, so that [Company name] pays the right vendor, the
right amount, once, for something it actually ordered and received — and so that
the person who approves a payable is never the person who releases the money.

## Scope

In scope: vendor payables for entity [legal entity], from the point an invoice
is registered with a legible vendor, amount, currency and date, to the point the
payment appears on the bank statement and is reconciled.

Out of scope, because it is a different job with different failure modes: the
invoice document lifecycle — arrival, capture, field extraction, validation and
posting — which is covered by [Invoice Automation SOP]. Also out of scope:
employee expenses, corporate card transactions, payroll, intercompany
settlement, and customer receipts ([Invoice Reconciliation SOP]).

## Owner

- Accountable for the cycle: [Accounts Payable Lead].
- Reviewing: [Financial Controller].
- Spend approval: the budget holder for the cost centre, per the amount bands in
  Approvals below.
- Payment release: [Payment Approver / Treasury], who must not be the person who
  entered or approved the payable.
- Vendor master custody: [Vendor Master Administrator], who must be able to
  neither approve a payable nor release a payment.

## Trigger

- Event: an invoice reaches state `registered` in [accounting system] with
  vendor, gross amount, currency, invoice date and, where the category requires
  one, a purchase-order reference.
- Scheduled: the payment run executes [weekly, Wednesday 14:00 local time].
  Payables approved after [Tuesday 17:00] fall into the following run.
- Scheduled: bank statement import and reconciliation at [daily, 08:00].
- Manual: [Financial Controller] may open an off-cycle run for an exception
  documented under A5.

## Inputs

| Input | System of record | Required |
| --- | --- | --- |
| Registered invoice with header fields and line items | [Accounting system] | Yes |
| Vendor master record, payable status, payment terms | [Accounting system] | Yes |
| Verified vendor bank details, with the date and method of verification | [Vendor master] | Yes |
| Purchase order and remaining commitment | [Procurement system] | Yes for PO-backed categories |
| Goods or service receipt | [Procurement system] or requester confirmation | Yes for goods |
| Contract, rate card or subscription schedule | [Contract store] | For recurring services |
| Approval matrix by amount band and cost centre | [Finance policy] | Yes |
| Match tolerance policy | [Finance policy] | Yes |
| Tax treatment rules for the vendor's jurisdiction | [Tax guidance] | Yes |
| Cash position and available balance | [Bank] | Yes, before release |

## Prerequisites

- A vendor master where every payable vendor has bank details verified out of
  band at onboarding, and every change since is logged with who verified it, by
  what method, on what date.
- A published approval matrix with amount bands, and a named deputy for every
  approver. An approval matrix with a single unbacked name stalls the run every
  time that person is on leave.
- Purchase-order discipline for the categories where it applies, agreed with
  procurement, so that a missing PO is a real exception rather than the norm.
- A written match tolerance (see D1) that finance, procurement and the auditor
  have all seen.
- Segregation of duties that survives automation. The GAO Green Book describes
  dividing key duties — authorising, processing and recording, and reviewing —
  among different people to reduce the risk of error and fraud; see
  [Standards for Internal Control in the Federal Government](https://www.gao.gov/products/gao-25-107721).
  If an automated process runs under one service account, the split has to be
  reproduced inside the process rather than assumed from the login.

## Steps

Each step is marked with who should perform it once the cycle is automated:
**[Deterministic]** for fixed rules, **[Model judgment]** for genuinely
open-ended reading, **[Human approval]** for a decision a person must remain
answerable for.

1. **Assemble the payable context.** [Deterministic] Pull the vendor record,
   payment terms, the referenced PO with its remaining commitment, the goods
   receipt, and any contract or rate card, and attach them to the payable.
   A payable that cannot assemble its own context is not ready to be judged.
2. **Check the vendor is payable.** [Deterministic] Vendor exists, is active,
   is not on hold, has verified bank details, and has no open bank-detail change
   request. Any failure routes to E5 or E6.
3. **Run the three-way match.** [Deterministic] Compare invoice line to PO line
   to receipt on quantity, unit price and total, then apply D1. Record the
   computed variance whether or not it passes.
4. **Check for duplication.** [Deterministic] Compare vendor, invoice number,
   gross amount and date against all registered payables, including cancelled
   ones. Any hit routes to E1 before anything else happens.
5. **Classify whatever did not match.** [Model judgment] Read the invoice, PO,
   receipt and vendor correspondence together and name the exception class, the
   evidence for it, and the proposed handling. Classifying is judgment;
   deciding what to do about the classification is not the model's to make.
6. **Code the payable.** [Deterministic] Apply cost centre, general-ledger
   account and tax treatment from the PO, the contract or the vendor default.
   An unmapped tax combination routes to E4.
7. **Route for approval by amount.** [Deterministic] Select the approver from
   the matrix by gross amount band and cost centre, per D2, and record the rule
   that selected them.
8. **Approve the spend.** [Human approval] The budget holder confirms the
   commitment is theirs and correct. Approval is recorded against a named
   person, not a role mailbox.
9. **Schedule into a payment run.** [Deterministic] Apply payment terms and D3
   to set the run date, holding early-payment and late-payment cases for the
   controller.
10. **Assemble the payment proposal.** [Deterministic] Group approved payables
    by vendor, net any matched credit notes within the same vendor account,
    total by currency, and check against available balance.
11. **Release the payment run.** [Human approval] [Payment Approver] reviews
    the proposal, including every new or recently changed payee, and releases
    it. This is the point at which money irreversibly leaves the business.
12. **Send remittance and record the payment.** [Deterministic] Issue the
    remittance advice per vendor and write the payment reference back against
    every payable in the run.
13. **Reconcile against the bank.** [Deterministic] Match statement lines to the
    released run, and open an exception for any line that does not match within
    [2] working days.
14. **File the record and close.** [Deterministic] Assemble the audit record
    below against the payable and close it.

## Decisions

- **D1 — Match tolerance.** Accept a variance up to [2%] of the PO line and no
  more than [250] in [currency], whichever is lower. Outside that, E2. Record
  the tolerance version that was applied, not just the outcome.
- **D2 — Approval band.** Up to [1,000]: [cost centre owner]. [1,001–10,000]:
  [department head]. [10,001–50,000]: [Financial Controller]. Above [50,000]:
  [Financial Controller] and [Managing Director] jointly.
- **D3 — Payment timing.** Default to the vendor's terms. Early payment needs a
  discount that beats [threshold] and approval A5. Deliberate late payment needs
  A5 and a note to the vendor.
- **D4 — Partial delivery.** If the received quantity is below the invoiced
  quantity, pay the received portion only when the PO permits partial billing
  and the shortfall is under [10%]; otherwise hold the whole payable (E7).
- **D5 — Credit note application.** Net a credit note only within the same
  vendor account and only against the original invoice or a later invoice from
  the same vendor. Never net across vendors to make a run balance (E8).

## Exceptions

- **E1 — Suspected duplicate.** Hold both records, confirm against the vendor
  statement, cancel the later registration with a stated reason, and retain the
  cancelled record. Never delete it.
- **E2 — PO mismatch beyond tolerance.** Return to the requester with invoice,
  PO and receipt side by side. Accounts payable does not negotiate a variance;
  the person who ordered does.
- **E3 — Missing PO.** Hold, notify the requester and the category owner, and
  require a documented retrospective PO with a reason. A rising count here is a
  procurement problem and belongs in the monthly review, not in a workaround.
- **E4 — Wrong or unmapped tax treatment.** Hold the posting, not the whole
  payable, and route to [Tax / Financial Controller] with the vendor's
  jurisdiction, registration number and the invoice wording.
- **E5 — Vendor bank details differ, or a change is requested.** Treat every
  change request as attempted fraud until proven otherwise. Verify by calling a
  number already on the vendor master, never a number from the invoice, the
  email or the request itself. Requires A3 and a second person, and blocks
  payment to that vendor until it clears.
- **E6 — Unknown vendor.** Do not create a vendor in order to clear an invoice.
  Route to [Vendor Compliance Review SOP], hold the payable, and let vendor
  creation be its own approved decision.
- **E7 — Partial delivery.** Apply D4. If holding, tell the requester what is
  outstanding and record the expected receipt date so the accrual is right at
  period end.
- **E8 — Credit note.** Apply D5, match to the originating invoice, and record
  the net position on the vendor account before the run is assembled.

## Approvals

| ID | What is approved | Who | Why it stays with a person |
| --- | --- | --- | --- |
| A1 | The spend on the payable | Budget holder per D2 | Someone must own the cost |
| A2 | Release of the payment run | [Payment Approver], not the enterer or approver | Money leaves irreversibly |
| A3 | A change to vendor bank details | [Financial Controller] plus a second out-of-band verifier | The classic payment-redirection fraud |
| A4 | Adding a vendor to the master | [Financial Controller] after vendor review | Stops an invoice creating its own payee |
| A5 | Paying off-terms, off-cycle, early or late | [Financial Controller] | Cash and vendor-relationship impact |

## Output

- Approved, coded payables with the full document set attached to each.
- A payment run released by an authorised second person, with a payment
  reference written back against every payable in it.
- A remittance advice sent to each paid vendor.
- Bank statement lines reconciled to the run within [2] working days.
- An exceptions log by class, reviewed [monthly] with procurement.
- An accrual list for goods received but not invoiced at period end.

## SLA / KPI

- Payables cleared to approval within [5] working days of registration: target
  [95%].
- Share of payables that clear the match with no human touch: measured monthly,
  reported as a trend rather than a target.
- Duplicate payments per period: target zero, investigated individually.
- On-time payment against agreed terms: target [98%].
- E3 (missing PO) count: trending down quarter on quarter.
- Unreconciled payment lines older than [5] working days: target zero.

## Audit record

Retain, per payable: the invoice document, the purchase order, the goods or
service receipt, the computed match variance and the tolerance version applied,
the coding, the approver name and timestamp for A1, the payment run identifier,
the releaser name and timestamp for A2, the payment reference, the remittance,
and the reconciled bank statement line. For any exception, retain the class, the
evidence, the decision and who made it.

Supporting documents should show the payee, the amount paid, proof of payment,
the date incurred and a description of what was bought; see the IRS guidance on
[what kind of records to keep](https://www.irs.gov/businesses/small-businesses-self-employed/what-kind-of-records-should-i-keep)
and [recordkeeping](https://www.irs.gov/taxtopics/tc305). The same requirements
apply when the records are electronic, and the system must be able to produce
them in a legible form; see
[automated records](https://www.irs.gov/businesses/automated-records). Confirm
retention periods and the documents your own entity must keep with your
accountant.

> Simulated example data — illustration only, not a real company or run.
>
> Payable [AP-2026-0731] from vendor [Aldergate Components Ltd], gross
> [EUR 12,480.00], PO [PO-20261-0412], receipt [GRN-9931]. Step 3 computes a
> variance of [EUR 180.00], which is [1.46%] of the PO line — inside D1, so the
> payable proceeds with the variance recorded. Step 7 places [EUR 12,480.00] in
> band [10,001–50,000], routing A1 to [Financial Controller]. Step 9 sets the
> run date to [2026-07-29] on [30]-day terms. Step 11 is released by
> [Payment Approver], who neither entered nor approved it. Step 13 matches
> statement line [2026-07-29 / EUR 12,480.00 / ref PR-0442] and closes the
> payable.

## Revision log

- v1.0 — 2026-07-24 — initial draft — [Your name].