What is Document Data Extraction?

Document data extraction is the identification and capture of specific values from a document, such as fields, tables, dates and named entities, as structured data with a defined schema.

Extraction is the stage that produces the output a business process actually consumes. Everything before it prepares the document; everything after it checks and delivers what extraction found.

What gets extracted

Header fields are the single values that identify and date a document: invoice number, purchase order reference, issue date, currency, total, supplier name and tax identifiers.

Line items and tables are repeating structures, and they are substantially harder than header fields. A line item may wrap across rows, continue across a page break, carry its own tax treatment, or reference a different delivery address from the document header.

Clauses matter in contracts rather than transactional documents: termination rights, notice periods, liability caps, governing law, renewal terms. Clause extraction is usually span identification rather than value capture, returning the passage and its location so a reviewer can read it in context.

Entities are the parties, places, products and identifiers named anywhere in the text, which may not correspond to a labeled field.

Signatures and marks are detected rather than read: whether a signature block is filled, whether a checkbox is ticked, whether an initial appears on each page.

Metadata is derived rather than found: page count, language, capture channel, quality score, and the confidence values attached to everything above.

Template-based versus model-based extraction

Template-based extraction defines where values sit, either by absolute coordinates or relative to an anchor such as a label. Given a stable layout it is highly accurate, fully explainable and cheap. Its failure mode is unforgiving: a supplier moving a field by a centimetre, adding a logo that shifts the header, or issuing a new template silently produces wrong values rather than no values.

The hidden cost is maintenance. A template per supplier per document type becomes hundreds of templates, each needing repair whenever a counterparty changes their paperwork. Organizations frequently underestimate this until the template library is already unmanageable.

Model-based extraction learns what a field looks like from examples, using text, layout and visual features together, so it generalizes to layouts it has not seen. It removes the per-supplier maintenance burden and handles the long tail of low-volume counterparties that never justified a template.

Its trade-offs are real. It needs labeled training data. Its accuracy on any individual document is less predictable than a matched template. And when it is wrong, explaining why to an auditor is harder than pointing at a coordinate rule.

The practical pattern is layered: model-based extraction as the default, with templates retained only where a high-volume counterparty has a genuinely stable layout and the accuracy gain justifies the maintenance.

Human-in-the-loop validation

No extraction system reaches complete accuracy, so the design question is not whether people are involved but where.

The usual arrangement routes documents by confidence. Values above a per-field threshold pass automatically. Values below it queue for review, where a person sees the extracted value next to the region of the document it came from, corrects it if needed, and releases it.

Two properties determine whether this works. Corrections must feed back into training, or the same error recurs indefinitely. And the review interface must be faster than reading the document from scratch, because if it is not, the queue costs more than the manual process it replaced.

Straight-through processing rate, the proportion of documents that complete with no human touch, is the metric that captures whether the balance is right. See document workflow automation.

What commonly goes wrong

Accuracy is averaged across fields. A single figure hides which fields fail. Accuracy has to be reported per field, because the consequence of a wrong payment amount is not the consequence of a wrong description.

Empty is conflated with missing. A field the document genuinely does not contain and a field extraction failed to find are different outcomes requiring different handling. Returning an empty value for both loses that distinction.

Validation is skipped because extraction seems confident. Cross-field checks catch what per-field confidence cannot: totals that do not sum, dates in impossible order, tax that does not match the applicable rate.

Contellect One extracts fields, tables and entities in advanced information extraction.