OCR vs LLM extraction: which one you need

OCR reads characters off a page. An LLM reads a document and decides what things mean. They are not competing products, they are two stages of the same pipeline, 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. That is reasoning about the content, and no OCR model is built to do it.

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, 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 never sees the page. 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. Position on the page. A text stream carries none of that, so a question that depends on it cannot be answered no matter how good the second model is.

The alternative is to put the page image and the schema in front of the model together, so the layout, the marks and the fields are available at the moment the decision is made. That is how Veralens works. Whether it produces measurably better fields than a well built two step pipeline is something we are benchmarking, and we are not going to claim it here until we can show 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.