What does invoice processing cost you today?
This cost hides in two places.
The visible half is the keying. Invoices arrive by email, by post, in a shoebox and increasingly as a photograph on a client's phone, and somebody turns them into ledger entries. That work is done by the people you would rather have doing advisory work, in the fortnight when everything else is also due.
The invisible half is the querying. A missing invoice for a payment on the bank statement. A supplier whose name does not match the ledger. A VAT treatment that looks wrong. Each is small. Together they are why a set of books that should have taken two days took five.
We will not borrow a number for either half, because every published figure on cost per invoice that we could verify comes from a software vendor measuring its own product. Instead, take last month, count the invoices you processed for your three largest clients, and count how many needed a question asked. The second number predicts what an automation is worth.
What exactly gets automated?
Six steps. The sixth separates a build from a demo.
Reading the invoice, whatever it arrives as. PDF, scan, photograph, email body or structured file. Supplier, invoice number, date, net, VAT, gross, line items and any purchase order reference.
Identifying the supplier properly. Not by string match on the name at the top, but by the identifiers that do not change: VAT number, bank details, previous invoice patterns. This is what stops "J. Murphy Builders" and "Murphy Builders Ltd" becoming two ledger accounts.
Matching. Against the purchase order or goods received note where they exist, and the expected pattern for that supplier where they do not. A recurring monthly invoice at the usual amount is a different risk from a first invoice from a new supplier.
Duplicate detection. Not just the same invoice number twice. The same invoice arriving as a PDF on Tuesday and a scan of the posted copy on Friday, different file name, different total.
Coding and posting. To the account that supplier is normally coded to, with the VAT treatment it normally carries, document attached to the entry.
Routing the exceptions and keeping the trail. Anything the system is not confident about goes to a queue with the reason in plain words, not a confidence score. Every invoice carries its own state, so it is posted exactly once and never silently dropped.
This works across your client base rather than one client at a time, and needs no change of accounting software.
What still needs a person?
Four things, none a limitation we hope to remove later.
The exception queue. This is the deliverable, not the failure mode. The exceptions are genuine: a real mismatch, a real duplicate, a real question about VAT treatment. A person spends the day on forty real questions instead of four hundred documents.
Anything over the approval threshold. You set the figure, per client if you want. Above it, a named person approves.
Any coding decision that sets a precedent. The first time a new expense type appears, or a supplier's treatment changes, a person decides and it is recorded. After that the system follows it. That is the difference between a system that learns your conventions and one that invents its own.
The sign-off. Whoever signs the accounts signs the accounts.
A machine that posts unsupervised is not the offer. Ask anyone pitching you one what happens the first time it is wrong across a hundred invoices.
How is the result measured?
Four numbers, agreed before anything is built, with a month of history each.
Straight-through rate, the proportion of invoices posted with no human touch. It climbs as the coding precedents accumulate, then flattens, and where it flattens is the honest answer about your book. It is not 100% in any practice we would describe.
Exceptions per hundred invoices, and why. A falling rate is good. One that falls because the thresholds were loosened is not, so the reason codes matter as much as the count.
Time from invoice arriving to invoice posted. Measured in days, which surprises people: the keying takes minutes, the waiting takes weeks.
Errors found after posting. The only one that tells you whether the straight-through rate is real. Count them before as well: the manual baseline is never zero.
What could go wrong?
It posts a duplicate. The most expensive single failure, because it moves money. Detection has to work on more than invoice number, and the per-invoice state stops one document being posted twice by two routes.
It is confidently wrong at scale. A wrong VAT treatment applied by hand affects one invoice. Applied by a rule, it affects every invoice from that supplier until somebody notices.
A supplier is not who the invoice says they are. Invoice redirection fraud works because a changed bank detail on a familiar-looking document passes a human eye in a hurry. Bank detail changes always require an out-of-band check by a person.
The exception queue becomes a second inbox. If exceptions arrive without a reason and without the document attached, the person working it is doing the old job with extra steps.
What does Revenue's e-invoicing mandate change about this?
It changes what is worth building, which is why to think about it in 2026 rather than 2028.
Most invoice processing automation sold today solves a document problem. The mandate slowly takes that problem away, because Revenue states that under ViDA, e-invoice structures must comply with European Standard EN 16931 using structured data formats, and that "current practices, including issuing PDF invoices or scanned paper invoices will no longer satisfy VAT compliance requirements".
When an invoice arrives as structured data there is nothing to read. What remains is the part that was always the actual work: is this invoice right, does it match what was agreed and what arrived, should it be paid now. So automation aimed at reading documents is depreciating and automation aimed at checking transactions is not. Invoices outside the mandate keep arriving in the old formats for years, so build for the decisions rather than for the reading. The dates and who they catch are on our Ireland e-invoicing page.
How long does it take to put in?
Three to six weeks, depending on the first wave.
A session on your coding conventions, approval thresholds and which clients go first. A build against a month of invoices you have already processed, so you can compare what it would have done with what you did. A parallel run where it posts nothing and produces a shadow ledger you check. Then live.
Then we hand it over. No retainer, no per-invoice licence, and the coding rules are yours to change. If you want to know where this sits against everything else on your list, that conversation is the opportunity review, and it starts with a month of your own invoices rather than with software.