Pick one invoice and follow it. That is the only honest way to evaluate invoice automation, because the category is sold in pieces and bought as a whole.
A supplier invoice arrives by email. Something has to read it, work out which vendor and which entity, code it to an account, match it against a purchase order and a delivery, route it for approval, pay it, and post it. 7 steps. Most products automate 2 or 3 of them well and hand the rest back, and the hand-back is where the time goes.
At All Gravy, bills arrive by email and Light's AI reads and codes them on arrival. Nobody opens them. Nobody keys them in.
to process a multi-line invoice at Oper Credits, submitted by photo in Slack
invoices a month Tillo issues over the API with no review step in the UI
line invoices parsed and coded accurately at ControlPlane, per its CFO
The 7 steps, and where they usually break
Capture is the step everybody demos and the easiest to get right. Reading a PDF is a solved problem.
Identification is harder than it looks in a group. The same vendor bills 3 entities, sometimes on the same invoice number sequence, and getting the entity wrong at this step poisons everything downstream.
Coding is where accuracy stops being generic. A model can guess that a software invoice is software. It cannot know that this particular company splits tooling by department, or that a Microsoft charge might actually be advertising, without seeing how the company has coded things before. ControlPlane's CFO, Ben Fotheringham, names the version of this that defeats most tools: "It's the only product I've seen that can accurately parse and code our 100+ line invoices from Perk."
Matching against the purchase order and the goods receipt is the control step, and it is where automation either holds or quietly degrades to a threshold. Too Good To Go has the hardest version: almost none of its bills carry a purchase order number at all, so there is nothing on the document to match against.
Approval fails on adoption rather than logic. All Gravy runs approvals through Slack, and its Head of Finance and Ops clears them on the metro, which is the honest test of whether a flow fits a working day.
Payment is the step most invoice tools do not touch, which is why so many finance teams mark bills paid by hand afterwards.
Posting is where the whole thing either lands in the ledger as a finished transaction or arrives as a file somebody imports monthly.
"I don't have to look at 100 transactions, I have to look at three."
Peter Egehoved, COO and CFO, Dreamdata
The same problem going out
Outbound invoices have their own version, and it is usually worse because the source data is scattered further. The contract is in one system, the deal in the CRM, the billing terms in a spreadsheet somebody maintains, and the invoice is a monthly reassembly of all 3. Reassembly introduces error, error justifies review, and review creates a queue.
All Gravy's contract terms were too bespoke for standard tools to generate correctly, which is why invoicing stayed manual in its old ledger for years. The team built its own CPQ tool and connected it straight to Light, so a contract closing in HubSpot generates the invoice with nobody re-entering a number. Tillo goes further: 750 to 900 invoices a month leave over the API with no triage in the UI, and revenue lands in the books on T+1.
Point solution
Automates 3 of 7 steps
Capture and coding are strong, matching is partial, and payment and posting hand back to a person or a monthly import.
In the ledger
Arrival to posted, unbroken
The document is read, coded, matched against its PO and goods receipt, approved in Slack, paid and posted without leaving the system of record.
The measure
How many hands touch it
Oper Credits: under 1 minute per invoice. All Gravy: nobody opens the bill at all. Tillo: no triage on 750 to 900 outbound a month.
The gap that generates the exceptions
Worth naming, because it is the most expensive part and the least visible.
At one 4-entity group, card spend ran through a separate provider producing 500 to 600 transactions a month with no direct link into any ledger. Every one went in by hand, and a single missing receipt held up an entry while somebody tracked exceptions across 2 systems. That number is now zero.
Read that carefully. The exceptions were not caused by anything unusual about the transactions. They were manufactured by the pipeline moving them between systems. Every boundary an invoice crosses is a place it can stall, and most invoice automation projects add a boundary rather than removing one.
At Proxify, attaching receipts by hand runs about 2 minutes each, and a receipt that never arrives is VAT the company cannot reclaim. Neither number is dramatic on a single invoice. Both are substantial by the end of a quarter.
The evaluation
Take the last 20 invoices, inbound and outbound, and mark where a person touched each one. Then ask, for each touch, whether it was judgment or transport.
Transport is moving data between systems, retyping, importing, marking something paid because a feed did not. Judgment is deciding something genuinely ambiguous. Most invoice automation reduces transport in 1 or 2 steps and leaves the rest. The version worth buying removes transport everywhere, because the invoice never leaves the system it will eventually post in.
See how Light automates bills end to end, read about three way matching, or book a demo.