Key takeaways
- Automate the match, the routing and the reconciliation first. Comparing an invoice line to a purchase order and a receipt, picking an approver from an amount band, and matching statement lines are arithmetic, and arithmetic is the cheapest thing to hand over.
- Keep two approvals and keep them with two people: approving the spend and releasing the payment. If an automated process runs under one service account, you have to rebuild that split inside the process, because the login no longer provides it.
- Treat every vendor bank-detail change as attempted fraud until a call to a number already on the vendor master proves otherwise. This is the one step in payables that should get harder, not easier, when the rest is automated.
- Write the exception catalogue before you automate anything. Duplicates, PO mismatches, missing POs, unmapped tax codes, unknown vendors, bank-detail changes, partial deliveries and credit notes are eight named branches, not one bucket called manual review.
- A payable is finished when the audit record is finished: invoice, purchase order, receipt, computed variance, both approvers with timestamps, payment reference and the reconciled statement line, retrievable long after the run.
Accounts payable automation means handing the repeatable parts of the payables cycle to software — assembling vendor and purchase-order context, running the three-way match, routing by amount band, preparing the payment run, reconciling against the bank — while keeping a named person on the two decisions that commit and release money. The design work is not choosing a tool. It is sorting your own cycle into fixed rules, genuine judgment and permanent approvals, and writing down what happens on each of the eight exceptions that actually occur.
The payables job, defined once: trigger, inputs, outputs, actors
| Dimension | For the payables cycle |
|---|---|
| Trigger | An invoice reaches a registered state with a legible vendor, amount, currency and date; separately, the scheduled payment run fires; and daily, the bank statement imports. |
| Inputs | Registered invoice, vendor record with verified bank details and terms, purchase order with remaining commitment, goods receipt, contract, approval matrix, match tolerance, tax rules, cash position. |
| Outputs | Coded and approved payables, a released payment run, a remittance per vendor, reconciled statement lines, an exception log by class, and the period-end accrual list. |
| Systems | Usually five and rarely from one supplier: ledger, procurement system, vendor master, document store, bank. The friction lives in the gaps between them. |
| Actors | AP owner, the requester who raised the PO, the budget holder who approves the spend, a separate approver who releases the run, the vendor master administrator, and the controller who owns exceptions. |
| Frequency | Matching runs per invoice, continuously; the payment run is weekly or fortnightly; reconciliation daily; the exception review monthly. |
| Success condition | The right vendor is paid the right amount, once, for something ordered and received, with two different named people behind the approval and the release, and a retrievable record. |
This playbook starts where the invoice is already a legible record. Everything before that — arrival, capture, extraction, validation and posting — is a different job with different failure modes, covered on invoice automation. Teams that treat both as one project tend to automate the document half and leave the payment half exactly as it was.
How the payables cycle runs by hand today
On a small team the cycle is spread across the week. Invoices are eyeballed against purchase orders in a second system. Approvals go out as forwarded emails and come back as replies saying "fine by me". The payment run is assembled in a spreadsheet from whatever was approved by Tuesday evening, checked twice because that is the only check there is, and uploaded to the bank. On Friday somebody ticks off statement lines.
None of it is difficult. What makes it expensive is that the state of every payable lives partly in the ledger, partly in an inbox and partly in the head of the person assembling the run.
- Chasing approvals. The matrix says who signs; the reality is a person on leave, a deputy nobody named, and reminders sent by the AP owner rather than by the process.
- Evidence scattered across mailboxes. The approval exists as a reply in someone's inbox rather than against the payable, so proving it later means searching email.
- The run rebuilt from scratch each cycle. Copying approved payables into a spreadsheet is where duplicates and transposed amounts get in.
- Exceptions handled from memory. Everyone knows the awkward vendor and the usual variance, but the handling is improvised and never written down.
Which steps are fixed rules, which need judgment, and which keep your signature
Sorted honestly, almost all of this job is arithmetic and lookup. One step needs real judgment, and two must keep a person for reasons that have nothing to do with how good the software is.
- 01An invoice is registered, or the payment run firesTriggerOne run per payable for the match, one per cycle for the payment. Keeping them separate lets matching run continuously while money still moves on a schedule somebody controls.
- 02Assemble the payable's contextCodePull the vendor record, terms, the referenced purchase order with its remaining commitment, the receipt and any contract. A payable that cannot assemble its own context is not ready to be judged by anyone.
- 03Run the three-way match and the duplicate checkCodeCompare invoice line to PO line to receipt on quantity, price and total, apply the written tolerance, and record the variance whether or not it passes. Then check vendor, invoice number, amount and date against every registered payable, cancelled ones included. Both are comparisons.
- 04Classify anything that did not matchAI judgmentReading the invoice, the PO, the receipt and the vendor's last three emails together to work out which exception this is — that is genuine judgment, and the one step here worth paying a model for. It names and evidences the exception; it does not decide the money outcome, edit a vendor record, or release anything.
- 05Code the payable and route it by amount bandCodeApply cost centre, ledger account and tax treatment, then select the approver by gross amount and cost centre and record the rule that selected them. Routing is a lookup, and a lookup can be audited.
- 06Approve the spendHuman approvalThe budget holder confirms the commitment is theirs and correct, as a named person rather than a shared mailbox. If the payable is edited afterwards the approval should be void and the payable should come back.
- 07Assemble the payment proposalCodeGroup approved payables by vendor, net matched credit notes within the same account, total by currency, check against available balance, and flag every new or recently changed payee. This is the step the spreadsheet was doing badly.
- 08Release the runHuman approvalA different named person reviews the proposal and releases it. Money irreversibly leaves the business here, and deliberately not on the say-so of whoever entered or approved the payable.
- 09Remit, write back, reconcile and fileCodeSend the remittance, write the payment reference against every payable in the run, match statement lines as they arrive, and assemble the audit record. Set matching: boring, exact, safe to repeat.
The two human gates are not a lack of confidence in the software; they are the control the cycle rests on. The GAO Green Book describes dividing key duties — authorising, processing and recording, and reviewing — among different people so that no one person controls all aspects of a transaction. A process running under a single service account has collapsed those duties into one identity, so rebuild the split inside it: different named approvers at the two gates, and a vendor master the process can read but never write.
That is the shape all-agents is built around. A process runs with the operator first, stopping before anything irreversible, and each accepted run is captured as an example. When the operator decides it is ready, a step-by-step walk-through turns the settled parts into deterministic code, leaves genuinely open-ended steps with a model, and keeps a permanent approval gate wherever the operator pins one. Steps 6 and 8 above are what pinning is for.
The eight exceptions that decide whether this can run without you
A payables process is only as automated as its exception catalogue. Each of these is a named branch with its own detection rule and handling, not one bucket called manual review.
| Exception | How it is detected | How it is handled |
|---|---|---|
| Duplicate invoice | Vendor, invoice number, amount and date matched against every registered payable, cancelled ones included. | Hold both, confirm against the vendor statement, cancel the later registration with a stated reason, and retain the cancelled record rather than deleting it. |
| PO mismatch | Computed price or quantity variance exceeds the written tolerance, in percentage and absolute terms. | Return to the requester with invoice, PO and receipt side by side. AP does not negotiate a variance; the person who ordered does. |
| Missing PO | No PO reference in a category where PO discipline applies, or a reference that resolves to nothing. | Hold, notify requester and category owner, require a documented retrospective PO. A rising count is a procurement problem, not an AP one. |
| Wrong tax treatment | Tax code cannot be derived for the vendor's jurisdiction, or the invoice wording contradicts the vendor default. | Hold the posting only, not the whole payable, and route to the controller with jurisdiction, registration number and invoice wording attached. |
| Unknown vendor | No active vendor master record for the payee named on the invoice. | Hold, and route vendor creation through its own approved review. Creating a vendor to clear an invoice lets the invoice create its own payee. |
| Bank-detail change request | Details on the invoice or in correspondence differ from the master, or a change is requested by any channel. | Block payment to that vendor, verify by calling a number already on the master and never one from the request, and require two named people. Treat it as attempted fraud until proven otherwise. |
| Partial delivery | Received quantity is below the invoiced quantity. | Pay the received portion only where the PO permits partial billing and the shortfall is inside the written threshold; otherwise hold and record the expected receipt date. |
| Credit note | Negative document or credit reference registered against a vendor with open payables. | Match to the originating invoice and net within the same vendor account only, before the run is assembled. Never net across vendors to make a run balance. |
A worked payment run, from registration to reconciliation
Invented figures, for illustration. Not a real company, vendor or run, and not a performance claim.
Payable AP-2026-0731, vendor Aldergate Components Ltd, gross EUR 12,480.00, referencing PO-20261-0412 and receipt GRN-9931. Vendor active, bank details verified at onboarding fourteen months ago, no open change request, terms 30 days.
The match finds the PO line at EUR 12,300.00 against an invoiced EUR 12,480.00. Variance EUR 180.00, or 1.46 per cent — inside a tolerance of 2 per cent capped at EUR 250, so the payable proceeds with the variance and the tolerance version recorded rather than silently absorbed. The duplicate check finds nothing, so no judgment step runs.
Routing puts the amount in the 10,001–50,000 band, so approval goes to the financial controller, who approves at 09:41 on 2026-07-27. The run scheduled for 2026-07-29 assembles eleven payables totalling EUR 47,905.00, one of whose payees is flagged as changed within 90 days and checked by hand. A second person, who neither entered nor approved any of them, releases it at 14:02. Next morning the statement line for EUR 12,480.00 with reference PR-0442 matches automatically.
The interesting number is not the total. It is that only one of eleven payables needed a person beyond the two approvals — and on a run with a disputed delivery that ratio would look far worse. Worth measuring; not worth promising in advance.
What the audit record has to contain when nobody watched the run
When a person assembles a payment run, the evidence is a by-product of them doing it. When software assembles it, evidence becomes a deliberate output — complete per payable, not scattered through a log of system events.
The baseline itself does not change. 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 on what kind of records to keep. The same requirements apply to automated records, which must still be produced in legible form. Confirm retention periods for your own entity with your accountant.
- Invoice, purchase order and receipt attached to the payable, not linked from a mailbox.
- The computed variance and the tolerance version that judged it, so a reviewer can tell whether the rule or the invoice changed.
- Both approvals as named people with timestamps, and evidence that they were not the same person.
- Per exception: the class, the evidence, the decision and who took it — including bank-detail verifications, with the method and the number called.
- The payment reference, the remittance and the reconciled statement line, closing the loop from invoice to cash.
A practical test: take a payable from three months ago and reconstruct it from the record alone, asking nobody. If you cannot, the process is not ready to run unattended, whatever its match rate looks like.
Take the procedure and the blueprint
Two editable Markdown files, no account needed. The SOP is the version a person runs and an auditor reads; the blueprint is the same cycle as data contracts, branches and test cases, for whoever — or whatever — builds it. Fill the SOP in against a payment run that actually happened last week: the placeholders you cannot fill are the parts that still need you present.
SOP
Accounts Payable SOP
The payables cycle written out for a person to run: trigger, inputs, prerequisites, fourteen steps, five decisions with thresholds, the eight exceptions, five approvals, KPIs and the audit record.
Preview the fileHide preview
# 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].
Workflow blueprint
Accounts Payable workflow blueprint
The same cycle written out for a machine: start and termination conditions, per-step data contracts, which steps are code and which keep a person, branches, retries, idempotency keys, rollback limits and fourteen test cases.
Preview the fileHide preview
# Accounts Payable Workflow Blueprint — [Company name]
Status: [Draft] · Version: v1.0 · Applies from: [date]
The executable shape of the payables cycle: what starts it, what each step
consumes and produces, who performs it, how it branches, and what has to be true
before you would let it run without watching. It is the companion to the
Accounts Payable SOP, which explains the same process in prose. This blueprint
describes a process, not any particular product's connectors.
Placeholders in [brackets] are yours to fill in. Educational template, not
financial or legal advice.
---
## Trigger and termination conditions
**Start conditions**
- `payable.registered` — an invoice reaches state `registered` with vendor,
gross amount, currency, invoice date and, for PO-backed categories, a PO
reference. One run per payable.
- `schedule.payment_run` — [weekly, Wednesday 14:00 local time]. One run per
cycle, consuming every payable in state `approved`.
- `schedule.bank_import` — [daily, 08:00]. One run per statement file.
- `manual.off_cycle_run` — opened by [Financial Controller] with a reason
recorded under approval A5.
**Terminate successfully when**
- the payable reaches `reconciled` and its audit record is complete; or
- the payable reaches `cancelled` with a recorded reason and a retained record;
or
- the payment run reaches `released` and every line in it has a payment
reference written back.
**Terminate unsuccessfully when**
- a hard gate is declined by its approver (record the decline and the reason,
never retry silently); or
- an exception has been open beyond [5] working days without a decision, at
which point it escalates rather than expires; or
- the available balance check fails at step 10, which stops the whole run rather
than paying part of it.
**Never start when**
- the vendor has an open bank-detail change request (E5); or
- the payable is already in a released run; or
- the same payment run identifier is already in flight.
---
## Ordered steps with data contracts
| # | Step | Actor | Consumes | Produces |
| --- | --- | --- | --- | --- |
| 1 | Assemble payable context | Deterministic code | `payable_id`, `vendor_id`, `po_ref?` | `context{vendor, terms, po, receipt, contract?}` |
| 2 | Check vendor is payable | Deterministic code | `context.vendor` | `vendor_status{active, on_hold, bank_verified_at, open_change_request}` |
| 3 | Three-way match | Deterministic code | `invoice_lines[]`, `po_lines[]`, `receipt_lines[]`, `tolerance_version` | `match_result{status, variance_abs, variance_pct, per_line[]}` |
| 4 | Duplicate check | Deterministic code | `vendor_id`, `invoice_number`, `gross_amount`, `invoice_date` | `duplicate_candidates[]` with similarity reason |
| 5 | Classify non-match | Model judgment | `match_result`, `invoice_text`, `po`, `receipt`, `vendor_correspondence?` | `exception{class ∈ E1..E8, evidence[], proposed_handling}` |
| 6 | Code the payable | Deterministic code | `context`, `tax_rules`, `cost_centre_map` | `coding{cost_centre, gl_account, tax_code, net, tax, gross}` |
| 7 | Select approver | Deterministic code | `gross_amount`, `cost_centre`, `approval_matrix_version` | `approval_request{approver, band, rule_id}` |
| 8 | Approve the spend (A1) | Human approval | `approval_request`, full document set | `approval{decision, approver_name, timestamp, comment?}` |
| 9 | Schedule into a run | Deterministic code | `approval`, `terms`, `D3` | `payment_schedule{run_date, run_id}` |
| 10 | Assemble payment proposal | Deterministic code | `payables[] where state=approved`, `credit_notes[]`, `balance` | `run_proposal{lines[], totals_by_currency, new_or_changed_payees[]}` |
| 11 | Release the run (A2) | Human approval | `run_proposal` | `release{decision, releaser_name, timestamp}` |
| 12 | Remit and write back | Deterministic code | `release`, `run_proposal` | `payment_reference` per payable, `remittance_sent[]` |
| 13 | Reconcile to bank | Deterministic code | `statement_lines[]`, `released_runs[]` | `reconciliation{matched[], unmatched[]}` |
| 14 | File and close | Deterministic code | everything above | `audit_record`, `payable.state = reconciled` |
Field-level contract notes:
- `gross_amount` carries an explicit `currency`; no step may compare amounts
across currencies without a recorded rate and rate source.
- `match_result.status ∈ {matched, within_tolerance, variance, no_po,
no_receipt}`. `within_tolerance` always carries the computed variance and the
`tolerance_version` that judged it.
- `exception.class` is a closed set. A model that cannot fit a case into
E1..E8 must return `class = unclassified` and escalate, not invent a class.
- Every human decision carries a named person, never a role mailbox or a shared
login.
---
## Step classification (deterministic / model judgment / human approval)
**Deterministic — steps 1, 2, 3, 4, 6, 7, 9, 10, 12, 13, 14.** Assembly,
comparison, arithmetic, threshold application, routing lookup and write-back.
These must give an identical result for identical inputs, and they are the
cheapest and most testable part of the process. If a step here needs a model,
the rule underneath it has not been written down yet.
**Model judgment — step 5 only.** Reading an invoice, a PO, a receipt and a
message thread together and naming which exception class this is, with the
evidence for it. This is the one place in the payables cycle where the variety
is genuinely open-ended. The model names and evidences the exception; it does
not decide the money outcome, change a vendor record, or release anything.
**Human approval — steps 8 and 11, plus A3 whenever E5 fires.** These are
permanent gates, not training wheels. They exist because someone must be
answerable for the commitment and for the money leaving, and because
[authorising, processing and recording, and reviewing must sit with different
people](https://www.gao.gov/products/gao-25-107721). Steps 8 and 11 must be
performed by different named people, and neither may be the person who
registered the payable.
---
## Branches and retries
| Condition | Branch |
| --- | --- |
| `duplicate_candidates` non-empty | E1: hold both, human confirms against vendor statement, cancel the later record with a reason |
| `match_result.status = variance` | E2: return to requester with the three documents; the requester, not AP, resolves it |
| `match_result.status = no_po` | E3: hold, notify requester and category owner, require a documented retrospective PO |
| Tax code unmapped for the vendor jurisdiction | E4: hold the posting only, route to [Tax / Financial Controller], keep the rest of the payable moving |
| `vendor_status.open_change_request` or bank details differ | E5: block payment to that vendor, out-of-band verification, A3 with a second person |
| Vendor not on master | E6: hold, route to vendor review; never create a vendor to clear an invoice |
| Received quantity < invoiced quantity | E7: apply D4 — pay the received portion or hold the whole payable |
| Credit note present | E8: net within the same vendor account only, before the proposal is assembled |
| Approver has not responded within [3] working days | Remind at [24h] and [48h], escalate to the deputy, then to [Financial Controller] |
**Retries.** Retry only steps that are safe to repeat: 1, 3, 4, 6, 13. Use
[3] attempts with backoff for transient read failures. Never auto-retry steps
11 or 12 — a failed release is investigated by a person, because a blind retry
is how a run gets paid twice. A declined approval is a terminal outcome, not a
retryable error.
---
## Idempotency
- **Idempotency key per payable:** `hash(vendor_id, invoice_number,
gross_amount, currency, invoice_date)`. Computed at step 1, checked at step 4,
and stored with the payable so a re-registration is recognised as a repeat.
- **Idempotency key per run:** `run_id = hash(entity, run_date, sequence)`.
Step 10 refuses to assemble a proposal for a `run_id` already in
`released`.
- **Write-back safety:** step 12 writes the payment reference only where it is
currently null, so a repeated write-back cannot overwrite a real reference.
- **Approvals are single-use:** an approval token is bound to
`(payable_id, gross_amount, vendor_id)`. If any of those change after
approval, the approval is void and the payable returns to step 7. This is what
stops an approved payable being edited into a different payment.
- **Reconciliation is set-based:** step 13 is safe to run repeatedly on the same
statement file; matching an already-matched line is a no-op.
---
## Escalation and rollback
**Escalation ladder.** Exception open [2] working days → remind the assignee.
[3] days → escalate to the deputy. [5] days → escalate to [Financial
Controller] and put the payable on the monthly exception review. Anything
touching E5 skips the ladder and goes straight to [Financial Controller].
**Rollback by stage.**
- Before step 8: safe to reverse entirely. Void the payable, keep the record.
- Between steps 8 and 11: void the approval, return to step 7, and notify the
approver that their approval was withdrawn and why.
- After step 11: the payment cannot be rolled back by the process. It is
recovered by a person contacting the bank and the vendor, and the process
records a `payment_incident` linked to the payable. Any blueprint that claims
to undo a released payment is describing something the bank will not do.
- After step 13: a wrong reconciliation is corrected by reversing the match, not
by editing the statement line.
**When the process stops trusting itself.** If step 5 returns `unclassified`
twice for the same payable, or if the unmatched count at step 13 exceeds
[5] lines in one run, stop the automated path and hand the queue back to a
person until someone has decided what changed.
---
## Permissions and sensitive data
- **Least privilege by step.** Steps 1–7, 9 and 10 need read access to invoices,
POs, receipts and vendor records, plus write access to the payable only. No
step in the automated path may write to the vendor master. Bank-detail changes
are performed by [Vendor Master Administrator] under A3, outside this process.
- **Payment initiation** is separated from payment release. The process may
assemble a proposal; only a named human at step 11 may release it.
- **Sensitive fields:** vendor bank account and IBAN, tax registration numbers,
contract pricing. Mask these in logs, notifications and any model prompt.
Step 5 receives document text with bank details redacted — the classifier does
not need them, and anything a model sees ends up somewhere it was not planned
to be.
- **The audit trail is append-only.** Corrections are new entries with a reason,
never edits over the top of the original.
- **Retention** follows the entity's records policy; 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 on [automated records](https://www.irs.gov/businesses/automated-records),
and confirm periods with your accountant.
---
## Test cases and acceptance criteria
Run each case on test data before the process handles a real payment run. Every
case states what must be true for it to pass.
| # | Case | Passes when |
| --- | --- | --- |
| T1 | Clean PO-backed payable inside tolerance | Reaches step 8 with no exception; variance and tolerance version recorded |
| T2 | Same invoice registered twice | Second registration blocked at step 4; both records retained; no second payment |
| T3 | Price variance above D1 | E2 raised, routed to the requester, payable held out of the run |
| T4 | Invoice with no PO in a PO-backed category | E3 raised; no retrospective PO is created by the process itself |
| T5 | Vendor absent from the master | E6 raised; process does not create the vendor |
| T6 | Bank-detail change requested by email | E5 raised; vendor blocked; A3 required; verification recorded against a number already on file |
| T7 | Partial delivery, [8%] short | D4 applied; only the received portion payable; expected receipt date recorded |
| T8 | Credit note against an earlier invoice | Netted within the same vendor account only; run total correct |
| T9 | Unmapped tax code | E4 raised on the posting only; the rest of the payable continues |
| T10 | Payable edited after A1 approval | Approval voided; payable returns to step 7 for re-approval |
| T11 | Payment run released twice | Second release rejected by the `run_id` check; no duplicate payment |
| T12 | Bank statement re-imported | Step 13 is a no-op on already-matched lines |
| T13 | Approver on leave | Reminder, then deputy, then controller — the run is not silently delayed |
| T14 | Model returns `unclassified` | Escalates to a human; no default handling applied |
**Acceptance criteria before this runs unattended**
- T1–T14 pass on test data, and the results are stored where a reviewer can
re-read them.
- Steps 8 and 11 are performed by different named people in every test run.
- Every test payable produces a complete audit record with no missing approver,
timestamp or reference.
- The exception classes have each fired at least once on real historical data,
not only on invented cases.
- A named finance owner has read this blueprint and the SOP together and agrees
they describe the same process.
Revision log: v1.0 — 2026-07-24 — initial draft — [Your name].
Limitations and when not to use this
- This is educational material about process design, not financial, tax or legal advice. Tolerances, approval bands, retention periods and tax treatment depend on your entity, jurisdiction and auditor, which is why both downloads leave them as placeholders.
- The playbook assumes purchase-order discipline for at least some spend. If nothing is raised as a PO there is no three-way match to automate, and the useful project is agreeing PO coverage with procurement first.
- Do not automate this at low volume. Below roughly one payment run a month, a written procedure and a shared checklist will do more for reliability than any automation, and cost nothing to change.
- Nothing here claims a connection to any particular accounting, banking or procurement system. What connects to what in your setup, and what any tool may write, is a question to settle before design.
Sources
- Standards for Internal Control in the Federal Government (Green Book) — U.S. Government Accountability Office Accessed 24 July 2026
- What kind of records should I keep — U.S. Internal Revenue Service Accessed 24 July 2026
- Automated records — U.S. Internal Revenue Service Accessed 24 July 2026
Bring your payment run to a 30-minute scoping call
Walk one real payables cycle through with us and leave knowing which steps could become code, which need judgment, and which keep an approver for good.
Bring your payment run to a 30-minute scoping callUli Prantz
Builds and operates all-agents
Uli Prantz builds all-agents, the process-automation platform this site documents. He writes about the operational side of automating recurring business work: where deterministic code beats model judgment, where it does not, and where a human still has to approve.