OCR vs LLM extraction: which one you need

OCR gives you the characters on a page. Extraction gives you the fields you asked for, typed and ready for a database. They answer different questions, and knowing which one your problem needs saves both money and a rewrite.

The difference in one example

Take a receipt line reading TENDERED NEDBANK 42.50.

OCR returns TENDERED NEDBANK 42.50. Correctly, completely, for a fraction of a cent. It has done its job.

Extraction has to answer a different question: what is payment_method? Nothing on that page says "card". Getting to card requires knowing that Nedbank is a bank, that a bank name on a tender line means an electronic payment, and that this is therefore not cash. Transcription will never give you that, however good it gets.

Now the harder half. Take a receipt with no payment line at all. The right answer is null, and a system that returns cash because receipts are often cash has produced a value you cannot distinguish from a real one. Knowing when to abstain is the hardest part of extraction, and it is the part that decides whether you can trust the output without a human reading every document.

When plain OCR is the right answer

Use OCR, and stop there, when:

• You need the text, not fields. Search indexes, archives, RAG pipelines.
• Your documents share one fixed layout that you control, so position tells you what a value is.
• Volume is high and the per page price dominates your thinking.

Dedicated OCR models are genuinely cheap, roughly $2 to $4 per 1,000 pages, and on public parsing benchmarks they lead. If this is your job, buy the cheapest credible one. We sell extraction and we would still tell you that.

When you need extraction

Use an extraction step when:

• You need typed fields going into a database, not text going into a search box.
• Layouts vary, because every supplier formats an invoice differently.
• Values need interpretation: which total is the total, is this date the issue or the due date, what currency is this.
• Absence matters. You need to know that a field is not present rather than receive a guess.

The two step trap

The obvious build is to run OCR yourself, then pass the text to an LLM with your schema. It works, it is cheap, and it has two structural weaknesses worth knowing before you commit to it.

Whatever the OCR misses, the second step cannot recover. It only ever sees a text stream. A misread digit becomes a confidently wrong number with no signal that anything happened, because by then the evidence is gone.

Anything that is not text disappears. Which checkbox is ticked. Whether a stamp says PAID. That two numbers are in the same table row. Handwriting in a margin. A text stream carries none of that, so a question that depends on it has no answer left to find.

Those are the questions Veralens is built to answer. A ticked box, a PAID stamp, a handwritten amount and which row a figure belongs to are all fields you can put in a schema and get back. Whether that beats a well built two step pipeline on your documents is your afternoon to spend, and the last section of this buyer's guide is how we would spend it.

What a general LLM will not tell you

You can send an image to a general purpose model with "return JSON" and get something usable. For occasional use that is fine. In a pipeline, three things bite:

• The shape drifts. Field names and formats vary run to run unless the output is constrained by a schema.
• It fills gaps. Asked for a field that is not on the page, the default behaviour is to produce something plausible, and nothing in the response marks it as invented.
• It is one call, not a job. No retries, no cost per document, no queue, no webhook. You build that.

Choosing

Either way, the checks at the end are the same: normalize dates and numbers, verify the document against itself, and route what fails to a human. The full pipeline is in how to parse unstructured data properly, and if you want to try the extraction half, the quickstart is a few minutes.