Read a photo or PDF into a spreadsheet with n8n

Five years ago this did not work. A photo of a crumpled receipt taken in a van in bad light was not something you could turn into a number without a person squinting at it.

It works now. That is the single biggest change in this whole category and it is why every other document build on this site sits on top of this one.

First, check whether you need it at all

Most invoices arriving by email are PDFs generated by software, and those have a text layer already. n8n’s Extract from File node pulls it out for nothing: no model, no API key, no per-page cost, and no chance of a hallucinated number.

So the first thing this workflow does is try the cheap way and only fall back to the model when the cheap way returns nothing.

That test is simple. Run Extract from File, then check the length of what came back. Under about fifty characters means there was no text layer and it is a picture of paper. Over that, you are done and you never touch the model.

On a normal month that routes maybe four fifths of documents down the free path. It is the single most useful thing in this guide and almost nobody does it.

The build, six nodes

1. Google Drive Trigger. Watch a folder. Poll every five minutes, event on file created.

An email address works equally well if that suits how people actually work. A tradesperson photographing a receipt is far more likely to send it to an address they already have in their phone than to open a Drive app on a site.

2. Extract from File. Operation: Extract from PDF, or Extract from File for other types. Set it to continue on fail, because an image file will throw here and that is the expected path rather than an error.

3. IF node, called Has Text. Route on whether the extracted text is longer than fifty characters. True goes straight to the extraction step. False goes to the model.

4. Analyze Image. On the OpenAI node this is the Analyze Image operation; on others it is an HTTP Request with the image as base64. Any of the current models does this competently, and the difference between them matters far less than the prompt does.

Ask for the fields, not for a description. This is the whole difference between a useful node and a paragraph of prose you then have to parse:

Read this receipt or invoice. Return only these fields.
supplier   the trading name at the top
date       YYYY-MM-DD
total      the gross amount paid, digits only
vat        the VAT amount if shown, otherwise null
currency   GBP unless another is printed
confident  true only if you can read every field clearly

That confident field is the most valuable thing in the prompt. A model asked for a total will always produce a total. A model asked whether it could read the total will sometimes admit it could not, and those are precisely the ones you want a person to see.

5. Information Extractor. For the text-layer branch, doing the same job on text instead of an image. Same field list, so both branches write the same shape and everything downstream stays simple.

6. Google Sheets, Append. Both branches join here. Write supplier, date, total, VAT, currency, the file link, and a source column saying text or image so you can tell later which route a row came down.

The checks that make it safe

A misread number is worse than no number, because it looks like a fact. Four cheap guards catch nearly everything.

Route the unconfident ones. Anything where confident came back false goes to a separate sheet tab or a folder called needs-a-look. Nothing else changes, and now the model’s uncertainty is visible instead of averaged away.

Sanity-check the total. A Code node that flags anything above a threshold you set, or below zero, or with more than two decimal places. Most misreads are wild rather than subtle: a decimal point in the wrong place turns £8.42 into £842, and a range check catches it instantly.

Check the date is plausible. Not in the future, not more than a year old. A date read as 2016-08-14 instead of 2026-08-14 is a common slip and an obvious one once you look for it.

Keep the original. Always. The row is a convenience; the document is the record, and HMRC’s interest is in the document.

What still defeats it

Handwriting. A model will read handwritten figures and get them wrong, and it will not tell you it is unsure unless you ask it to.

Thermal receipts that have faded, which is most of them after a summer in a van. The top half reads perfectly and the total has vanished, which is the worst combination because it produces a plausible row with a missing number.

Documents that are two things at once. A supplier statement listing eleven invoices is not one receipt, and asking for a single total gets you either the first line or the sum of all of them, with no way to tell which from the output.

None of these are reasons not to build it. They are reasons the needs-a-look pile has to exist and has to be looked at.

Where the real time goes

Not the reading. The reading is the part that got solved.

The time goes into the fields being consistent enough to sum. A supplier called SCREWFIX, Screwfix Direct Ltd and screwfix is three suppliers in a pivot table. A short mapping list in the Code node, ten or fifteen entries covering the suppliers you actually use, fixes it permanently and takes about a quarter of an hour.

Do that once and the sheet becomes something you can total. Skip it and you have a very fast way of producing data nobody can add up.