OCR vs document extraction — why characters aren't data

If you’ve ever scanned a stack of invoices, run them through an OCR tool, and then found yourself still copying numbers into a spreadsheet by hand, you’ve already felt the gap this post is about. OCR did its job — it turned the picture of a page into text. But text isn’t data. Knowing that the characters 1,250.00 appear somewhere on the page doesn’t tell you that’s the total amount due and not the subtotal, the tax, or last month’s balance.

That last mile — from “here are the words on the page” to “here is the total, the vendor, and every line item, labeled and ready to use” — is document extraction. This post explains the difference in plain terms, shows where each one fits, and helps you tell which your workflow actually needs.

What OCR actually does

OCR — optical character recognition — has one job: look at an image of text and output the text. Feed it a scanned receipt and it gives you back a transcript — the merchant name, the line items, the total, the date — as a flat run of characters, roughly in reading order.

That’s genuinely useful for some things:

• Making a scanned PDF searchable. OCR is what lets you Ctrl-F a document you photographed.
• Accessibility. Screen readers need the text layer OCR produces.
• Full-text archives. If all you need is to find a document later by its contents, OCR is enough.

What OCR does not do is understand the document. It doesn’t know which number is the total and which is the tax. It doesn’t know that the three lines in the middle are line items and the line at the bottom is a sum. It doesn’t know that “Acme Corp” is the vendor and “Jane Smith” is the contact. It just gives you the characters and leaves the meaning to you.

What document extraction adds

Document extraction starts where OCR ends. It takes the content of the page and returns named, typed fields — a structured object you can drop straight into a spreadsheet, a database, or another system:

{
  "invoice_number": "INV-2026-0412",
  "issue_date": "2026-05-30",
  "vendor": "Acme Corp",
  "total_due": 1250.00,
  "currency": "USD",
  "line_items": [
    { "description": "Design work", "quantity": 10, "unit_price": 100.00 },
    { "description": "Hosting", "quantity": 1, "unit_price": 250.00 }
  ]
}

Three things changed between the OCR transcript and this:

1. The values are labeled. total_due is the total, not just a number that happens to be on the page. You don’t have to figure out which is which — the extraction did.
2. The structure is preserved. Line items come back as a list of rows, not a flattened blob. The thing there’s one of (invoice number) is separate from the things there are many of (line items).
3. Types are normalized. 1250.00 is a number, not the string "$1,250.00". 2026-05-30 is a sortable date, whatever format the document printed. You can do math and filtering without cleaning anything up first.

That’s the whole difference in one word: OCR gives you characters, extraction gives you data.

The comparison, side by side

	OCR	Document extraction
Output	A run of text	Named, typed fields (JSON / CSV / Excel)
Understands the document?	No — just transcribes	Yes — knows total vs subtotal vs tax
Structure	Flat text, reading order	Preserves lists, tables, nesting
Types	Everything is a string	Numbers, dates, booleans normalized
New layout	Works (it just reads)	Works without a per-vendor template
Good for	Search, archive, accessibility	Feeding data into tools and workflows
Still need to retype?	Usually yes	No

The row that matters most for most teams is the last one. If your goal is to do something with the numbers — reconcile them, total them, push them into your accounting system — OCR leaves you with the retype step still in front of you. Extraction removes it.

”But I already have OCR — isn’t that enough?”

This is the most common question, and the honest answer is: it depends entirely on what you do next.

If you only ever need to find and read documents, OCR is enough — don’t add complexity you won’t use. But if a human is reading the OCR output and typing the values somewhere else, that typing step is exactly what extraction is for. The tell is simple: are you copying numbers off a screen into another screen? If yes, you’re doing by hand what extraction does automatically.

A related trap is building extraction yourself on top of OCR with regular expressions — “find the line that starts with TOTAL, grab the number after it.” It works on the first vendor and breaks on the second, because the next invoice says “Amount Due” instead, or puts the total in a different place, or runs the table across two pages. Every new layout is a new rule. That treadmill is the reason template-based and regex-based approaches don’t scale past a handful of document formats.

Where modern document extraction is different

The older generation of extraction tools needed a template per layout — you’d draw boxes on a sample document saying “the invoice number is always here, the total is always there.” That works only when every document looks the same, which is almost never true once you have more than one vendor, bank, or counterparty.

Layout-aware extraction reads the document the way a person does — by understanding what the fields mean, not where they sit on the page. A new invoice layout works on the first try, with no template to set up. A bank statement whose table spills across twelve pages comes back as one clean list. A customs document that mixes two languages keeps each value in its original script. The same approach covers receipts, contracts, IDs, resumes, and lab reports — different documents, same idea: you describe what you want, the engine finds it.

If you want the practical version of “describe what you want,” we wrote a whole post on it: how to write a good extraction schema.

What about verifying the result?

There’s one fair worry about going from raw OCR to structured fields: when a tool interprets the document instead of just transcribing it, how do you check it got the interpretation right?

The answer is provenance. Every value Ztract extracts is anchored to its exact position on the source page. Click total_due in the output and the matching spot lights up on the original document — so verifying a number is a glance, not a hunt. You scan the fields that look off, fix any in one click (corrections are free — only extraction counts against your pages), and you’re done. You get the speed of automation without losing the auditability of reading the source yourself.

So which do you need?

A quick decision guide:

• You need to search or archive scanned documents → OCR is enough.
• You need the document to be screen-reader accessible → OCR is enough.
• A person is reading documents and typing the values into a spreadsheet, ERP, or database → you need document extraction.
• You tried OCR-plus-regex and it breaks every time a layout changes → you need layout-aware extraction, not more rules.
• You need every extracted value to be auditable back to the source → you need extraction with provenance, like the side-by-side viewer.

Most teams that land on Ztract started with OCR, hit the retype wall, and realized the missing piece wasn’t better character recognition — it was turning those characters into labeled data.

Try the difference on your own document

The fastest way to feel the gap is to run a document you actually work with through extraction and look at the structured output — labeled fields, real numbers, line items as rows — instead of a wall of text. New accounts get 30 free pages, no credit card, which is plenty to test a few of your messiest layouts.

And if you’ve got a workflow where you’re not sure whether OCR or extraction is the right tool, tell us about it — we’d rather help you pick the right approach than sell you the wrong one.