Part of our series on Claude for finance teams. The surface map is in Claude Has Four Surfaces.
Accounts payable is the most automatable function in finance and somehow still the most manual: invoices arrive as PDFs in someone's inbox, get keyed into a system by hand, chased through approvals by Slack ping, and paid in a batch someone assembles in a bank portal at 16:45 on Thursday. Every step is rule-driven. Every step is also, in most companies, a person.
The Claude-era version of AP keeps exactly one of those people-steps — the signature — and hands the rest to agents. Here's how the pipeline actually runs.
Stage 1: The inbox that processes itself
Your AP address (bills@yourcompany…) is wired to a bill-processor Managed Agent. When an invoice arrives:
- It reads the email and attachments and identifies the document type — invoice, credit memo, or a payment receipt that needs no action.
- It extracts vendor, invoice number, amounts, due date, tax, and line items.
- It matches the vendor record — or, for a new supplier, routes creation through master data instead of inventing a duplicate "Amazon EU S.à r.l. (2)".
- It codes the expense, resolves the tax treatment, and submits the bill through the approval workflow — with the original PDF linked to the entry as evidence.
Documents the agent can't classify confidently aren't guessed at — they queue for a human with the extraction shown, so review takes seconds, not re-keying. After an extraction-quality incident last year we added explicit review triggers for low-confidence cases; the honest lesson is that the agent's job includes knowing when not to act. (Watch a real run.)
Stage 2: Approvals that scale with risk
Not every bill deserves the same ceremony, and pretending otherwise is why approval queues rot. Every submission flows through risk-based lanes:
- Green — routine, validated, within thresholds: flows straight through.
- Yellow — larger amounts, new vendors, unusual coding: waits for one approver.
- Red — the big or strange: multi-level approval.
The thresholds and rules are yours, readable, and changeable. The practical effect: approvers see only what needs a human, with the document one click away — and the audit trail records who approved what, when, against which evidence.
In Chat, AP status questions stop requiring a report: what's due in the next 14 days, what's stuck in approval and on whom, did we already pay this — it looks like a duplicate of last month's invoice? (Duplicate detection is exactly the kind of cross-checking a model with ledger access is good at.)
Stage 3: The payment run, prepared — not sent
On schedule, a payment-proposal agent assembles the run: approved bills due in the window, balance check, your prioritization rules, early-payment discounts flagged when worth taking. A human reviews the proposed batch, signs it through the approval lane, and transmits the bank file (Wise CSV today).
No agent moves money. The run is prepared autonomously and executed by a named person — the same division of labor we use everywhere, and in AP it's the difference between automation you can defend to an auditor and automation you can't. Employee expense reimbursements ride the same rails as vendor bills.
Stage 4: Closing the loop
When the payment hits the bank statement, the reconciliation agent matches it back to the bill — so "paid" in the ledger means cleared at the bank, not we sent a file. Vendor questions ("did you pay invoice 2066?") become a ten-second Chat lookup with the entire chain — email → extraction → approval → payment → bank line — attached.
What's real today — and what isn't
Real, shipping now: email-to-posted-bill processing with document evidence; vendor matching and master-data-gated creation; risk-based approval lanes; agent-prepared payment proposals; human-signed batches transmitted as Wise CSV; payment-to-statement reconciliation; expense reimbursements through the same flow; aging and cash-requirement views on demand; full audit trail per row including agent actions.
Not there yet — and we'd rather tell you: purchase orders and three-way matching (PO ↔ receipt ↔ invoice) are not the focus — if your AP is procurement-heavy manufacturing, the fit is partial today; supplier portals and supplier-side payment status pages don't exist; autonomous payment execution is deliberately absent (see Stage 3); bank-file formats beyond the current set (Wise CSV; pain.001 in the connector stack) depend on your bank's coverage; and OCR on terrible scans is honest-best-effort — a photographed, crumpled taxi receipt still might route to a human, which is the correct failure mode.
How AP teams adopt this
Forward ten invoices to the bills address in bridge mode and watch the queue — that's day one, no migration. Most teams then turn on the approval lanes (the part that fixes the Slack-ping culture), and only later hand over the payment-run assembly, because trust in the run follows from a few cycles of watching the proposals match what you'd have assembled yourself.
The control philosophy — agents propose, humans sign — is in The Thinking Behind Artifi. Real runs in the walkthroughs.