Reading Documents with Content Understanding: Extraction You Can Audit

The two halves of document analysis

Document work in Content Understanding splits cleanly in two, and keeping the halves apart makes everything else easier to reason about.

Content extraction answers "what is on this page?" It is generic. It runs the same way whether the file is an invoice, a lease or a lab report, and it produces a faithful machine-readable rendering of the document.

Field extraction answers "what do I want out of this document?" It is specific to you, driven by a schema you define, and it depends on the extraction layer beneath it.

Learners often collapse the two and then cannot explain why a table appears in the output when they never asked for one. Content extraction gave it to them.

What content extraction picks up

The extraction layer is deliberately thorough, because anything it misses is invisible to every stage above it. It handles multilingual machine-printed and handwritten text across hundreds of languages. Beyond plain text it identifies selection marks such as checkboxes and buttons, decodes over a dozen types of linear and two-dimensional barcodes, and captures mathematical expressions in LaTeX format so equations survive as equations rather than as garbled characters.

It also finds the non-text furniture of a document: images, figures, diagrams and charts along with their captions, embedded hyperlinks, and annotation elements such as strikethrough, underline and highlight. Signature detection returns a signature's location together with any text recognised inside the signature region. Document metadata — author, creation date, title — is pulled from file types that carry it.

Structure, not just a wall of text

Structure analysis is what separates this from ordinary OCR. Paragraphs are detected and categorised by the role they play in the document. Tables are recognised including awkward real-world cases: cells that span rows or columns, and tables that continue across pages. Hierarchical sections map how the content is organised, through section headers and nested relationships.

That structural fidelity is exactly why the same extraction layer underpins retrieval-augmented generation. A chunk of text that has lost its heading, its table boundaries and its figure captions retrieves badly. One that keeps them retrieves well.

Designing a field schema

Field extraction lets you extract, classify and generate structured data from documents and forms according to your own requirements. In practice that means naming the things you care about and choosing a method for each: customer details, billing addresses and itemised charges from an invoice; contractual parties, renewal dates and payment terms from an agreement.

The same three methods apply as elsewhere. Extract captures data that is present on the page. Classify sorts content into predefined categories — the sentiment of a transcript, the type of an item on a hotel receipt. Generate produces something new from the document, such as a summary or a chapter overview, to make long content easier to navigate.

You have two routes to a working analyzer. Start from a prebuilt template — the invoice template, for instance — when your documents resemble a common form. Build a custom analyzer from scratch when they do not, and sharpen its accuracy by labelling more sample documents.

Confidence, grounding and normalisation

These three features determine whether extraction output is trustworthy enough to automate against, and each behaves differently.

Confidence and grounding travel together and, importantly, they are opt-in. You turn them on by setting estimateFieldSourceAndConfidence = true in the analyzer configuration, or estimateSourceAndConfidence = true for a single field. Once on, they work for every document field type regardless of whether that field uses the extract, classify or generate method. Confidence tells you how much to trust a value; grounding tells you where the value came from, which is what makes human-in-the-loop review fast and what gives you an audit trail.

Normalisation behaves oppositely. Typed values such as dates and numbers are normalised to a canonical format automatically, and that behaviour cannot be configured. The value you receive is the normalised value. If your downstream system expects the raw string exactly as printed, that is a design constraint to plan around, not a setting to change.

When the answer is not on the page

Some questions cannot be answered by locating a field, because the answer has to be assembled from evidence scattered through the document — a total that must be computed, a condition that must be checked against several clauses, a conclusion that depends on reading a table and a figure together. Agentic mode exists for these cases. It reasons over a document to support multistep calculations, validation against sets of conditions, and analysis of complex tables or figures. It is a preview capability available with API version 2026-06-01-preview, and the initial preview accepts one input file per analysis request.

What to watch out for

Three traps recur. First, assuming confidence and grounding are on by default; they are not, and an automation design that depends on them silently degrades if the flag is missing. Second, expecting to control normalisation. Third, reaching for agentic mode when a plain field would do — it is for evidence-assembled answers, not ordinary extraction.

Carry the business shape too: contract lifecycle management, loan and mortgage applications, financial reporting, expense management from receipts and invoices, and insurance policy analysis. In each, extracted data feeds a decision — which is why grounded, confidence-scored output matters more than raw accuracy alone.