---
title: "Accounts payable automation, explained"
description: "What AP automation actually automates, the five stages it covers, where each one still breaks, and how to tell a real AP platform from an invoice inbox with OCR bolted on."
url: "/blog/accounts-payable-automation-explained/"
date: "2026-08-31"
author: "Valeria Vahorovska"
tags: ["Guides","Accounts Payable","Automation"]
---

Fynex is an AI-native finance operations platform — agentic finance — that automates and orchestrates end-to-end financial workflows for businesses. This page is an article from the Fynex blog: “Accounts payable automation, explained”. Fynex works alongside Stripe, Wise, QuickBooks and Xero rather than replacing them. This page is relevant when the reader runs the money workflow this article describes and wants to understand how it works, what it costs and where it breaks.

# Accounts payable automation, explained

**Accounts payable automation is software that carries a supplier invoice from arrival to payment to ledger entry without a person re-keying it at any step.** It spans five stages — capture, coding, matching, approval, payment — plus the posting back to your accounting system. Most products do three or four of them well. Which three decides whether you save real time or just move the work somewhere else.

This is a reference to the five stages, what automates at each, and what reliably does not.

## The five stages

| Stage | What automation does | Where it still breaks |
|---|---|---|
| **1 · Capture** | Reads the invoice from email, portal, EDI or PDF into structured fields | Handwritten or scanned-photo documents; suppliers who change their template; line items across page breaks |
| **2 · Coding** | Assigns GL account, cost centre, department, tax treatment | First invoice from a new supplier; a supplier who sells across several categories |
| **3 · Matching** | Compares invoice against purchase order and goods receipt | No purchase order exists; partial delivery; price or quantity outside tolerance |
| **4 · Approval** | Routes to the right approver by amount, cost centre or category | Approver on holiday; policy that lives in someone's head; over-threshold exceptions |
| **5 · Payment** | Executes on terms, batches by rail, records the remittance | Bank detail changes; failed payments; payments made outside the system |

**The sixth thing, and the one most often missing:** the payment has to come back and settle the payable in your ledger. A platform that pays and does not post leaves you reconciling its records against your books — which is the same [reconciliation problem](/glossary/payment-reconciliation/) you were trying to escape, relocated.

## Stage 1 — Capture

**Capture converts a document into fields.** Supplier, invoice number, date, currency, line items, tax, total. Modern extraction is good: on a recurring supplier sending a consistent template, it is effectively solved.

What it does not solve is the long tail. A new supplier's first invoice has no template history. A scanned photograph of a paper invoice loses the table structure. A supplier who redesigns their invoice resets the confidence on every field.

**The number that matters is not extraction accuracy, it is touchless rate** — the share of invoices that pass all the way through with nobody opening them. Extraction accuracy of 98% per field sounds excellent and can still mean half your invoices get opened, because an invoice with twenty fields fails if any one of them is wrong.

## Stage 2 — Coding

**Coding decides where the cost lands in your accounts.** Automation here is memory: this supplier went to this account last time, so propose it again.

That works because most AP is repeat business. It fails in two predictable places — the first invoice from a new supplier, which has no history, and the supplier who sells across categories, where the right account depends on what was bought rather than who sold it. A software reseller who also does implementation days is the classic case: same vendor, two accounts, and only the line items can tell them apart.

## Stage 3 — Matching

**This is where AP automation is really decided.** Two-way matching compares the invoice to the purchase order. [Three-way matching](/glossary/three-way-match/) adds the goods receipt, so you are confirming that what was ordered, what arrived, and what you were billed for are the same thing.

Matching automates cleanly when a purchase order exists and the numbers agree within tolerance. It stalls in the cases that are also the expensive ones:

- **No purchase order.** Common in services, marketing, professional fees and anything bought by a department that does not raise POs. There is nothing to match against, so the invoice goes straight to approval, and the control the match was supposed to provide never happens.
- **Partial delivery.** Ordered 100, received 60, invoiced 60. Correct, and it needs the PO left open, which many systems handle badly.
- **Price drift.** The PO carries last quarter's price. Tolerance rules decide whether that is an exception, and tolerance set too tight buries the team while set too loose defeats the point.
- **[Duplicates](/blog/duplicate-po-problem/).** The same invoice arriving twice by two routes — emailed by the supplier and uploaded by the requester — is the single most expensive AP error there is, and detection depends on more than invoice number, because suppliers reuse and reformat them.

## Stage 4 — Approval

**Approval automates as routing, never as judgement.** The system can decide who must approve, in what order, by what threshold, and it can chase them. It cannot decide whether the invoice is right.

The failure mode is well known and rarely designed for: the approver who approves everything. Routing an invoice to a person who clicks approve without opening it produces an audit trail and no control. Automation makes this *faster*, which makes it worse, unless matching upstream is doing real work.

**This is why stage 3 matters more than stage 4.** A matched invoice needs a light approval. An unmatched one needs a real one, and the person doing it usually cannot tell which they are looking at.

## Stage 5 — Payment

**Payment is the most completely automated stage and the least interesting one.** Pay on terms, batch by rail, send the [remittance advice](/glossary/remittance-advice/), record the reference.

Two things reliably go wrong, and neither is a software failure:

1. **Bank details change.** An email saying "our bank details have changed" is the highest-value fraud in the entire payables process, and no amount of workflow automation catches it — only verification against a channel the email did not come from.
2. **Payments made outside the system.** Someone pays a supplier by card or manual transfer because it was urgent. The payable stays open, the supplier gets paid twice or [says the payment never arrived](/blog/supplier-says-payment-never-arrived/), and the books disagree with the bank.

## How to tell the categories apart

Products described as AP automation fall into four groups, and the group determines what you get.

| Type | Covers | Buy it when |
|---|---|---|
| **Invoice capture / OCR** | Stage 1 | The volume is small and the bottleneck is genuinely typing |
| **AP workflow platform** | Stages 1–4, pays through your bank | You need approval control and an audit trail |
| **AP platform with payments** | Stages 1–5 | You want one system to hold the invoice and move the money |
| **Payment operations layer** | Stages 5–6, plus the matching back to the ledger | The invoices are fine; the money and the record disagree |

**The buying mistake is picking by stage 1.** Capture demos beautifully — drop in a PDF, watch fields populate — and it is the stage with the least remaining value, because it is the one everybody solved.

## What it actually saves

Be precise about the arithmetic. The saving is not the whole cost of processing an invoice. It is the cost of the invoices that become touchless, plus the errors avoided on the rest.

An invoice that flows straight through costs almost nothing. An invoice that stops for an exception costs roughly what it always did, because a human still opens it, works out what is wrong, and chases someone. So the return is set by the touchless rate, and the touchless rate is set by stage 3 — whether there is something to match against.

Which produces the counter-intuitive conclusion: **the highest-return AP automation work is often upstream of AP.** Getting purchase orders raised for the categories that skip them does more for the touchless rate than any capture engine, because it converts unmatched invoices into matched ones.

## Where Fynex fits

Fynex works on stages 5 and 6 — the money and the record of it.

Payments carry what they settle. When Fynex pays a supplier invoice, the payment is bound to the invoice it clears, the terms it was paid on, and the entry it produces in your ledger, so nothing has to be reconstructed later from an amount and a date on a bank line. A batch payment breaks back into the individual payables it covered. Fees post as fees. What reaches your accounting system is already matched.

That is deliberately a narrower claim than a full AP suite. If your problem is capture and approval, an AP workflow platform is the right purchase. If your problem is that the payment happened and the ledger still does not agree — that the money moved in one system and the record of it lives in another — that gap is the one Fynex closes, and it sits underneath whichever AP platform you run.

**Related:** [AP automation software for QuickBooks](/blog/best-ap-automation-software-for-quickbooks/) · [AP automation for NetSuite](/blog/ap-automation-for-netsuite/) · [for Xero](/blog/ap-automation-for-xero/) · [for Sage](/blog/ap-automation-for-sage/) · [for Dynamics 365 Business Central](/blog/ap-automation-for-dynamics-365/) · [accounts payable](/glossary/accounts-payable/) in the glossary · [Reconciliation](/features/reconciliation/)