How to take the keying out of AP invoice entry — capture, match, and route — while keeping a human on every exception. A practical sequence, the failure modes, and where automation should stop.
Accounts payable is one of the few back-office jobs where the work is genuinely repetitive and the cost of a mistake is genuinely real. A bookkeeper opens a PDF, reads the vendor name, the invoice number, the line totals and the tax, types them into the accounting system, decides which GL account and cost centre they belong to, checks them against a purchase order if there is one, and routes the invoice for approval. Then the next PDF. A few dozen times a day in a small business; a few hundred in a mid-sized one.
The keying is the part worth automating. The judgement around it usually is not. Getting that line right is the whole game.
What "automating AP entry" actually means
It is tempting to picture a single button that turns invoices into ledger entries. In practice the work is four distinct stages, and they automate to very different degrees.
Capture. Pulling the structured fields off the document — vendor, invoice number, date, line items, subtotal, tax, total. Modern OCR and document-AI handle clean PDFs well and messy scans less well. This is where most of the manual time goes, and it is the stage with the highest, safest payback.
Coding. Deciding which GL account, cost centre, and tax treatment each line belongs to. Recurring vendors are predictable; you can learn the coding from history. New vendors and one-off purchases are not, and guessing here quietly corrupts your books.
Matching. Reconciling the invoice against the purchase order and the goods receipt — the classic three-way match. Where POs exist this is mechanical and a machine does it faster and more consistently than a person. Where they do not, there is nothing to match against, and no amount of software invents one.
Routing and approval. Sending the invoice to whoever owns the budget, collecting the approval, and posting it. This is workflow, not data entry, and it is the easiest stage to automate reliably because the rules are explicit: this amount, this department, this approver.
Notice that two of the four stages — capture and routing — are almost pure mechanism, and two — coding and matching-without-a-PO — carry real judgement. A sensible automation leans hard on the first two and treats the other two as assisted, not autonomous.
A sequence that holds up
The mistake we see most often is trying to automate all four stages at once, behind one opaque step, and then not trusting any of it. Build it in order instead, and keep a person in the loop at the seam.
-
Start with capture into a draft, never a post. Extract the fields and present them next to the original document for a one-glance human check. You have removed the typing — the slow, error-prone part — without handing the ledger to a model. On day one this alone is most of the time saved.
-
Learn coding from your own history, and only auto-apply it above a confidence line. If a vendor has been coded the same way for the last ten invoices, propose that coding and let the reviewer accept it with a keystroke. If it is a new vendor or an unusual amount, leave the field blank and flag it. Confident cases flow; uncertain ones stop. That is the entire trick.
-
Add three-way matching where, and only where, POs exist. For PO-backed invoices, match automatically and surface only the discrepancies — a price that moved, a quantity that does not line up, a duplicate invoice number. For non-PO invoices, route straight to approval; do not fabricate a match.
-
Automate routing last, because it is the safest and most satisfying. Once capture and coding are trustworthy, sending the right invoice to the right approver with the right context is a rules problem. This is where the remaining human minutes disappear.
Each step ships and earns its keep before the next one starts. If step two never clears your accuracy bar, you still keep the very real savings from step one.
The failure modes nobody mentions in the demo
Vendors do not cooperate. The same supplier sends a tidy PDF one month and a photographed scan the next, renames "Invoice No." to "Reference," and rounds tax differently. Capture accuracy is a distribution, not a number, and the long tail is where your exceptions live.
Duplicate and near-duplicate invoices are the expensive failure. Automation that posts without a duplicate check will, sooner or later, pay the same invoice twice — and unlike a typo, that one leaves the building. A duplicate guard on vendor-plus-invoice-number-plus-amount is not optional; it is the first control you build.
Silent miscoding is the insidious one. A wrong figure is loud and gets caught at reconciliation. An invoice posted to the wrong GL account is quiet — it balances, it just lands in the wrong place, and it surfaces months later as a variance nobody can explain. This is exactly why coding should be proposed and confirmed, not silently applied, until you have months of evidence it is right.
Approval theatre. If routing gets so smooth that approvers rubber-stamp without looking, you have automated the control out of existence while keeping the appearance of it. Good routing gives the approver the few facts that matter — amount, budget line, any matching discrepancy — so the approval stays a real decision.
Where the automation should stop
Some things in AP look automatable and should be left alone.
- Vendor relationships and disputes. When an invoice is wrong, the resolution is a conversation, not a workflow. Keep it with a person.
- First-time and one-off vendors. There is no history to learn from and the downside of guessing is a corrupted ledger. Route these to a human by default.
- Anything near a period close or an audit trail. The value of AP is that the numbers are trustworthy. Automation that makes them faster but less trustworthy is a net loss, and finance will — correctly — never adopt it.
The honest version of AP automation is not a robot that replaces the bookkeeper. It is a system that does the typing, the matching, and the routing so the bookkeeper spends their day on the dozen invoices that actually need a human judgement — and gets through three times as many in the same hours.
What "good" looks like after
You are not aiming for zero people. You are aiming for a person who reviews exceptions instead of keying every line. The numbers that tell you it worked are specific to your shop, so measure your own before and after: minutes per invoice, the share that flows through without a manual edit, duplicate payments caught, and how long an invoice sits between arriving and posting. If those move and your books stay clean, the automation is doing its job. If accuracy slips to make the dashboard faster, it is not — and the fix is to put the human back in the loop, not to push more through.
That is the whole posture: take the keying, keep the judgement, and prove it on your own invoices before you trust it with the close.