Stop retyping supplier invoices
Supplier invoices arrive as PDFs, and somebody retypes them. It's the most requested automation there is, and the one I most often see built badly. Below is how I actually assemble the working version, including the parts that fail and the point where I'd tell you not to bother.
The questionHow do I get invoice data out of my inbox and into my accounts automatically?
How the working version is put together
Watch one mailbox, not the inbox
A trigger watches a single label. Suppliers send to invoices@, or the messages carry a label, and the automation only ever sees that. I treat this as a security boundary. An automation holding read access to everything becomes a data protection question somebody has to answer later.
Normalise the attachment
Invoices arrive as clean digital PDFs, as scans, and as photographs of paper taken on somebody's phone in a warehouse. Text PDFs I read directly; scans and photos go through OCR first. A pipeline that assumes every invoice is a tidy PDF demos beautifully and falls over in week two.
Extract into a strict schema
A language model reads the document and returns a structured record: supplier and invoice number, both dates, the three totals with their currency, and the line items underneath. I care far more about the instruction than about which model runs it. Asking for a strict schema, and telling the model to return null when it isn't sure, is what separates a missing field you can see from a wrong number you can't.
Reconcile before booking
This is the stage I most often find missing. Do the line items sum to the net. Does net plus VAT equal gross. Is that VAT rate one that actually exists. Have you paid this supplier before, and if not, does anyone know why they're invoicing you. Is this invoice number already in the books, because duplicate payment is the failure in this process that costs real money. Anything that fails a check lands in a human queue and never reaches the accounts.
Land it where your books live
The accounting software through its API, a database, or genuinely a spreadsheet if that's the honest answer. I file the PDF against the record so the original is one click away when somebody queries a line six months later.
Extract and validate Gmail invoice PDFs into Google Sheets with OpenAI
I've published this as a free n8n template, so you can read every node before you decide whether you want help with it. It's live in the n8n creator library.
Open the template ↗What the manual version really costs
Four minutes per invoice, give or take. I measured that on my own operations; it isn't a figure I lifted from a vendor study. Open the email, open the PDF, read off the supplier and the date and the invoice number and the three totals, type them into the accounting system, file the PDF somewhere findable, mark the email done.
At twenty invoices a month that's survivable. At four hundred it's more than a full working day, every month, spent moving numbers between two screens. The hours are rarely what I end up discussing with anyone, though. The person doing this is usually the same person who'd otherwise be chasing whoever hasn't paid you.
The parts that break
Here's what I actually watch go wrong. Multi-page invoices where the total sits on page three and the model confidently reads page one. Credit notes, which look exactly like invoices except the sign is inverted, and which will cheerfully be paid as invoices if nothing checks. Suppliers who redesign their template without telling anyone. A euro invoice booked as sterling. The same invoice arriving twice because somebody chased it.
None of that's exotic and all of it is cheap to catch. It's also why I wouldn't read a demo running on five invoices as evidence of anything. When you're buying this from anyone, including me, the question worth asking is what happens on the day extraction gets it wrong.
What it costs to run
Less than most people expect on inference. A page of invoice text makes a small prompt, and what you already pay for the automation platform will dominate the running cost long before the model calls do.
In my own operation the honest cost sits somewhere else. Somebody still has to work the exceptions queue, and somebody has to notice when a supplier changes their layout. Automation moves that work, it doesn't delete it, so treat any quote assuming zero human involvement afterwards as a quote for something you'll switch off within a quarter.
Why take this from me
Because I run it. The pipeline described above isn't a proposal I'm pitching; it feeds a live production platform, and the case study below links to the running thing instead of a screenshot. I build the surrounding machinery too: a store that fulfils itself, a content pipeline that publishes across nine brands, and an operational brain that's open source, so you can read how I build before paying me anything.
The fair objection is that all of this is my own operation. It isn't a client roster. That's true, and I'd rather say it here than have you notice it. There are no reviews on this site because I don't have any yet.
When I would tell you not to build it
Below roughly thirty invoices a month, don't. The exceptions queue will cost you more attention than the retyping ever did, and you'll have bought a system to maintain in exchange for saving two hours.
I'd check your accounting software first as well. Several now ship invoice capture that's good enough, and paying me to rebuild a feature you already own is the most avoidable spend in this whole category. If it turns out you have it, you've saved a project and we've both had a useful conversation.
What lands on your desk
- The pipeline running in your own account, on your own mailbox, under your own credentials
- A validation layer that quarantines anything failing to reconcile instead of booking it anyway
- Duplicate detection keyed on invoice number and supplier, because paying twice is the expensive failure
- An exceptions queue a human can actually work, not a log file nobody opens
- A written walkthrough, so whoever touches it next is not dependent on me
Open the proof
Published case studies of systems that are running. Each links to the thing itself.
The platform this pipeline feeds ↗Booboo on GitHub (MIT, read the code) ↗
Questions this page answers
- How does the automation read invoice PDFs and scans?
- Text PDFs are read directly. Scans and photographed invoices go through OCR first, because assuming every invoice is a tidy PDF is what makes a pipeline fail in week two.
- What stops a wrong number getting booked?
- I check the numbers before anything gets booked. The line items have to sum to the net, and net plus VAT has to equal gross. I also check the VAT rate is real, and anything that fails lands in a human queue instead of your accounts.
- What does it cost to run?
- Less than most people expect on inference, since a page of invoice text is a small prompt. What you already pay for the automation platform will dominate the running cost long before the model calls do.
- Below what volume should I not bother?
- Below roughly thirty invoices a month, don't. The exceptions queue will cost you more attention than the retyping ever did.
- Is there a free way to try this?
- There is. The pipeline is published as a free n8n template in the n8n creator library, so you can read every node before deciding whether you want help with it.
Want this built and handed over working?
One line is enough to start. You get an honest answer on fit, and a number rather than a discovery call.
Start a brief