Finance & Accounting

Finance Automation: Accounts Payable and Invoice Workflows

If you run accounts payable for a small team, this section breaks the invoice chain into its seven stages so you can see which ones can run without you and which must keep an approver.

Uli PrantzBuilds and operates all-agents
Published
Key takeaways

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.
Accounts payable is not one job. It is a chain: an invoice arrives, the data comes off it, it is matched against the purchase order and the goods receipt, the failures get worked, a budget holder approves, a second person releases the payment, and the bank statement is reconciled. Those stages are not the same kind of work: most are arithmetic, two need real judgment, and two must keep a person answerable permanently. This page maps the chain so you can pick where to start. It is educational material about process design, not financial, accounting or tax advice.

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.

  1. 01IntakeTrigger
    An invoice appears. Capture the document, record where it came from and when, and give it an identifier before anything else touches it.
  2. 02ExtractAI judgment
    Pull 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.
  3. 03MatchCode
    Compare 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.
  4. 04ExceptionAI judgment
    When 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.
  5. 05ApproveHuman approval
    The 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.
  6. 06PayHuman approval
    Preparing 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.
  7. 07ReconcileCode
    Match 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.

One week of supplier invoicesSimulated example data

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

Judge a finance candidate on all four axes — frequency, risk, variability and approval need — not on how annoying it feels.
Finance jobFrequencyRisk if wrongVariabilityApprovalVerdict
Invoice intake and extractionDailyLowHighNoneGood first stage: errors are visible and cheap to correct.
Three-way match and postingDailyMediumLowNone inside toleranceThe strongest candidate for plain deterministic code.
Exception handlingDailyMediumHighOn supplier-facing messagesKeep the judgment, gate what leaves the building.
Payment run releaseWeeklyHighLowAlways, by a second personAutomate the preparation. Never the release.
Vendor master and bank detailsOccasionalVery highHighAlways, two peopleDo not automate the decision at all.
Bank reconciliationDaily to monthlyMediumLowExceptions onlyStrong second project once matching is codified.
Month-end accruals and closeMonthlyHighMediumController sign-offTwelve 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

  1. Write the procedure down first: trigger, tolerance bands, the exception classes you actually see, and who approves what. The procedure guide covers the format.
  2. Pick one stage, not the chain. Matching and posting is usually right: high volume, fixed rules, and a wrong answer shows up immediately.
  3. Decide the gates by risk before you build, using the approval patterns, and expect the payment gates to be permanent.
  4. 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

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

  1. Standards for Internal Control in the Federal Government (Green Book)U.S. Government Accountability Office Accessed 24 July 2026
  2. What kind of records should I keepU.S. Internal Revenue Service Accessed 24 July 2026
  3. Automated recordsU.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 playbook
About the author

Uli 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.

Bring one process. We will scope it in 30 minutes.

You leave the call knowing whether it is a fit, what can become code and what still needs a person.

Book a discovery call