How AI reads my invoices without touching the money
# How AI reads my invoices without touching the money
For a long time the worst hour of my month was the same hour every month. I would open each invoice that had landed in my inbox and retype its numbers into a sheet. Supplier name, amount, due date, invoice number, row after row, dozens of times. Slow work, dull work, and dangerous in a quiet way, because one slip of a finger puts the wrong figure in the wrong row and nobody notices until much later, when it actually matters.
So I built a small system that does the reading and the typing for me. It watches for invoices as they arrive, extracts the handful of fields I care about, and lines them up in a clean sheet that I then check and approve myself. Before anything else, two disclaimers. It pays nothing and moves no money, ever. And none of this is accounting or financial advice. It is a description of a data entry tool, one that frees my limited attention for checking the work instead of producing it.
What automated means in this system
Invoices and money together are exactly the territory where loose language causes trouble, so let me define the boundary precisely. The system reads invoices and pulls numbers out of them. That is the whole job. Deciding whether a bill is correct, whether it should be paid, when, and from where, all of that stays with me, on every single invoice, with no exceptions.
The honest mental model is a very fast, very tireless data entry clerk who has never been given a key to anything. The reading is automated. The deciding is manual, and it will stay manual, because the deciding is where the real risk lives, and that seat belongs to a person.
Reading a messy invoice
Extraction sounds simple until you look at what actually arrives. Real invoices are chaos. Every supplier lays theirs out differently. Some send tidy PDF documents. Some send a phone photo of a crumpled printout. Some attach nothing and bury the figures somewhere in the body of an email. Step one is always the same, get plain text out of whatever showed up that day. For scans and photos that means OCR, the technology that turns the text in an image into characters a program can work with.
The raw text then goes to a language model along with instructions to find the specific fields I want. Supplier, total amount due, due date, invoice number. This is the part where a model genuinely earns its place, because it reads the way a person reads. It knows that amount due, total payable, balance owing, and grand total all point at the same underlying figure, even when they sit in completely different corners of the page from one supplier to the next.
A traditional program that looks for a number at a fixed position shatters the first time a supplier nudges their template. The model was never relying on the layout, so a supplier can redesign their invoice overnight, move every field, relabel everything, and the new version gets read the same way the old one did. That quiet resilience is the whole reason this approach survives contact with a real inbox.
The review sheet where I approve everything
Extracted numbers do not flow anywhere final. They land in a review sheet, one row per invoice, each field sitting beside a link back to the original document it came from. Then I go through it by hand. I glance from row to original, confirm the total matches what the document says, and mark the row approved, or flag it if anything looks off. Only rows I have personally approved move into my records. Nothing skips the queue.
I keep this step manual on purpose, even though automating it away would be trivial and would save a few minutes. The reason is compounding. A wrong number in my financial records does not hurt on the day it lands. It sits there quietly for months and surfaces at the worst possible moment, at tax time or during an audit, dragging a trail of downstream corrections behind it. Two minutes of scanning a sheet costs me almost nothing against that. The system took over the typing, which was the slow part. It handed the checking back to me, which was always the part that counted.
The hard limits
With anything near money, the limits are the design, so I will spell mine out plainly. The system has no connection to my bank or to any payment service, by construction, since day one. It cannot judge a bill legitimate. It cannot file anything for taxes and was never built to try. It cannot even mark its own rows as approved. Every one of those powers stays in my hands.
The principle behind the line is one I apply to everything I build. A tool that only reads and suggests can be wrong cheaply, because a person catches the mistake before anything happens in the world. A tool that acts on money directly can be wrong expensively, because by the time anyone notices, the money has moved and cannot simply be called back. So the machine reads and organises, while I approve and pay. Anyone telling you to wire a model straight into a live bank account has skipped the step where they imagine the day it misreads a digit.
What it costs to run
People always want real figures, so here they are. Reading one invoice costs a tiny fraction of a cent of model usage, plus the OCR step for the scanned ones, which is also cheap at the volume a single operator generates. A full month of invoices comes to maybe a dollar or two. It is metered, so I pay only for what runs, and to be clear it is a paid service rather than a free one. It just happens to be very cheap at the scale of one person's bills.
The real investment was elsewhere. Building the thing, then tuning it. Teaching it to handle the genuinely strange formats took several rounds of watching it fumble an odd layout and adjusting the instructions until it stopped. That time was the actual price of the system. The return is that a dreaded hour of retyping every month became roughly ten minutes of calmly approving rows, plus a whole category of typos that simply stopped happening. The running cost is a rounding error either way. The recovered hour and the absent mistakes are the entire payoff, and neither of them ever appears on a bill. I have found that pattern holds for most small automations worth building.
Where it still goes wrong
It does still make mistakes, and with money involved you want to know exactly which ones. The most common miss is a layout problem, where a supplier puts the final figure somewhere unusual and the model grabs a subtotal, a tax line, or a previous balance instead of the amount actually due. Next is the blurry scan, where OCR misreads a single digit and a five quietly becomes a six. Occasionally it swaps two dates, filing the invoice date where the due date belongs.
None of these has ever reached my records, and the reason is structural rather than lucky. Every row passes through my hands, so every one of these errors is the kind of thing the two minute check reliably catches, with the original document sitting right beside the extracted row. A wrong total jumps out the moment you glance across. The system is allowed to be wrong occasionally, precisely because it is never allowed to act on being wrong. I would much rather have a reader that fumbles a number in front of me than one that confidently files a bad figure I never get to see.
Whether you should build one
It depends almost entirely on volume. Two or three bills a month, just type them in, this much machinery would be absurd for a problem that small. But if supplier invoices or expense receipts arrive faster than you can comfortably process them, or you keep retyping the same few fields out of any recurring document, a reader like this genuinely returns your time.
Start narrow. Pick one supplier with a consistent format, get extraction working properly for just them, and approve everything by hand until the output has earned some trust. Then add the next format. Mine grew exactly that way, one layout at a time over several weeks, until it covered most of what lands in my inbox. It replaced none of my judgment about my own money. It removed the typing, and it left me in the seat for everything that counts.
More write ups of the small systems I run, including their failures, are on the [home page](/).
Get new guides and videos first — join the Telegram channel.