Supplier invoices that read and match themselves.

The problem

Supplier invoices arrive by email, by post, as photographs taken on a phone, attached to a text, and occasionally handed over on site in a condition that suggests they spent a fortnight in a van. Somebody opens each one. Reads it. Works out which job it belongs to. Checks whether the amount looks about right. Finds whoever is allowed to approve it. Waits. Then keys it into the accounting package. The published average for all of that is 9.84 dollars and 8.2 days per invoice.

The cost is not the keying. It is the waiting. An invoice sits for a week because the person who ordered the materials is on a roof, is not checking email, and is the only human alive who knows whether the delivery actually turned up. Nothing is broken. Everything is simply paused, in a queue nobody can see, and the first visible symptom is a supplier ringing up about a statement.

Then there is the fifth that genuinely do not agree. The price is not the price that was quoted. The quantity is three short because two pallets came the following Tuesday. The invoice is against a job number that was closed in April. Benchmarks put the average exception rate at 18.4%, and exceptions are expensive because an exception is not a task. It is a conversation between three people who are all somewhere else.

The pieces are all buyable. An invoice parser is a browser extension. Your accounting package has an approval button. The bank will happily take a payment file. What none of them hold is the state in the middle: that this invoice relates to that order, which was partly delivered, approved by somebody who was actually allowed to approve that amount, and has not already been paid once. Duplicate payment is the failure that funds this entire software category, and not one tool on that list can see it coming.

How it works

Seven things happen between the invoice arriving and the payment clearing. The aim of the first five is that a person never sees four invoices out of five.

1. 01Every invoice lands in one place, whatever shape it arrived inA dedicated inbox takes the emailed PDFs, a forwarding address takes the ones that went to someone's personal inbox, and a phone photograph of a paper docket goes to the same place from site. Suppliers do not have to change anything, which is the only realistic assumption: published benchmarks put the share of suppliers able to invoice electronically at 57%, so a system that requires them all to is a system covering half the problem.
2. 02It is read rather than scrapedSupplier, invoice number, date, currency, net, tax, total, payment terms, bank details and every line item, out of a layout nobody has seen before. Reading rather than template-matching is what makes this work on the long tail of small suppliers who each invoice differently and none of whom are worth building a template for. Low confidence on any field flags the invoice rather than guessing at it.
3. 03It is matched against what was ordered and what arrivedThree-way matching where there is a purchase order and a delivery note, two-way where there is only an order, and against the job or cost centre where there is neither, which in a small company is most of them. Tolerances are yours and are set in money and percentage, so a 40 cent rounding difference does not become a conversation and a 400 euro one always does.
4. 04Duplicates are caught before anything else happensChecked on supplier, invoice number, amount and date across everything already in the system, including invoices currently in flight and ones already paid. A supplier chasing payment often sends the same invoice again, which is how the same amount leaves twice. This check runs first for a reason: every later step is cheaper than recovering money that has already gone.
5. 05Approval goes to whoever is actually allowed to give itRouted by amount, cost centre and the delegation rules you already have on paper, with the approval happening where the approver already is rather than in a portal they have to be taught. Each one carries the invoice, the order, the match result and the variance, so the question being answered is specific rather than do you approve this. Unanswered approvals escalate on a timer to a named deputy.
6. 06It is posted, and the payment run is assembledPosted to the ledger with the coding already on it, and scheduled into a payment run according to its terms, so invoices are paid on time rather than early or late. Where there is an early settlement discount worth taking, the run says so with the arithmetic shown. The run is reviewed and released by a person. That is a deliberate stop, not a gap.
7. 07The payment is reconciled back to the invoiceCard spend and bank payments are matched back to the invoices they settled, so the ledger closes without anybody tying it out by hand, and a payment that did not go through is visible that day rather than at month end. Anything unmatched after the run surfaces immediately, because an unmatched payment is either a mistake or a supplier about to ring.

What it's built from

Five pieces, and the accounting package you already have stays exactly where it is. This sits in front of it rather than replacing it.

• Claude, for the reading and the judgementReads each invoice out of whatever layout it arrived in, pulls the header and every line, and explains in a sentence why an exception is an exception so the person picking it up starts from the question rather than from the document. It is also what makes the long tail work: a template-based reader needs a template per supplier, and most of your suppliers send you four invoices a year.
• n8n, the part that decidesSelf-hosted on European infrastructure, and the actual product. Matching tolerances, approval thresholds, delegation rules, escalation timers, duplicate windows and payment scheduling all live here as something you can open and read. When the approval limit changes, one person changes one number rather than four systems disagreeing about it for a quarter.
• Airtable, for the state in the middleWhere an invoice lives while it is in flight: matched or not, approved or waiting, on which run, against which order. This is the part no individual tool provides and the reason the system can answer what is the oldest unapproved invoice and who is sitting on it, which is a question most companies cannot answer at all.
• Stripe, for the spend that runs on cardsCard subscriptions and supplier card payments are a real and badly tracked share of what a small company spends, and the feed from them is what lets card spend be matched to an invoice like everything else. Bank payment runs stay with the bank, as a file it accepts. Nothing here moves money without a person releasing it.
• Slack, for approvals and exceptionsThe approval request arrives where the approver already works, with the invoice, the order and the variance attached, and an exception goes to finance with the reason written out. Teams or email work the same way. An approval queue in a portal somebody logs into weekly is an approval queue that adds a week.

What it's worth

Do this with your own numbers rather than ours. It takes a minute, and it is the only version of it worth believing.

• You process 250 supplier invoices a month and the published average processing cost of 9.84 dollars is roughly right for you.About 2,500 a month, nearly all of it people's time, spent on moving documents rather than on deciding anything.
• The published average exception rate of 18.4% holds, so 46 of those 250 need a person to ask somebody a question.The other 204 do not, and currently they are handled by the same process, at the same speed, by the same people. That is the actual waste: not the hard ones, the easy ones.
• Average processing time is the published 8.2 days and your terms are thirty.You are using a quarter of every payment window on internal handling. Suppliers experience that as you being slow, and it is the hidden cost in every conversation about terms.
• One duplicate payment of 1,800 euros gets out per year, which is a conservative number for a company of this size.Recovering it takes two people a fortnight of polite emails, and sometimes it is not recovered at all. The duplicate check is the cheapest insurance in the system.

These are illustrations using published averages and round numbers, not results we are reporting. Your invoice volume, supplier mix and approval structure will move every line, which is why the first fortnight of the build measures them rather than assuming them.

The research behind those assumptions

Published benchmarks rather than ours, from an annual survey of accounts payable teams. They describe the size of the problem, which is the number worth knowing before spending anything on it.

• $9.84is the average fully loaded cost of processing a single supplier invoice. Ardent Partners, State of ePayables
• 8.2days is the average time an invoice takes to get through the process, against terms that are usually thirty. Ardent Partners, State of ePayables
• 18.4%of invoices become exceptions, meaning something does not agree and a person has to resolve it. Ardent Partners, State of ePayables
• 79%lower processing cost, and the same figure again in speed, is what separates the best performing teams from everybody else. Ardent Partners, State of ePayables
• 57%of suppliers can submit an invoice electronically, which is why any system that depends on all of them doing so covers half the problem. Ardent Partners, State of ePayables

What it costs

This is sold as one system at the automation price on the services deck, and it sits at the upper end of that range: four to six weeks, five tools, and more rules to agree than anything else on this list. What moves it is the approval structure rather than the invoice volume. One company, one approver, one cost centre and no purchase orders is quick. Three entities, a delegation matrix, purchase orders on some spend and not others, and two accounting packages mid-migration is the top of the range.

The running cost is a small hosting line plus the per-document cost of the reading step, which is cents per invoice against a published average processing cost of nearly ten dollars. There is no per-approver seat licence, which matters because the approvers are usually the people nobody would buy finance seats for, and that is exactly why approvals wait.

Outside the build price is somebody watching it, which is the care retainer. Here that means watching the match rate and the exception reasons. A tolerance that was correct in January goes wrong the moment a supplier changes its pricing, and the symptom is not an error message. It is a slowly rising exception count that everyone gradually accepts as normal.

What goes wrong, and what happens then

Every one of these is in the build because it happens, not because somebody raised it once in a workshop.

• The same invoice arrives twiceCaught on supplier, number, amount and date before anything downstream runs, including against invoices already paid and ones currently in flight. This is the failure the whole system is worth paying for, because recovering money that has already left is far harder than not sending it.
• The invoice is for 2,400 and the order said 2,000Outside tolerance, so it stops and goes to a person with both documents, the difference calculated and the order history attached. It is never approved automatically on the basis that it is probably fine, and it is never rejected automatically either, because quite often it genuinely is fine.
• Half the order arrived in March and half in AprilMatching handles partial deliveries rather than treating a short delivery as a mismatch. An invoice for what actually arrived is matched against what actually arrived, and the outstanding balance stays open against the order rather than disappearing.
• The approver is away and the invoice is due FridayEscalates on a timer to a named deputy with the delegation limit applied, rather than waiting. The oldest unapproved invoice and who is holding it is a number on the weekly report, because an approval queue nobody can see is just a slower version of losing the invoice.
• A supplier emails new bank detailsNever applied automatically, ever. A change of bank details is the single most common invoice fraud, so it stops, is flagged loudly, and is verified by a person on a number already on file rather than one in the email. This is a hard rule.
• The reading is unsure about an amountLow confidence on any field routes the invoice to a person with the field highlighted, rather than posting a number the system is not certain of. A system that guesses quietly is worse than one that asks, because the error is found at the bank rather than at the desk.
• The accounting package rejects the postingRetried with backoff, then held in a queue and raised as an alert rather than dropped. The invoice is always recorded in the pipeline before any downstream system is asked to accept it, so nothing is ever only in flight.
• Somebody photographs a docket badlyUnreadable goes back as a request for a better photograph the same minute, to the person who took it, rather than sitting in a queue until month end. The fastest moment to fix a bad scan is while the person is still standing next to the paper.