Invoice processing automation: three-way matching that only escalates the exceptions.
Extraction is the part everyone demonstrates. Matching, tolerances and variance chasing are the part that actually costs your finance team its week.
The same work, twice
- 1Pull the invoice out of the shared inboxAP · 4m
- 2Key the header fields into the ledgerAP · 7m
- 3Find the purchase order it belongs toAP · 9m
- 4Compare line items, quantities and totalsAP · 11m
- 5Email the buyer about a price varianceAP · 6m
- 6Wait for the buyer to replyBuyer · hours
- 7Route for approvalAP · 5m
- 8Schedule payment and file the documentAP · 6m
The shape of the run, drawn from the Coastline Logistics build. Your steps, timings and tolerances come out of the audit week.
Why this queue costs what it costs
Accounts payable is the most automatable process in most companies and the one most often half-automated. A tool reads the PDF, someone still opens the ledger, finds the purchase order, checks whether 96 units at a slightly different price is acceptable, and sends an email that will be answered tomorrow.
The saving is not in reading the invoice. It is in matching it against the purchase order and the goods receipt, applying your tolerances without a meeting, and turning the three that fail into a specific question sent to the person who can answer it.
Coastline Logistics ran invoice creation and matching as part of a wider order flow. In production, 38 of 38 invoices matched inside a run that finishes in under four minutes, and the flow as a whole returned 698 hours a month.
Three-way matching is where the hours actually go
An invoice on its own means nothing. It has to agree with what was ordered and what arrived, and the interesting cases are where those three documents disagree: a partial delivery, a substituted SKU, a unit of measure recorded as cases on one side and units on the other, a freight charge that appears on the invoice and nowhere else.
Automating this means writing your tolerances down, often for the first time. What price variance passes without a human, what quantity variance passes, which suppliers have negotiated terms that override the default, and what always needs approval regardless of size. That document is a deliverable of the audit week and it tends to outlive the automation.
Extraction is solved. Judgement is configured.
Reading fields off an invoice, including a photographed one, is now reliable enough to build on, provided low-confidence reads are treated as exceptions rather than facts. Nothing posts to the ledger from a field the extractor was unsure about.
What is not solved by a model is whether this particular variance is acceptable. That is a policy question, and we encode it as explicit rules you can read and change rather than as a prompt that behaves differently on Tuesday. The model reads; the rules decide; the log records which rule fired.
Exceptions get a person, on purpose
The goal is not zero human involvement. It is that a person only sees the three invoices out of forty-one that need a decision, with the purchase order, the receipt and the specific mismatch in front of them.
At Coastline, exceptions land in a channel with the context attached, and the team clears them in the time it takes to drink a coffee. That is a better outcome than a system that guesses, because a wrong payment costs far more to unwind than a two-minute question costs to answer.
Duplicate payments and the rails that prevent them
The failure everyone in finance has seen is the same invoice paid twice after a retry. Every run we build is idempotent and checkpointed: a failure stops at the step, alerts with context, and resumes from the checkpoint rather than from the beginning.
On top of that sits deduplication on supplier, invoice number and amount, plus a rule that no payment is released by the automation itself. The run stages the payment run; a person releases it. That line stays where it is regardless of how well the matching performs.
What it connects to
NetSuite, SAP, Xero, QuickBooks, Sage and most mid-market ledgers expose enough to read purchase orders and post invoices. Where a ledger does not, we use its supported import route on a schedule instead of automating its interface.
The inbox side is usually simpler than teams expect: a shared mailbox, a supplier portal that emails, and occasionally an EDI feed. The audit week confirms which sources are real and which are one supplier who still posts paper.
Cost, timeline and payback
A pilot on one supplier group starts at $4,000 and is usually live in three weeks. A full accounts payable flow with tolerances, approvals and ledger posting runs $12,000 to $30,000.
Payback is arithmetic you can do before calling us: invoices per month, minutes of handling each, loaded hourly cost. If that number is under a few thousand dollars a year, automate something else first, and we will say so on the call.
How the build runs
Map and count
Twenty real invoices, including the awkward ones. Volumes, handling times and the exceptions nobody documented.
Write the tolerances
Price and quantity variance rules, supplier overrides, approval thresholds. Signed off before anything is built.
Build and shadow-run
The run works alongside the team on live invoices while nothing posts, so disagreements surface before go-live.
Cut over and hand back
Documentation, an editable workflow, exception routing your team owns, and 30 days of support.
Before and after, in numbers
Coastline Logistics, where invoice creation and matching sat inside the wider order flow. Measured over 90 days from their run logs.
Where we have built this
Related reading
AI automation
The practice this sits in: map the process, build one run, route the exceptions.
n8n vs Make vs Zapier
Where an AP workflow should live, and what each platform costs at volume.
Questions before a pilot
High enough that extraction is not the constraint, but we do not quote a single number because it depends on your supplier mix and document quality. What matters more is the confidence threshold: low-confidence fields never post, they become exceptions, so the failure mode is a question rather than a wrong entry.
Yes, scans and phone photos both work. The realistic caveat is that a poor scan raises the exception rate, so if a supplier group is entirely paper, the first improvement is usually asking them to email a PDF rather than engineering around it.
No. The run matches, routes approvals and stages the payment run; a person releases it. That is a policy we hold on every accounts payable build, and it is the reason a matching error costs a conversation rather than money.
They are configured as their own paths rather than treated as failures. A partial delivery matches against the received quantity and leaves the balance open; a credit note is matched to the original invoice and applied. Both are among the first things we check in the audit week.
Usually the shadow-run period, which is a week or two of the automation processing live invoices while nothing posts and the team compares. Trust comes from disagreeing with it a few times and seeing why, not from a demonstration.
From $4,000, live in about three weeks, covering one supplier group end to end: extraction, matching against your PO data, exception routing and the documentation to run it. Ledger posting is included where your system exposes a write path.
Want to see this run on your own invoice processing?
Bring twenty real examples to the scoping call. The audit week counts the hours, writes the rules and comes back with a fixed price, and you keep the process map whatever you decide.