Designing an Accounts Payable Workflow That Scales Past the Inbox
Invoice processing breaks in predictable places as volume grows. A practical design for capture, approval and posting that holds up at scale without adding headcount.
The Inbox Is Not a Queue
Most accounts payable processes start with invoices arriving by email and someone working through them. This is not a workflow, it is a pile with an ordering. Nobody can see how many are outstanding, how long the oldest has been waiting, or which are blocked on an approval. Nothing is lost visibly — it is lost by being scrolled past. The first structural improvement is not automation; it is giving invoices a state, so that "received but not yet entered" is a thing you can count.
Separate Capture From Approval
Capturing what an invoice says and deciding whether to pay it are different jobs requiring different people. Collapsing them means a senior person doing data entry, or a junior person making commercial decisions. Capture first, into a reviewable record, and route the approval separately. The practical benefit shows up immediately: capture can be batched and largely automated, while approval can be parallelised across whoever owns the budget.
Capture the Fields, Not the Total
An invoice recorded as a single amount is nearly useless downstream. Capture the supplier and their GSTIN, the invoice number and date, the taxable value, and the tax split by head. That level of detail is what makes input credit reconciliation possible later — a lump-sum entry cannot be matched against GSTR-2B without going back to the source document. Line-level capture is worth having where the document supports it, particularly for purchase orders you intend to match against.
Keep a Human in the Loop Deliberately
Automated extraction is now good enough that the tempting next step is to post straight to the ledger. Resist it. The failure mode is not frequent errors, it is rare errors that nobody notices for a quarter. A review step where a person sees the extracted values next to the source document costs seconds per invoice and catches the things a model cannot: a supplier billing the wrong entity, a duplicate submitted under a new reference, an amount that is plausible but wrong.
Duplicates Deserve a Specific Control
Paying the same invoice twice is among the most common and most recoverable AP losses, and it is rarely caused by carelessness. It happens when an invoice arrives twice through different channels, when a supplier re-issues with a new number, or when a statement and an invoice are both entered. A check on supplier plus invoice number plus amount at the point of entry catches most of it. Near-matches — same supplier, same amount, dates a few days apart — should be flagged for a look rather than blocked.
Three-Way Matching Where It Earns Its Cost
Matching invoice to purchase order to goods receipt is the textbook control, and it is genuinely valuable for inventory and high-volume repeat purchases. It is disproportionate for one-off services where no PO exists. Apply it where there is a PO to match against and use approval thresholds elsewhere. A control that is applied everywhere regardless of value tends to be worked around, which is worse than a narrower control that is actually followed.
Measure the Queue, Not the People
The metrics that improve a payables process are queue metrics: how many invoices are unprocessed, the age of the oldest, how many are blocked and on what, and how many required correction after capture. That last one tells you whether your capture step is actually working. Counting invoices processed per person measures throughput without telling you whether the process is healthy, and it pushes people to clear easy items first.
What to Fix in What Order
If everything is manual, the highest-return change is capture, because it is the highest-volume, lowest-judgement step and the one where fatigue errors concentrate. Next is the duplicate check, which pays for itself the first time it fires. Approval routing comes third — it is more visible but usually less costly than the first two. Leave three-way matching until the earlier steps are stable, or you will be automating a process you are about to redesign.
Related
Finatica