Key takeaways
- Treat accounts payable as a chain of separate stages, not one job. Matching, payment preparation and bank reconciliation are arithmetic and should become plain code; only extraction and exception handling genuinely need judgment.
- Keep two distinct human approvals — approving the invoice and releasing the payment — and keep them with different people. Automation that collapses both into one service account has quietly removed the control.
- Choose the first candidate on frequency and variability, not on how much it hurts. A daily, low-variability, reversible stage repays the effort; the month-end close, at twelve runs a year, does not.
- Never hand vendor master changes to an automated decision. A change of bank details on a payee record is the highest-value fraud target in AP and belongs to two named people.
- Whatever runs the process has to leave the same evidence a filing cabinet would: payee, amount, date, description and proof of payment, retrievable per invoice long after the run.
Where the week actually goes in accounts payable
The pain in a small finance team is rarely the ledger. It is the fetching, chasing and re-keying around it.
- Invoices arrive in five places. A shared mailbox, a supplier portal, a PDF attached to a thread about something else, and the occasional photograph of a receipt.
- Coding is tacit. Which GL account, which cost centre, which project — obvious to whoever has done it for two years, written down nowhere.
- The exceptions eat the day. Short delivery, a price uplift, freight billed separately, a wrong PO, or a non-PO invoice waiting on a budget holder who is not reading email: a minority of the volume, a majority of the effort.
The AP and invoice job chain, stage by stage
Most of that is automatable in principle. The useful question is which stages become fixed code, which need a model making a call, and which keep a person answerable however good the software gets. Seven stages, labelled by owner.
- 01IntakeTriggerAn invoice appears. Capture the document, record where it came from and when, and give it an identifier before anything else touches it.
- 02ExtractAI judgmentPull supplier, invoice number, date, currency, totals, PO reference and line items off an unfamiliar layout. Two hundred suppliers means two hundred layouts: judgment, not parsing. It should return a confidence signal, never a silent guess.
- 03MatchCodeCompare the invoice against the purchase order and the goods receipt: quantities, unit prices, tolerance bands, currency, and whether this invoice number has appeared before. Lookup and arithmetic, identical every run.
- 04ExceptionAI judgmentWhen the match fails, work out which failure it is: short delivery, price variance, freight billed separately, wrong PO, or a true duplicate. Classifying it needs judgment; what follows from each class is a rule you can write down.
- 05ApproveHuman approvalThe budget holder confirms the spend is real and coded correctly. This gate stays permanently — not because matching is unreliable, but because someone must be answerable for committing money.
- 06PayHuman approvalPreparing the run is fixed-rule work: group by due date, net off credit notes, produce remittance advice. Releasing it is a second approval, belonging to a different person from whoever created or amended the payee record.
- 07ReconcileCodeMatch cleared bank lines back to payments and remittances, close the ones that agree, surface the residue. Only what fails to match should reach a person.
Two stages need judgment. Two need a person and always will. The rest is arithmetic that most teams are still paying someone to do.
Illustrative volumes for a team taking 120 supplier invoices in a week, 90 of them PO-backed. Made-up figures, not customer results.
- 74 match order and receipt inside tolerance and post without anyone reading them.
- 16 fail the match: 9 price variances under two per cent, 4 short deliveries, 3 wrong PO references.
- 30 non-PO invoices need coding and a budget holder's approval.
- 2 are duplicates, caught at intake.
The 74 are pure code. The 46 needing judgment or an approver are where the week goes. Automating only the 74 removes most of the clicking and none of the hard thinking, which is still the honest place to start.
Which finance jobs are ready to automate, and which are not
| Finance job | Frequency | Risk if wrong | Variability | Approval | Verdict |
|---|---|---|---|---|---|
| Invoice intake and extraction | Daily | Low | High | None | Good first stage: errors are visible and cheap to correct. |
| Three-way match and posting | Daily | Medium | Low | None inside tolerance | The strongest candidate for plain deterministic code. |
| Exception handling | Daily | Medium | High | On supplier-facing messages | Keep the judgment, gate what leaves the building. |
| Payment run release | Weekly | High | Low | Always, by a second person | Automate the preparation. Never the release. |
| Vendor master and bank details | Occasional | Very high | High | Always, two people | Do not automate the decision at all. |
| Bank reconciliation | Daily to monthly | Medium | Low | Exceptions only | Strong second project once matching is codified. |
| Month-end accruals and close | Monthly | High | Medium | Controller sign-off | Twelve runs a year. Document first, automate later. |
Frequency and variability decide whether a stage is worth automating; risk and reversibility decide how much of a person stays in it. Our ROI calculator does the volume arithmetic.
The controls an automated AP process has to preserve
The oldest control in payables is segregation of duties. The GAO Green Book describes it as dividing key duties among different people — authorising, processing and recording, reviewing, and custody of assets — so that no one person controls every stage of a transaction. The person who approves a payment should not be the person who created the payee record.
Automation erases that control invisibly. If one account extracts the invoice, creates the supplier, approves the coding and releases the run, every step still looks correct and the control is gone. The two gates above must stay distinct, sit with distinct people, and record who approved what.
The second obligation is evidence. The IRS is explicit about what a supporting document must show — payee, amount paid, proof of payment, the date incurred and a description — and the same requirements apply to records kept in an automated system. A chain that cannot produce that per invoice, years later, has saved you nothing. It is why all-agents records every run and keeps it replayable, and why the steps you pin keep their approval permanently once the rest has become code.
How to start on your own invoice chain
- Write the procedure down first: trigger, tolerance bands, the exception classes you actually see, and who approves what. The procedure guide covers the format.
- Pick one stage, not the chain. Matching and posting is usually right: high volume, fixed rules, and a wrong answer shows up immediately.
- Decide the gates by risk before you build, using the approval patterns, and expect the payment gates to be permanent.
- Sanity-check the volume. Under a couple of dozen invoices a month, a weekly slot and a checklist win.
The playbooks below take one job each all the way through.
In this section
- Job playbookAccounts Payable AutomationIf you assemble the payment run yourself every week, this playbook takes the payables job apart step by step so you can see which parts are arithmetic, which need judgment, and which must keep your signature.
- Job playbookInvoice AutomationIf invoices reach you through a shared mailbox, three supplier portals and the occasional photograph, this playbook takes the document lifecycle apart so you can decide what the process does at each level of confidence in what it read.
Limitations and when not to use this
- This is process-design material for the people who run accounts payable. It is not financial, accounting or tax advice, and no substitute for your auditor. Obligations vary by jurisdiction, entity and industry.
- The terminology assumes purchase-order-based payables in a small to mid-sized team. Multi-entity consolidation, intercompany settlement, cross-border tax determination and statutory e-invoicing regimes change what intake and matching mean, and are not covered here.
- Do not start here if your finance stack is mid-migration or your chart of accounts is being restructured. Automating a process that changes shape every month produces work, not leverage.
- Nothing here states that all-agents connects to a particular accounting package, ERP or banking system. What a process can reach depends on what you set up, and we do not publish integration claims we cannot demonstrate.
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
Open the accounts payable playbook
One job, end to end: trigger, inputs, tolerances, exception paths, approval points, and a procedure you can edit.
Open the accounts payable playbookUli 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.