Invoice Processing Automation for Accounts Payable Teams: Inbox to Draft Bill, With Your Approval Matrix

An accounts payable team of two handles about four hundred supplier invoices a month. Each one is opened, read, keyed into the ledger, coded to an account, matched to a purchase order if there is one, and sent to someone for approval — by email, usually on a Friday, usually chased the following Wednesday. The close lands on day eight. Once a quarter, reconciliation finds a duplicate payment.

None of those steps needs judgement except two: whether the coding is right when the rules do not cover a supplier, and whether a bank-detail change on an invoice is genuine. This post is about automating everything around those two decisions so that the people make them and nothing else. It follows the invoice processing blueprint that the accounts payable team package installs.

The eight steps, and where a person is

1. Capture the invoice. An AP inbox label (Gmail or Outlook) or a supplier portal poll picks up the PDF or the email body.
2. Extract the fields. Supplier, invoice number, dates, currency, subtotal, tax, total, PO number, line items, and any bank details printed on the document — with a confidence score per field. Totals are copied, never computed; a printed total that does not equal subtotal plus tax is flagged, not fixed.
3. Validate and check for duplicates. Supplier plus number plus total against everything posted in the last year. The same invoice forwarded from two mailboxes is the most common duplicate; the second copy goes to the exceptions queue, not to the ledger.
4. Match to the PO and the receipt. Quantity and price within tolerance — typically two per cent on price, five on quantity. Outside tolerance, or no PO where the policy requires one, the invoice waits with the difference spelled out.
5. Route by amount and category. Your approval matrix decides who sees it: the budget owner under $2,000, a second approver above, the CFO above $25,000. The automation routes; it never approves.
6. Approve on the phone. One message in Slack or email with the supplier, amount, coding, PO status and the PDF. Approve, reject, or query.
7. Post to the ledger as a draft. Xero, QuickBooks Online, NetSuite or Sage, with the PDF attached and the action tagged "automated". Approval for payment stays in the ledger and stays yours.
8. Answer the supplier. "Where is my payment?" gets a drafted reply from the ledger's own status — approved on which date, in which payment run — for one tap before it goes.

Steps 2 and 8 use a language model. Steps 3, 4 and 5 are plain rules and a table, which is the point: the parts that must be auditable are deterministic.

The two checks that pay for the whole thing

Bank-detail changes. Business email compromise is the fraud that AP teams actually lose money to, and it works by changing the account number on an otherwise ordinary invoice. The automation remembers each supplier's known account from the first invoice it sees; any later invoice with different details is a hard stop, held with the old and new numbers side by side and a message to call the supplier on a number you already have. It cannot be approved by tapping; it can only be released after someone replies "verified".

Duplicates before posting, not at reconciliation. Finding a double payment at month-end means clawing it back. Finding it at step 3 means it never posts. In a typical first month the check catches two or three; each one is an invoice that arrived twice from two inboxes or a resend after a "did you get this?" email.

What "approval matrix" means in practice

A table with three columns: amount band, category, approver. Six to ten rows cover most companies. It lives in the workflow's configuration, not in anyone's head, and it is the control an auditor asks for: every bill in the ledger shows who approved it and under which rule. Anything the table does not cover routes to the AP lead — the automation does not guess an approver any more than it guesses an account code.

What the ledger sees

Every bill the automation creates is a draft, carries the source PDF, and is tagged "automated" with the approver's name. Nothing is approved for payment and no journal is posted by the workflow. The reconciliation step of the same package — the financial reconciliation blueprint — proposes entries for the breaks it explains; an accountant posts them. That separation is what lets a two-person team run this without a control gap.

Where the standard version stops

One entity, one ledger, one AP inbox, up to about a thousand invoices a month. Several entities or currencies with intercompany reconciliation, three-way matching against goods receipts in a warehouse system, and supplier portals where vendors submit and track their own invoices are custom builds — the blueprint page lists the triggers before you pay.

For the team that owns AP

The accounts payable team package installs this blueprint first — a kit for $49 to import yourself, an install for $249 in a 45-minute session in your own ledger, or the package at $490 that adds purchase orders and daily reconciliation. For an accounting practice running AP for several clients, the accountant package is the same blueprint framed for a practice. Companies that want it hosted, monitored and reported on run it as a managed automation instead.

See also AI finance agents and the month-end close post.

Sources and further reading

• Xero, Developer documentation — the Invoices (ACCPAY) and Attachments endpoints the draft-bill step uses: https://developer.xero.com/documentation/
• Intuit, QuickBooks Online API: getting started — the Bill endpoint for the QuickBooks variant: https://developer.intuit.com/app/developer/qbo/docs/get-started
• Oracle, NetSuite documentation — vendor bills and the REST record service: https://docs.oracle.com/en/cloud/saas/netsuite/index.html
• FBI Internet Crime Complaint Center, Business email compromise — the fraud the bank-detail hard stop is designed against: https://www.ic3.gov/CrimeInfo/BEC