Turning documents into structured records requires more than asking a language model to return JSON. A response can parse correctly while inventing a missing identifier, assigning the wrong currency, or silently conflating two names. Reliable extraction needs a schema, a verified evidence source, business-rule validation, and explicit outcomes for incomplete or contradictory data. At scale, it also needs a batch workflow that preserves the identity of every request and makes partial failures visible.

Begin with a single invoice, but design the extraction contract to survive asynchronous processing and independent review. Every accepted record needs the same required fields, source identity, handling of missing values and business approval rules whether it came from an interactive request or a large batch. Otherwise the batch pipeline can produce syntactically consistent output while losing the evidence needed to trust or correct it.

Begin with the downstream data contract

Imagine a finance system requiring invoice_number, supplier_name, currency, total_amount, issue_date and purchase_order_number. Which fields are mandatory? Can a purchase-order number be absent? Is a date allowed to be approximate? What must happen if two totals appear? The answers belong in an explicit schema and business-validation rules, not in the model’s guess about what a typical invoice probably contains.

An extraction schema can require known fields while allowing appropriate nullable values. Do not force a fabricated value merely because a database column was initially designed as non-nullable. If the source does not contain a PO number, return a documented missing value and route that fact to the correct validation or review process. When the input truly violates a downstream requirement, a rejected record is better than a believable invention.

Use current schema-constrained output capabilities

Current Claude structured-output documentation describes JSON output configured with output_config.format and strict tool use configured separately. JSON outputs constrain the structure of the model’s response; strict tool use validates tool names and input shapes. These mechanisms can be combined when appropriate, but they are not the same feature. Older examples may use a beta output_format parameter, so consult the current SDK and model-compatibility guidance before copying production code.

Schema-constrained decoding reduces formatting failures such as missing required JSON fields or invalid syntax. It cannot guarantee that a string extracted from an invoice actually appears on the page. The application still needs to compare values against source evidence, validate permissible currencies, check arithmetic, and reconcile duplicates. Strong typing is a useful guardrail, not a license to skip factual checks.

Write prompts with explicit evidence criteria

An extractor prompt should say which document is being processed, which fields may be returned, and how to handle missing or ambiguous information. Include instructions not to infer an invoice number from a filename or invent a purchase-order reference. A small number of examples can clarify unusual cases: one invoice with a standard table, one credit note with a negative amount, and one document missing an optional field.

Examples should teach distinctions rather than overwhelm the input. If the prompt includes many nearly identical invoices, the model may learn irrelevant surface patterns. State the criterion that determines the answer, such as “use the currency explicitly shown next to the invoice total; otherwise mark the currency unresolved.” Then verify that the model applies it to genuinely different formats.

A few-shot prompt works best when its examples teach different decisions rather than repeat the same format. Example A can map a standard invoice with an explicit purchase-order number to a complete typed record. Example B can show a credit note whose negative total must remain negative. Example C can show a missing purchase-order number returned as null rather than guessed. Keep the expected field names and evidence rules consistent across all three examples, then test on unseen document layouts. Few-shot examples improve interpretation, but the output schema and business validator must still reject unsupported values.

A worked missing-field case

Suppose an invoice has a clear supplier, invoice number, date and total of 820.00, but the PO field is blank. The extraction output can contain the known fields and a null purchase_order_number with an accompanying evidence status. The validator should not reject this as malformed JSON if the schema permits null; it may classify the record as REQUIRES_REVIEW if the downstream accounting workflow requires that field before payment.

If the document shows a subtotal, tax and total, independently recompute the arithmetic within the appropriate rounding tolerance. If the printed figures disagree, preserve the document values and flag the contradiction. Do not “correct” the invoice silently to a number that makes the math work. The evidence must remain available for a human or authorized business rule to decide what happens next.

Separate four kinds of error

A format error occurs when a response does not meet the required structure. A factual extraction error occurs when a well-formed field is wrong. A business-rule error occurs when extracted facts violate an application constraint. A source-quality failure occurs when the document does not contain enough information to answer. These cases need different handling: schema repair, evidence re-check, controlled rejection, or human clarification.

A retry is justified only if it can plausibly fix the failure. Re-requesting the same unreadable scan without better input often wastes cost and produces a different guess. A validation-feedback loop can tell the model which specific field failed and provide the original evidence, but it should bound retries and never loosen an authorization requirement merely to obtain a passing record.

Durable provenance for each field

Store a source document ID and version alongside the extraction. For high-value fields, record a page or location reference and a verification status. This allows auditors to distinguish “the model returned 820” from “the document on page 2 states 820.” When text is corrected or a source is replaced, dependent records can be revalidated rather than silently assuming they still match.

If multiple workers handle one document, do not let a synthesizer discard the original source IDs. A final record can be concise while retaining a trace to the raw document and processing history. This also helps when a user disputes an extracted value: a reviewer can inspect the relevant evidence instead of rerunning the entire model interaction blindly.

Scale through the Message Batches API deliberately

The Anthropic Message Batches API supports processing many independent requests asynchronously. Its documented advantages include throughput and lower cost relative to immediate requests. A batch is not a magic multi-turn agent runner; design each item as an independent request with everything it needs to produce a verifiable result. Store a unique custom_id for each item so the result can be matched to the correct document when responses arrive.

Build a durable manifest containing batch ID, source version, item custom_id, expected schema, submission status, result status and acceptance decision. Batch completion does not prove every item succeeded; inspect per-request outcomes and reconcile missing, errored or expired items. Never infer an invoice’s output from its position in an unordered result stream.

Retry failures without duplicating accepted records

Suppose 400 invoices enter a batch. Three requests fail and seven have unresolved fields. Preserve the 390 accepted items and their evidence. Retry only the three failed requests within a defined budget, and send the seven ambiguous records through appropriate review. Reprocessing all 400 without deduplication could create duplicate downstream entries or alter records already approved by people.

Use custom IDs tied to immutable source versions. An invoice uploaded again after correction is a new source version, not necessarily a new transaction. The downstream writer should upsert or reconcile under approved business rules, rather than trusting the model to decide whether two similar invoices represent the same payable item.

Independent review and multi-pass evaluation

A second pass can independently inspect the original document, the extracted fields, and a rubric of important error types. It should not merely read the first pass’s explanation and agree. Give the verifier actual source evidence and ask which specific field or claim is unsupported. If the checker finds a mismatch, return it to the correction workflow; if no reliable resolution exists, preserve an unresolved status.

Risk-based review is usually better than reviewing every low-risk field with the same intensity. A missing PO number, unusually large amount, new supplier or conflicting currency may require a human. Routine well-supported records may pass automated constraints. Calibrate review triggers from observed error rates and operational consequences, not from a model’s decorative confidence percentage.

Measure more than valid JSON

Track schema acceptance, field-level factual accuracy, unsupported values, correction rate, reviewer workload, batch failures, duplication incidents and cost per accepted record. A system that always produces valid JSON can still fail badly on important business fields. Conversely, a cautious extractor that honestly returns null for unknown values may be more useful than a seemingly complete response with hidden guesses.

Create test fixtures covering scanned invoices, missing dates, conflicting amounts, different decimal separators, negative credit notes and duplicate uploads. Use real authorization controls when moving accepted records into financial systems. An AI extraction model should not receive unrestricted permission to approve invoices or issue payments because its output passed schema validation.

Test the extractor with two records that satisfy the same JSON schema but differ in truth. One contains a confirmed invoice number and an unreadable tax field represented as null; the other invents a plausible tax value. A parser accepts both, but an evidence-aware review must reject the invented value. Next add a duplicate upload and require the writer to preserve an accepted record rather than overwrite it without authorization. Candidates using independent third-party CCA-F practice questions can test these same distinctions: syntactic validity does not prove grounding, idempotency or approval. The answer should identify what the model can format, what validators can verify, and which consequential action belongs to a reviewer or trusted service.

What this means for Architect Foundations

As a validation exercise, compare a single-pass JSON extractor with a pipeline that retains source offsets, uses explicit nulls for absent fields and routes ambiguous values to review. Give both systems a credit note, an invoice with an unreadable tax field and a batch containing one malformed record. A successful run must not invent missing evidence or cause one disputed document to overwrite accepted records from other inputs.

Consult Claude structured-output documentation and batch-processing documentation for the features and limits supported by the selected model and API version. Syntax-constrained output is only one validation layer: currency rules, document identity, arithmetic and authorization still require application-level checks. When a batch is retried, preserve a durable item identifier so accepted results cannot be silently duplicated.

Design a review queue people can actually operate

A model may flag dozens of incomplete records, but someone must decide what to do next. Group unresolved extractions by failure reason: missing source evidence, inconsistent arithmetic, unsupported currency, inaccessible document or an approval required by business policy. Present the source identifier and exact disputed field so a reviewer does not have to open the entire batch to understand the problem. Keep accepted records separate from unresolved ones; a single ambiguous invoice should not cause a correct hundred-record batch to be discarded.

When a reviewer corrects a record, preserve the original extraction, the source version, the reason for correction and the identity of the authorized reviewer. This makes error analysis possible and prevents a later automated rerun from silently replacing an approved human correction with a plausible but unsupported value. The audit trail is an engineering requirement, not an optional reporting flourish.