How to Automate Accounts Payable: Invoice Capture to Three-Way Match to Posting, Step by Step
Accounts payable automation, step by step: invoice capture from any channel, field extraction with confidence, duplicate and fraud checks, three-way matching, approvals on the phone, posting to the ERP.
Written by Max Zeshut
Founder at Agentmelt
TL;DR: Accounts payable automation is one workflow from the supplier's invoice arriving — email, portal, scan — to an approved, coded invoice in the ERP ready to pay: capture, extraction with a confidence per field, validation and duplicate detection, three-way matching against the purchase order and the receipt, approvals routed to the right person on their phone, posting with the audit trail, and status replies to suppliers who ask. Clean matches within policy approve themselves; everything else has a named approver. The AP team handles exceptions instead of keying, cycle time drops from weeks to days, and the fraud checks run on every invoice instead of the ones someone had time to look at.
Buildable version: the invoice processing workflow — what arrives, what happens, who approves, a free template, and the price to have it run for you.
Step 0: the three decisions before any tool
- What is a clean match? PO exists, quantities received, prices within a tolerance you name (2% or $50, say). Those invoices will approve themselves within a policy limit; write the limit down.
- Who approves what? Non-PO invoices need an approver by cost centre and amount; mismatches go to the buyer. One matrix, in a sheet the controller owns.
- What never posts automatically? Bank-detail changes (a verification call, every time), new suppliers, anything over the policy limit. These are the fraud controls, and they are rules, not judgement.
Step 1: capture from every channel
Invoices arrive as PDF attachments to an AP inbox, through supplier portals, as scans, and increasingly as e-invoices. The workflow watches the inbox and the portals, saves every attachment to a document store with the email metadata, and classifies each one: invoice, statement, reminder, credit note, something else. Non-invoices are filed, not processed. The anti-pattern to avoid: someone forwarding invoices to the "AP system" — the system should read the inbox itself.
Step 2: extract the fields, with a confidence
Supplier, invoice number, dates, line items with quantities and unit prices, tax, totals, PO reference, bank details — extracted from the document by a model that reads any layout, each field with a confidence score. Low-confidence fields are highlighted for a person to check, never silently accepted; that is the difference between an extraction you can post from and one you cannot. A supplier's tenth invoice extracts better than its first, because the corrections feed back.
Step 3: validate and detect duplicates
Rules, not the model: the totals foot, the tax is arithmetically right for the jurisdiction, the supplier exists in the master (or is flagged as new), the invoice number has not been seen before from this supplier, and — the control that matters most — the bank details match the master. A change in bank details is not posted; it triggers a verification call to the supplier at a number you already have. This one rule stops the invoice-redirection fraud that AP teams lose real money to.
Step 4: three-way match
The invoice's lines against the purchase order's lines and the goods-receipt quantities in the ERP: right supplier, right items, quantities received, prices within tolerance. Clean matches proceed; mismatches carry the specific difference — "invoiced 120, received 100" — to the buyer. Non-PO invoices (utilities, subscriptions, services) are coded by the model from the supplier's history and routed to the cost-centre approver with the suggested code.
Step 5: route exceptions and approvals — on the phone
Clean matches within the policy limit auto-approve. Everything else goes to a named person in Slack, Teams or email with the invoice summary, the exception and approve / reject / query buttons; reminders escalate after a set time. Approvers approve on their phone in ten seconds, which is why the cycle time collapses: the invoice no longer waits for someone to open a desktop system.
Step 6: post to the ERP
Approved invoices are created in NetSuite, Xero, QuickBooks, Sage or SAP with the coding, the attachments and the approval trail, and scheduled for payment on terms. The ERP stays the system of record; the workflow only writes what a person or a policy approved. Duplicates were blocked before this step, not caught at month-end.
Step 7: answer the supplier
"Has our invoice been paid?" is a large share of AP's inbound email. The workflow answers it from the ERP — received on this date, approved, scheduled for that date — without a person, and routes anything else to AP with the thread. Suppliers stop calling, and AP stops looking things up.
The tools, and what talks to what
| Job | Tools | Note |
|---|---|---|
| Capture | The AP inbox (Gmail, Outlook), supplier portals, a scan folder, e-invoice feeds | The workflow reads them; nobody forwards |
| Document store | Google Drive, S3, the ERP's attachments | Every invoice kept with its metadata |
| Extraction and coding | A language model reading the document | Confidence per field; corrections feed back |
| Matching and posting | NetSuite, Xero, QuickBooks, Sage, SAP | The ERP stays the record |
| Approvals | Slack, Teams, email | Buttons on the phone |
| Automation | n8n, Make or Zapier — or the installed workflow | The free template is n8n |
What to expect
| Measure | Before | After | What moves it |
|---|---|---|---|
| Invoices touched by a person | 100% | 20–40% (exceptions and non-PO) | PO coverage; tolerance settings |
| Cycle time, receipt to approval | 2–4 weeks | 2–5 days | Approvals on the phone |
| Duplicate payments | Found at month-end, sometimes | Blocked before posting | The duplicate rule |
| Extraction accuracy on standard invoices | — | 95–99% of fields | Layout variety; scans vs native PDFs |
| Supplier status emails answered by a person | All | Near none | The ERP lookup |
| Early-payment discounts captured | Rarely | Routinely | Cycle time |
Build it yourself, or have it installed
The free template has the capture, extraction, validation, matching and approval steps wired; a first version runs in a day or two for a team with someone who uses n8n or Make and an ERP with a usable connection, followed by a few weeks in review mode where every posting is checked. Installed for you: live within two working days of access to the inbox and the ERP, $249 one-time, or $297 a month run for you for up to 1,000 invoices a month with one ERP and one AP inbox; the accounts payable teams package adds purchase orders and reconciliation. Several entities or currencies with their own approval matrices, an ERP without a usable connection, or matching across several systems are custom builds from the free audit.
Mistakes that make AP automation fail
- Extraction without confidence. A field that is wrong 3% of the time and never flagged is 3% of your invoices posted wrong.
- Auto-approving non-PO invoices. Only PO-matched invoices within tolerance and policy should approve themselves; everything else has a name on it.
- Bank-detail changes handled like any other field. They are the fraud vector; verify by phone, every time.
- Approvals on the desktop. If the approver has to open the ERP, the cycle time does not move.
- No supplier master hygiene. Four spellings of one supplier defeat the duplicate check; the spend-analysis normalisation fixes it as a side effect.
Questions, answered
What is accounts payable automation?
A workflow that takes a supplier invoice from wherever it arrives, extracts every field with a confidence, validates it and checks for duplicates and bank-detail changes, three-way matches it against the purchase order and the receipt, routes exceptions and approvals to the right person on their phone, posts the approved invoice to the ERP with the audit trail, and answers suppliers' status questions from the ERP. The AP team handles exceptions; the workflow handles the rest.
How does three-way matching automation work?
The invoice's lines are compared with the purchase order's lines and the goods-receipt quantities in the ERP: right supplier, right items, quantities received, prices within a named tolerance. A clean match within the policy limit approves itself; a mismatch goes to the buyer with the exact difference; a non-PO invoice is coded from the supplier's history and routed to the cost-centre approver.
Which ERPs and accounting systems work with AP automation?
NetSuite, Xero, QuickBooks, Sage and SAP directly; others through their import formats. The requirement is a way to read purchase orders and receipts and to create an invoice with attachments — most cloud systems have it; an ERP without one is a custom build with a file-based step.
How much does it cost to automate accounts payable?
AP automation platforms are priced per invoice or per user, typically from a few hundred to a few thousand dollars a month at mid-market volumes. The installed workflow here is $249 one-time in your own systems or $297 a month run for you up to 1,000 invoices, plus model usage of a few cents per invoice. Against an AP clerk's handling cost of $8–20 per invoice, it pays back within the first month at a few hundred invoices.