How to stop retyping invoices and receipts

Every month there is a pile. Purchase invoices that arrived by email in ninety different layouts, and a bag or a folder of receipts, some of them photographed badly on a phone, some of them thermal paper that has already started to fade.

Somebody keys all of it in. Then somebody checks the keying. This is about what you can get back instead, and how to set it up so it survives real suppliers rather than the tidy ones.

Why invoices are harder than they look

Every invoice contains the same dozen facts, and no two suppliers agree on where to put them. The total might be bottom right, or in a summary box at the top, or on the second page after the line items. The VAT might be a column, a row, or a single figure at the foot.

That is why invoice scanning software with a template per supplier becomes its own job. You set one up, it works, and then that supplier changes their layout or you take on eleven new ones. The maintenance is the cost, not the setup.

Invoice data extraction that lasts works the other way round. You describe what you want once, in the terms you would use to a new colleague, and that description holds across every layout, because what a value is does not change between suppliers even though where it sits does.

Receipts are a different problem

Invoices are at least produced by a computer. Receipts are the half nobody volunteers for: creased, faded, photographed at an angle on a restaurant table, sometimes with the total handwritten on the bottom.

Most receipt OCR gives you a wall of text and leaves you to find the total in it, which is not obviously faster than reading the receipt. What you actually want from receipt scanning software is the same six things off every one, in a sheet: date, merchant, net, VAT, gross, and which claim or job it belongs to.

Two practical notes worth passing to whoever collects them. Flat beats sharp, because a photograph taken square-on reads far better than a crisp one taken at an angle. And thermal receipts fade in months, so the photograph taken on the day is often better evidence than the paper itself by the time you see it.

What you get back

One sheet, whatever went in. You choose what a row means, and it is worth deciding that before anything else, because it is the difference between a useful sheet and a useless one.

For coding a purchase ledger you usually want one row per invoice: supplier, invoice number, date, net, VAT, gross. For anything where the detail matters, a cost analysis, a job costing, a VAT review, you want one row per line item instead, with the invoice it came from carried on every row. Receipts are almost always one row each.

Every row carries the file it came from, so a figure you do not believe is one click from the document that produced it. That matters more than it sounds when somebody queries a number four months later.

Describing what you want, so it survives real suppliers

This is where a setup either holds up for a year or becomes a chore. A few things make the difference, and none of them is technical.

• Ask for what you will use, and nothing else. A description with forty fields is not more accurate than one with eight, it is just slower to check. Fewer fields does not make a run cheaper, but it does make the review quick enough that you actually do it.
• Name each field the way you would explain it to a new colleague. Not "ref2" but "the supplier's own invoice number". The description is read as English, so plain English works.
• Add a note wherever a document is genuinely ambiguous. One sentence, such as "the reference at the top right, labelled PO No.", does more for accuracy than any other single thing. Save them for the fields that need it.
• Say when something is money. That is what lets a column total later, and what makes a supplier writing 1.234,56 and one writing 1,234.56 land as the same number.
• Set a check wherever the document states arithmetic about itself. On an invoice that is usually the line items against the total, and the net plus VAT against the gross. It costs nothing and it is the thing that catches a bad read.
• Keep one currency per check. A check is arithmetic, not judgement. Total a column holding both euros and pounds and you will get a confident number that means nothing.

Start from something close and delete, rather than building from a blank page. Most people are done in a couple of minutes, and the second document tells you more about what is missing than any amount of planning did.

The check that catches a bad read

The failure that costs you is never the garbled line, because you can see a garbled line. It is the VAT figure read from the wrong box, or a line item quietly missed on a two-page invoice. Those produce a sheet that looks perfectly reasonable and is wrong.

An invoice, usefully, states enough arithmetic to catch that by itself. The line items have to sum to the total. The net plus the VAT has to equal the gross. If a line went missing, those stop agreeing, so we check them before you see the result and tell you which two figures disagree.

A missed line on page two is invisible to careful reading and obvious to arithmetic.

Receipts rarely carry that kind of arithmetic on their own, but a claim does. If you are totalling a set of receipts against what somebody claimed, the sum of the rows against the claimed figure is the same test, one level up.

Where this stops

Worth being straight about the boundary. What you get is a spreadsheet you check and import. There is no connector into your accounting package, no approval routing, and nothing that decides which nominal code a purchase belongs to.

So this removes the keying and most of the checking. It does not remove the bookkeeping, and anything promising otherwise is selling you a problem you will find in month three.

Try it on last month

Do not test this on a tidy sample. Take last month's actual pile, including the two invoices you had to email someone about and the receipt you can barely read. Signing up gives you enough free credit to run a real handful, and how it does on the awkward ones is the only thing that tells you whether it is worth having.

If you want the wider version of this, covering documents beyond invoices, there is a piece on getting structured data out of PDFs. If it is client bank statements you are drowning in rather than purchase invoices, the statement guide covers that end to end.