Schema-Based Document Extraction: Custom Schemas Without Templates

The short answer

Schema-based extraction lets you define the fields your application needs without drawing a fixed template for each layout. Reducto Extract uses a JSON schema to describe the output and supports document-level instructions through a system prompt. Prebuilt models are another option when their standard fields meet your needs: Azure’s invoice model extracts invoice fields across varied formats. Google Document AI’s generative custom extractor also supports schema-based, zero-shot extraction without training examples. Choose based on field coverage and tested accuracy across your documents, not layout variety alone.

Templates, prebuilt models, and template-free schemas

A template describes how to find values in a layout; a schema describes the fields and structure you want back. Prebuilt models provide a vendor-defined starting point. These approaches can overlap.

Reducto’s documented Extract workflow starts with a schema and an API call, without a separate labeling or training stage. Reuse the schema across senders when the fields mean the same thing, then test new layouts before relying on the output. For a wider API-level comparison, see Best PDF Data Extraction APIs and SDKs.

Schema design patterns that hold up

Flat fields, nested objects, and repeating arrays

Use flat properties for header values that appear once: document number, dates, totals. Group related values that belong to one entity (vendor, borrower, patient) into a nested object so field names stay short and unambiguous. Use an array of objects for anything that repeats an unknown number of times, such as line items, transactions or plot records. Numbered fields (charge 1, charge 2, and so on) break as soon as a document has one more row than you planned for, while an array leaves the row count open. Very long tables still need care, because Reducto's documentation warns that documents with hundreds of rows spanning many pages can be truncated or skipped by standard extraction.

Types, enums, and values that are not on the page

Give numeric fields a number or integer type when you plan to compute with them, and keep formatting-sensitive strings (payment terms, reference codes) as text. Where a field has only a handful of valid answers, an enum constrains the output instead of leaving room for free text variants. Avoid asking the schema for derived values: extraction returns what appears in the document, and the documentation notes that requesting calculated fields can lead the model to fabricate values. Extract the raw inputs and do the arithmetic in your own code, where it is testable.

Getting reliable nested output

Nested and repeating structures fail in predictable ways. A short checklist covers most of them.

• Write a description for every field, including where it usually appears. The model uses field names and descriptions to locate values, so they act as instructions.
• Check the parse output first when a field comes back empty. Extract runs Parse internally, so confirm that the source value was recovered before changing field descriptions. If it was missed, review the parsing configuration.
• Keep schemas bounded. Reducto recommends staying under 50 fields as a rule of thumb, not a hard limit. Remove unnecessary fields, simplify deep nesting, or split larger extractions into logical groups.
• For long repeating arrays, use Deep Extract, an agentic mode that iteratively refines its output for complex documents. The older array extraction setting is deprecated in favour of Deep Extract, which the documentation notes carries higher cost and latency.
• Validate the extracted values against your schema, accounting for the response structure when citations are enabled. Add cross-field checks, such as matching identifiers or reconciling rows to a subtotal, before downstream use.

Traceability and review thresholds

Enable citations when reviewers need to trace a value to its source. Citation-enabled output wraps values with citation metadata. PDF and image citations include source text and page coordinates; Excel and CSV use cell coordinates. Numeric confidence scores are included when enabled, alongside categorical confidence. Citations can be empty for inferred values or when a source location could not be established. Citations cannot be combined with parsing chunking.

Use confidence to prioritize review. A high score does not establish that the value has the correct meaning, period, or units for your application. Review missing required values, failed checks, low-confidence fields, and missing citations where traceability is required. Keep source references with the record. For common configuration mistakes, see JSON schema pitfalls.

Frequently asked questions

Why do results change between identical runs?

Model outputs can vary between runs. Clear field descriptions and enums can reduce ambiguity, but they do not guarantee identical results. If your application caches extraction results, include the document hash and a version of the schema, instructions, and extraction configuration in the cache key. Invalidate cached results when these change so an old extraction is not reused for a new request.

Do I need a separate schema per document type?

Not for every layout or sender. Reuse a schema when the target fields have the same meaning and structure, and test it across representative documents. Create separate schemas when the required fields or their interpretation differ substantially, such as invoices and medical records. For combined records, Reducto can accept several previous Parse job references in one extraction.

Does valid JSON mean the extracted values are correct?

No. Schema validation checks structure and types, not whether a value came from the right row, entity, or reporting period. Pair it with source citations, completeness checks for repeating rows, and business rules. An amount can be a valid number and still refer to the wrong total.