The document your AI cannot actually read

A pattern we meet often: a company wants to process incoming documents automatically, tries it, and gets poor results. The cause is almost never the model. It is that half the documents are pictures.

The distinction that matters

A PDF generated by software — an invoice from an accounting system, an export from a word processor — contains text. Software can read it directly and accurately.

A PDF produced by a scanner or a phone camera contains an image of text. Software must first recognise the characters, and recognition makes mistakes: a 3 becomes an 8, a column becomes a paragraph, a table loses its shape.

Both look identical on your screen. You can tell them apart in two seconds: try to select a word with your mouse. If you cannot, it is a picture.

Why this decides whether a project works

Recognition on a clean, straight, printed document is very good now. On a crumpled delivery note photographed on a loading bay in poor light, it is not, and no model will fix that because the information is genuinely not legible.

This is why supplier-invoice automation succeeds at companies whose suppliers send proper PDFs and disappoints at companies whose suppliers send photographs.

What to do before you build anything

Take thirty real documents of the type you want to process. Sort them into text and picture. The proportion is your answer, and it takes fifteen minutes.

If most are text, proceed. If most are pictures, the highest-value project is not automation — it is asking your ten largest suppliers to send a machine-readable invoice, which most will do for free and which fixes the problem at its origin.

The wider principle

The 12 September questions ask whether a process is a good candidate. This is the same question at the level of data: the quality of what goes in sets a ceiling no model can raise.

Checking the input first is unglamorous and saves entire projects.