Mandatory Field Coverage Rules by Document Type

When an invoice moves through an extraction pipeline and lands in AP automation with a tax field left blank, it can trigger a payment error before anyone notices the field was empty. The pipeline didn't crash. It returned a clean, well-formed record with a high confidence score, and that record moved downstream and did damage on the way.

That's the gap that separates a demo from a production system. Demos run on documents picked to work. Production runs on the full spread of real paperwork, where the failures that matter aren't the ones where a model gets a number wrong but the ones where a model leaves a field empty or invents a value, wraps it in valid JSON, and reports a confidence score high enough to pass review.

Part of why this slips through is how accuracy gets reported. Hallucination comes in at least four distinct forms, factual, grounding, citation, and reasoning, and most reporting compresses all four into one headline accuracy number. That number tells an engineering team almost nothing about which field class is breaking or why.

By 2026, strong accuracy on common documents is table stakes. Every credible platform clears that bar. What separates a production-grade system now is what happens after extraction: whether it reasons over the data it just pulled, checks it against business logic, and leaves behind an audit-ready trail. Mandatory field coverage rules sit right at that boundary. They decide whether an extraction attempt becomes an accepted record or gets stopped before it can cause a downstream problem.

Mandatory field coverage rules

A mandatory field coverage rule is a schema, built per document type, that lists the fields a record must have, non-empty and valid, before that record is allowed to move downstream. It sits upstream of accuracy scoring, not alongside it. Accuracy asks whether a value is correct, and coverage asks whether the system attempted to populate the field.

The metric that tracks this is field completeness rate, or FCR: the share of required fields that are non-empty and valid, measured independent of whether the value in each field is actually right. So a pipeline can score high on per-field accuracy and still post a low FCR. Those are two different failure surfaces, and a team that only watches one of them is blind to the other.

The open-source ExtractBench framework builds this distinction directly into its scoring. An omitted key doesn't get skipped, it gets scored as an explicit null. Every scalar field counts in both the numerator and the denominator of the calculation, and a correct null on a field that's genuinely blank in the source document gets credit rather than getting ignored. That design choice matters because it forces a pipeline to account for every mandatory field, not just the ones it managed to populate.

Accuracy tells you one thing and coverage tells you another, so you need both. If an engineering team tracks per-field correctness against ground truth but never checks FCR, it can run for months with a systematic omission nobody catches. Modern agentic extraction systems build the fix into the pipeline itself: an agent identifies the document type, pulls an initial set of fields, validates those fields against business rules, then cross-checks ambiguous values against related documents. Mandatory field schemas are the rule set those validation steps run against. Without a schema, there's nothing for the agent's validation step to check against.

Schema definition does double duty as a data boundary. A field that isn't named in the schema never gets stored. The schema enforces data minimization at the same time it enforces completeness.

Why field schemas must be defined per document type

If you apply a single generic schema across document types, it blocks valid output it shouldn't, or lets incomplete output through that it should catch. Both failures defeat the purpose of having a schema. Different document types carry structurally different obligations, and the only way to enforce coverage correctly is to define a schema for each type on its own terms.

Take an invoice. Header-level fields, vendor name, invoice number, dates, totals, behave differently than line-item fields, descriptions, quantities, unit prices, tax amounts. These field classes need to be tested and enforced separately, because treating them as one undifferentiated block misses the most common failure class in AP automation. An extraction API can nail every total amount and still stumble on line-item descriptions, so you have to judge acceptability by the workflow it feeds. Mandatory status is a decision made by the workflow that consumes the data, not a property of the data itself.

Azure Document Intelligence's mortgage models make this concrete at the product level. The platform ships separate prebuilt models for the Uniform Residential Loan Application (Form 1003), the Uniform Residential Appraisal Report (Form 1004), the Verification of Employment form (Form 1005), the Uniform Underwriting and Transmittal Summary (Form 1008), and mortgage closing disclosures.

Regulatory filings carry this logic further. The Canada Revenue Agency publishes XML specifications for information returns, T4, T4A, T5, NR4, and others, that spell out required fields per form. The CRA requires Name, Address, Country, and Province fields to contain valid text; it treats an empty mandatory field as a submission error, not a warning. It's a filing requirement with legal weight behind it, not an engineering preference about schema design.

A tempting shortcut is to build one flexible schema with a long list of optional fields and let it cover several document types at once. That shortcut doesn't hold up. Optional fields don't get enforced, and FCR only measures the fields marked mandatory. Making a field optional to stretch a schema across document types is functionally the same as not requiring that field at all.

Invoice mandatory field schema: what AP automation requires

Invoice extraction is the clearest starting point because most teams already recognize the shape of the problem. Automation rules define the specific fields a pipeline needs to capture, invoice number, date, amounts, tax, and line items, and how to read the formats they arrive in. Those rules are what standardize routing, matching, coding, and approval across every invoice that enters the system.

At the line-item level, the mandatory fields are description, quantity, unit price, line total, and tax code or rate per line where the jurisdiction or buyer requires it. You should treat each line item as its own record with its own FCR calculation, not fold it into a single document-level score.

Confidence thresholds get applied field by field, not at the document level. So a single invoice can auto-route on its header fields (vendor, date, total) while a specific line item with a low-confidence unit price gets flagged for a human to check. The schema also feeds the system's own improvement loop: corrections made by human reviewers train future extraction, and corrections to mandatory fields should carry more weight in that training signal than corrections to optional, nice-to-have fields.

The rule that makes all of this matter in practice: a null on a mandatory line-item field has to fail the document or send it to human review. If you let a record with an empty unit price pass through to payment, a mandatory field schema exists to stop exactly that failure mode.

Payslip and tax form schemas: where regulatory structure defines mandatory fields

For payslips and tax forms, the mandatory field list isn't something an engineering team chooses; it's set by the regulatory instrument the document implements, and a missing field is therefore not just a data quality issue but a compliance issue.

The CRA's XML specifications make this explicit. Information returns, T4, T4A, T5, NR4, and others, require valid text in Name, Address, Country, and Province fields, and the agency treats an empty mandatory field as a submission error rather than something to flag and move past. There's no soft landing for an incomplete mandatory field in a tax filing.

Payslip schemas carry their own list: employee name, employer name (mandatory in jurisdictions like Australia, though not a statutory requirement in the UK), pay period start and end, gross pay, net pay, tax withheld, and each deduction type and amount. Deductions need to be listed individually rather than rolled into one aggregate figure, because payroll reconciliation downstream depends on line-level detail, not a lump sum.

Multi-copy tax documents introduce a specific failure mode. Aggregate accuracy looks fine in that scenario, but FCR for the second record is zero. Azure Document Intelligence updated its prebuilt tax form models in March 2026 specifically to address this, adding quality improvements for multi-copy extraction so that multiple W-2s or 1099s in one document can be extracted in a single request with more complete field coverage. That update is a direct response to the exact completeness gap multi-form payslip batches expose.

So the fix at the pipeline level is to apply schema enforcement per record inside a multi-document batch, not per document. A document-level FCR check can miss a record-level omission buried in a multi-form filing, because the document as a whole can still look complete when one record inside it isn't.

Bank statement schemas: the completeness challenge in transaction-level extraction

Bank statements raise a different kind of completeness problem. Mandatory field coverage has to operate at the transaction level, because a statement that looks complete at the document level can still be hiding a gap in the middle of its transaction list.

Azure Document Intelligence's bank statement model, updated in November 2024 to add check table extraction, covers account information including beginning and ending balances along with transaction details. The field coverage built into that prebuilt model is a useful baseline for what a transaction-level schema needs to require: account holder name, account number, statement period start and end, opening balance, and closing balance at the document level, with every individual transaction carrying its own required fields underneath.

The sharpest check in this schema is a computation: the sum of every transaction applied to the opening balance has to equal the stated closing balance. You express that reconciliation check as validation logic rather than a simple non-empty test, and it's the textbook example of what production-grade agentic extraction means by validation and cross-checking before output goes out the door.

The reconciliation check earns its place because of what it catches. A bank statement where the extractor silently drops a page can still score a perfect FCR on every field it did manage to extract. Field-level monitoring alone won't flag that gap, because every field it looked at is fine. Only the closing balance check fails, and only the closing balance check would have caught the missing page.

Mortgage closing disclosure schema: multi-document validation as mandatory coverage

Mortgage closing disclosures push mandatory field enforcement past the boundary of a single document. Completeness here can't be judged by looking at the closing disclosure alone, because some of its fields only make sense when checked against other documents in the same loan file.

Cross-referencing extracted data across those documents, comparing the income on a paystub against the figure on the Form 1003 application, for instance, catches discrepancies immediately, flags missing signatures or expired documentation before the file ever reaches underwriting, and helps the file stay compliant with TILA and RESPA requirements. Azure Document Intelligence's mortgage models reflect this by splitting the loan file into separate prebuilts: Form 1003 (Uniform Residential Loan Application), Form 1004 (Uniform Residential Appraisal Report), Form 1005 (Verification of Employment), Form 1008 (Uniform Underwriting and Transmittal Summary), and the closing disclosure itself, each its own model, because mandatory fields differ across these instruments even inside the same loan file.

One detail stands out because it's easy to miss: signature detection, which the mortgage model now supports across Forms 1003, 1004, 1005, and the closing disclosure. A signature functions as a mandatory field in the schema sense. A closing disclosure missing a detected borrower signature is an incomplete record no matter how well every financial field on the page was extracted.

The mandatory fields on a closing disclosure itself cover loan terms (amount, interest rate, product type), projected payments (principal, interest, mortgage insurance, estimated escrow), closing cost totals, cash to close, and comparison table values like APR and total interest percentage. A consumer signature line for acknowledgment of receipt is part of the form, but the TRID Rule does not require that signature, leaving it optional rather than mandatory in the schema.

The cross-document rules are what make this schema genuinely multi-document rather than just thorough. A closing disclosure's stated loan amount has to match the figure on the 1003, and a paystub's income figure has to line up with the income stated on the 1003. These checks are mandatory field rules expressed as relational constraints between documents rather than single-document field checks. When an extraction engine hits a genuinely ambiguous value, it assigns that specific field a low confidence score and routes it to human review, where a trained analyst corrects the data and labels it to improve the underlying model. In a mortgage file, that human-in-the-loop record doubles as the compliance audit trail.

A fair objection here is that cross-document validation is too tangled to encode in a static schema. Agentic pipelines answer that by breaking the validation into sub-tasks: extract the parties and loan terms first, then cross-check those values against related documents for internal consistency. The schema defines what has to match across the file. The agent is what actually runs the check.

Insurance claims documents: schema rules for multi-form, heterogeneous document sets

Insurance claims present the hardest version of this problem, because you can't fix the document set in advance.

Processing a claim this way requires genuine multi-document reasoning: an agentic system reads across the entire claim file, validates that coverage applies, identifies any exclusions, computes a provisional reserve, and routes the claim to an adjuster for review with a structured explanation attached. That list of tasks, coverage validation, exclusion checks, reserve computation, routing, only works if the schema defines what counts as a complete claim file at the level of the whole set of documents, not at the level of any single form inside it.

A mandatory field schema for a document type that isn't fixed in advance has to name the fields the claim file needs as a whole and then check which document in the file is supposed to supply each one, which is a harder enforcement problem than any single invoice, payslip, bank statement, or closing disclosure poses on its own, because the schema has to account for variation in the document set itself before it can even start checking whether the fields inside that set are complete.