What is document data extraction?

What does document data extraction produce?

Document data extraction takes a file meant for people to read and returns data meant for software to use. The input might be a digital PDF, a scanned page, a phone photo or an email attachment. The output is a set of named fields in a fixed shape, usually JSON, that can go straight into an accounting system, a loan file or a database. Three things separate useful output from a text dump. Every field has a stable name, whatever the document called it, so “Inv. No.” and “Bill number” both arrive as invoice_number. Values are normalised, so dates and amounts share one format. And each value carries evidence: a confidence score and, ideally, the page it came from. Repeating data such as invoice line items or bank statement transactions comes back as rows, not loose text.

{
  "invoice_number": { "value": "INV-20418", "confidence": 0.98, "page": 1 },
  "due_date": { "value": "2026-12-01", "confidence": 0.93, "page": 1 },
  "purchase_order": { "value": null, "confidence": 0.90, "page": null },
  "total": { "value": 1284.50, "currency": "EUR", "confidence": 0.97, "page": 2 }
}

What is the difference between OCR and data extraction?

OCR, optical character recognition, converts an image of text into machine-readable characters. It answers “what does this page say?” and stops there. Extraction answers “which of these characters is the due date?”, which takes an understanding of labels, position and document type. A good OCR result on an invoice is still a long run of words and coordinates; something else has to decide that one number is the total and another is a tax registration. OCR quality still limits everything built on it. Tesseract’s documentation says it works best at 300 DPI or more and suffers on skewed or noisy pages, and Amazon’s guidance for Textract asks for at least 150 DPI. Digital PDFs often avoid the problem: Microsoft recommends text-embedded PDFs because they remove the chance of character errors, while scanned PDFs are handled as images.

How do OCR, templates, APIs, IDP and LLM parsing compare?

What does IDP add to extraction?

Intelligent document processing, or IDP, is a product category rather than a single technique. An IDP platform wraps extraction in the surrounding workflow: taking in files from email or folders, splitting bundles into separate documents, working out what each one is, extracting fields, checking them against rules, sending doubtful values to a person and exporting the result. The engine inside might be OCR with trained models, an LLM, or both. Because IDP is a market label and not a standard, two IDP products can differ widely, so ask what each one includes. The appeal is a working process, with review screens and history, that nobody has to build. The usual cost is more setup and more platform than a small integration needs. If you only want fields returned to your own application, an API may be enough. If people will work a queue every day, the review tooling matters as much as the extraction.

What is a document extraction API?

A document extraction API takes a file over HTTP and returns structured JSON, leaving the surrounding process to you. Cloud providers offer prebuilt models for common documents: Amazon Textract’s expense analysis returns standard fields such as vendor name, total and line items with a confidence for each, and Google’s Invoice Parser and Azure’s invoice model do similar work. For your own document types, custom models learn from labelled samples. The model type matters: Microsoft says its template models rely on a consistent visual template and need a model per variation, while its neural models use one model across variations. Newer API vendors, compared here, pair parsing with schema-driven extraction. The trade-off is ownership: retries, monitoring and handling low-confidence values become your job unless the vendor supplies them.

How reliable is LLM document parsing?

LLM parsing sends a document, or its text, to a large language model with instructions or a schema, and asks for the fields back as JSON. Its strength is flexibility. There is no template to build, a new field can be a one-line change, and unfamiliar layouts need no setup. Its weakness is that a language model produces likely text, and likely is not the same as present. Research on degraded identity cards and invoices found that multimodal models often fail to recognise that an image is unreadable and lean on language patterns, inventing content. A separate study found that LLMs asked to state their confidence tend to be overconfident, so a self-reported score is weak evidence. Valid JSON proves the shape of an answer, not its truth. LLM parsing can work in production, but the controls have to sit outside the model: arithmetic and format checks, links back to the source page, and human review for values that matter.

How do you choose a document extraction approach?

Work backwards from the cost of a wrong value, not forwards from the technology. Six questions settle most decisions:

1. Do you need text or fields? If search is the goal, OCR is enough.
2. How many senders do you have, and do they repeat? A few stable forms suit templates or custom models. A long tail of senders needs something that copes with layouts it has not seen.
3. What happens when a value is wrong? A misfiled note is cheap. A wrong payment amount is not, so look for per-field scores and review.
4. Who fixes errors? Name the person, and check they get the source page next to the value.
5. Will you build the workflow or buy it? This is usually the real choice between an API and an IDP platform.
6. Can the data arrive as data? Structured e-invoices need no extraction at all.

How should you test a document extraction tool?

Test on your own documents, and split them by sender. A random sample flatters any tool, because documents from the same sender land on both sides of the split. The CloudScan invoice study shows the gap: its model averaged 0.891 F1 on a random split of invoices and 0.840 when the split was made by sender. The DocILE benchmark builds in the same idea, with zero-shot and few-shot layouts in its test set. Score each field separately, because a strong average can hide a weak total or tax field. Count wrong values apart from missing ones. Include your worst scans and documents that lack an optional field, to see whether the tool says so or fills the gap. Then find out what happens when a sender changes their form, because a good first month says little about the following year.

Where does docRefinery fit?

docRefinery is a document data extraction API and review dashboard for back-office teams: documents go in and checked data comes out. Each sender’s layout is learned once and remembered, absent fields come back null, and by default every value carries a confidence score checked against thresholds you set per field, with page and box citations on extracted values. You name each output with a Return as alias, every document type returns the same format, and long files are segmented into the documents inside them. It runs in our cloud, a private VPC or air-gapped on your own servers. That suits work where the same senders return month after month, such as invoices, purchase orders and utility bills. It helps less where every document is a one-off, and if you only need searchable text, an OCR engine is simpler. The Starter plan is free up to 100 pages a month; paid plans are custom, quoted by sales. See how it compares with tools such as AWS Textract and Azure Document Intelligence.