# Document extraction schema

Define exactly what each field means before extracting it. An output can follow the correct structure while still containing wrong values or claims unsupported by the document.

Revision: 2026-09-24

## When to use it

When extracting information from requests, confirmations, invoices or other documents for transfer into an operating system.

## Expected output

A schema for each document family with field meanings, validation rules, evidence and missing-data behaviour.

## 1. Define document and destination

Separate document families that use the same labels with different meanings. Describe the output needed by the process instead of collecting every available detail.

### Family, formats and variations

List included documents, languages, scans, attachments and versions requiring exclusion or separate handling.

________________

### Destination and use of fields

Explain which system receives the data and which decisions or actions depend on it.

________________

### Document and line identity

Define stable reference, version and how lines, pages and duplicate documents are distinguished.

________________

> Illustrative example, replace with your own: Illustrative example: extract a supplier order confirmation to compare with the original purchase order. Do not treat a quotation as confirmation merely because it contains codes and prices.

## 2. Specify the fields

Complete one entry per field. Distinguish information present in the document from values calculated using an explicit, verifiable rule.

### Name, meaning and requirement

Describe field, type and when it is required; clarify ambiguous labels such as date or total.

________________

### Format, units and normalisation

Specify date format, currency, separators, units and allowed transformations while preserving the original value.

________________

### Evidence and missing value

Require a page or text reference; define the result when a field is absent or ambiguous.

________________

> Illustrative example, replace with your own: Illustrative example: “delivery_date” means a date explicitly assigned to delivery, not document issue. If the document says “to be agreed”, leave it empty and record why.

## 3. Check before use

Combine deterministic checks with review of ambiguities. Do not silently correct amounts or identifiers just to pass validation.

### Field and cross-field checks

List formats, total consistency, master-data matches and rules with explicit tolerances.

________________

### Review conditions

Define critical fields, conflicts and unreadable documents that must stop a write.

________________

### Test cases and correct references

Prepare ordinary, missing and conflicting examples with results verified by someone familiar with the documents.

________________

> Illustrative example, replace with your own: Illustrative example: quantity multiplied by unit price differs from the line total. Preserve both values and request review instead of inventing a discount to explain the difference.

## Pitfalls to avoid

- Using a field name without defining its operational meaning.

- Filling missing information with plausible guesses.

- Treating valid JSON as proof that the extracted data is correct.

Stolen Orbit — https://stolenorbit.com/en/templates/document-extraction-schema/