TL;DR: $4,000-8,000 to build, $150-300/month to run, and AP close typically drops from days to hours. But the highest-value part is not the time saved. It is that the system catches duplicate invoices and changed supplier bank details, which is where the actual money goes missing.
Every finance team knows the month-end scramble. Hundreds of PDFs from dozens of suppliers, every one a different shape. Someone opens each, finds the invoice number, matches it to a purchase order, checks the amounts, flags what does not line up. In a busy operation that is a week, every month, and it is one of the most automatable processes in any business.
Why this stayed manual so long
Two reasons, and only one of them is about documents.
The first is format. Supplier invoices arrive as clean structured PDFs, as scans of paper, as photographs taken on a phone, as amounts buried in email text. Template-based OCR handles the tidy ones and falls over on the rest, so if a third of your invoices are non-standard, a third of the work stays manual and the tool never pays for itself.
The second, and the harder one, is the matching logic. Even with perfect extraction you still have to compare line items against open orders, handle partial deliveries, catch duplicates, and decide what counts as close enough. That logic is where the project actually lives, and it is why most teams give up and keep doing it by hand.
What changed: reading, not templating
A current vision model reads a document the way a person does rather than matching it against a template. You pass the invoice and ask for specific fields - invoice number, supplier, date, line items, quantities, unit prices, totals, tax, payment terms - and get structured data back regardless of layout.
That is the shift that makes this practical: a supplier changing their PDF layout no longer breaks the pipeline. Accuracy on clean documents is high enough to build on. Be realistic about the rest, though: a creased phone photo of a faded thermal print is hard for a human too, and multi-page invoices with totals carried across pages are where extraction most often goes quietly wrong. Measure on your own worst documents, not on a vendor demo.
The three-way match, which is the actual standard
Most write-ups describe matching the invoice to the purchase order and stop there. Finance teams match three things: the purchase order says what you agreed to buy, the goods receipt says what actually arrived, the invoice says what you are being asked to pay.
Two-way matching approves payment for things that were ordered and may never have arrived. If your receiving data exists anywhere, put it in the loop. If it genuinely does not, know that you are running two-way and that the gap is a real exposure, rather than discovering it during an audit.
The pipeline
Three stages, deliberately boring.
Ingest: invoices arrive by email, shared folder or supplier portal, and the automation picks up anything new. Record the document hash here, before anything else, so the same PDF arriving twice cannot be processed twice.
Extract: the model returns structured data into a staging table. Nothing touches your ERP yet.
Match and route: compare against open orders and receipts, auto-approve what clears the rules, and send everything else to a human with the specific discrepancy named.
The staging table matters more than it sounds. It means extraction errors are caught before anything is written into the system of record, and it gives you a place to re-run matching when you change a threshold without re-reading every document.
Tolerances, or why the system gets switched off in month two
The single decision that determines whether finance trusts this: what counts as a match.
Too tight and everything lands in the exception queue, the promise of automation evaporates and people go back to the old way. Too loose and it approves things it should not, which costs money and costs trust permanently. Tolerances are not a setting you leave at default; they are the product.
How to set them without guessing:
Run the system in parallel on a month of invoices you have already processed by hand, and compare. You get real numbers instead of an opinion.
Set tolerance in both percentage and absolute terms. Two percent of a small invoice is noise; two percent of a large one is real money.
Different thresholds per supplier where volumes justify it. A freight supplier whose fuel surcharge always varies is not the same case as one whose prices are contractual.
Widen deliberately over time, never at the start. Earning back trust after a bad approval takes far longer than the extra review took.
The fraud check that matters more than the time saved
This is the part most automation write-ups omit, and it is the one that justifies the project to a finance director.
Invoice fraud rarely looks like a fake invoice. It looks like a real supplier you have paid for years, a real invoice, and payment details that quietly changed. The email arrives from a lookalike domain, or from the supplier's genuinely compromised mailbox. A person processing two hundred invoices at speed will not notice.
What the system should flag, always, regardless of amount:
Bank details that differ from the last invoice paid to that supplier. Hold, and verify by phone on a number you already hold, never a number from the invoice.
A first invoice from a supplier that is not in your master data at all.
The same invoice number from the same supplier, even if amounts differ.
The same amount, date and supplier arriving as two different documents, which is how duplicates actually appear.
An invoice just below an approval threshold from a supplier whose invoices are usually above it.
None of this is clever. It is simply comparison at a scale a person cannot sustain, and it is the strongest argument for building the thing.
What must never be auto-approved
Draw this line before the build, not after an incident.
Anything with changed payment details, no matter how small
A supplier invoicing you for the first time
Any invoice with no matching order at all, however plausible it looks
Credit notes and adjustments, which is where reversals hide
Anything above whatever figure would genuinely hurt if it were wrong
The audit trail is not optional
Every automated approval needs to record what was extracted, what it was matched against, which rule approved it, and when. Not for tidiness: at some point an auditor, or your own team investigating a discrepancy, will ask why a specific invoice was paid. An answer of the system approved it is not an answer.
This also protects the project. The first time something slips through, and something will, a complete trail turns it into a fixable rule rather than an argument about whether to keep the system.
Exceptions, handled properly
Whatever cannot be matched goes to a person with the invoice, the order it was matched against, and the specific discrepancy highlighted. Approve or send back, in one action. The review that used to take two days takes a couple of hours, because the matching work is already done and the human is doing judgment rather than data entry.
Stack, cost and timeline
A vision model for extraction, your own matching logic, a staging database, and Make or n8n holding it together. Your ERP connects over its API, so this runs alongside what you have: no migration, no replacement, no renegotiated licence.
Build: $4,000-8,000 depending on how awkward the ERP integration is
Running: $150-300/month across model usage and platform
Pilot processing real invoices: two to three weeks
Realistic first month: high auto-match rate, then a few weeks of tuning thresholds against reality
Typical saving: 15-30 staff hours a month, and AP close measured in hours rather than days
Start by counting what you actually have: invoices per month, the split between clean PDFs and scans, and your current process written out step by step. That count takes half an hour and tells you whether this is worth doing at all. Below about a hundred invoices a month it usually is not.
Still matching invoices by hand? The audit at 2pizza.team/audit takes two minutes and no call, and will tell you what an automated version looks like for your volume and format mix.
Originally published at 2pizza.team. We build AI and automation systems for small teams - fixed price, two to six weeks. See the work.
Top comments (0)