Mandatory Field Coverage Rules by Document Type

Every document type carries a hidden checklist. An invoice needs a PO reference before it can move through accounts payable. A W-2 needs an employer EIN before the income it reports can be properly verified. When an extraction pipeline skips a field on that checklist and hands over the rest as if nothing were missing, it hasn't failed loudly enough for anyone to notice, and that's the actual danger.

Every document type exists to tell a defined audience a defined set of facts. Regulators, counterparties, and the software sitting downstream all depend on specific fields showing up, correctly, every time. That's not incidental to the document, it's the point of the document. So when a pipeline returns partial output and calls it done, it isn't failing in any visible way. It's shipping a broken record downstream dressed up as a complete one.

The gap between "extracted something" and "extracted everything the downstream system requires" is where silent failures live. Making that gap explicit, field by field, document type by document type, is the engineering work that separates a pipeline built for a demo from one built to run in production.

What mandatory field coverage actually means, and what it does not

Three separate things get flattened into one conversation, and the flattening causes most of the confusion. Character accuracy asks whether the individual characters got read correctly. Field accuracy asks whether the right value landed against the right field name. Coverage asks whether every required field is present and populated at all. These are not the same question, and a system can score well on the first two while failing the third completely.

When a vendor advertises "high accuracy," that number is almost always character accuracy. It says nothing about whether the invoice number, the PO reference, or the line-item unit prices got extracted in the first place. A document can hit 99% character accuracy on every field it decided to extract and still be missing the one field a downstream system can't function without.

Mandatory field coverage works as a binary gate at the field level. A field is either present and validated, or the document fails the check. There's no partial credit in an AP system waiting on a PO number, and there's no partial credit in a lender's underwriting engine waiting on an employer EIN. Coverage rules are also specific to document type by nature: a PO reference matters enormously on an invoice and means nothing on a bank statement, while an employer EIN is mandatory on a W-2 and has no equivalent on a mortgage closing disclosure.

Worth separating, too: a missing field and an extraction gap are not the same failure, even though they look identical downstream. A missing field means the document never contained that data. An extraction gap means the data was sitting right there on the page and the parser walked past it. Both produce the same blank space in the output. Both require different fixes, and conflating them is how teams end up debugging the wrong problem.

Invoices: the field set that AP automation actually depends on

A trusted invoice extraction depends on a specific, non-negotiable set of fields. Vendor identity, meaning name, address, and tax ID, feeds supplier master matching and catches fraud before it reaches a payment run. The invoice number works as the deduplication key, so a missing or garbled one opens the door to paying the same invoice twice. Invoice date drives payment terms, aging buckets, and whether an early-payment discount window is still open.

Line-item descriptions, quantities, and unit prices matter because a three-way match against the purchase order and the goods receipt needs all three to reconcile. Line and document totals get checked against each other arithmetically, and a mismatch there is a mandatory validation failure on its own, not something to flag for later review. The purchase order reference is the thread connecting the invoice back to the original commitment; without it, no automated approval workflow has anything to close against.

Vendors have been expanding what counts as extractable header data. SAP's Document Information Extraction release notes from Q1 2025 list an expanded set of address-related header fields for invoices, including buyer city, supplier city, buyer country code, and supplier country code. That expansion matters because positional, template-based OCR breaks the moment a supplier redesigns their invoice layout. AI-based document intelligence reads for meaning instead of position: it identifies what a field represents regardless of where it sits on the page, so a new template doesn't require a new set of rules.

PLANERGY's 2025 benchmarking found AI-driven document processing achieves extraction accuracy above 98%, compared to significantly lower rates from template-dependent OCR, but that number only means something once you know what's being measured. If the field set behind that 98% is limited to header fields, it says nothing about line items, and line items are exactly where three-way match lives or dies. A common failure pattern in practice: teams treat line-item extraction as a nice-to-have enrichment layer instead of a mandatory field. The result is a record that's header-complete, line-incomplete, and passes every coverage check on paper while failing the actual matching process it exists to support.

Bank statements: when structure is the data

A bank statement's mandatory coverage set starts with account holder identity and the account number, since everything else anchors to those two fields. Statement period, meaning opening and closing dates, comes next, along with opening and closing balances. Then there's the transaction table itself: each row needs a date, a description, a debit or credit amount, and a running balance. All four columns are mandatory together. A parser that returns two out of four hasn't covered the row, it's covered half of it.

The failure mode that shows up most often here is structural, not textual. A parser that dumps everything as plain text destroys the relationships between columns: a date, a description, and a debit amount become three unconnected strings sitting near each other on the page, and a downstream system has no way to figure out which amount belongs to which transaction without re-parsing the whole thing from scratch. Coverage on a bank statement isn't just "are these fields present," it's "are these fields still structurally linked to each other." A running balance column that gets extracted as one long concatenated string is a coverage failure, full stop, not a cosmetic formatting issue.

Microsoft's Azure Document Intelligence added check table extraction to its US Bank Statement Model in a November 2024 general availability release, which extends mandatory coverage to check-related transactions that used to sit outside the standard transaction table entirely. In mortgage underwriting and income verification, a bank statement with incomplete transaction coverage doesn't partially qualify a borrower. It doesn't qualify them at all.

US tax forms: multi-copy documents and the coverage completeness problem

Tax forms carry different mandatory field sets depending on the form, and treating them interchangeably is a design mistake before it's ever an execution mistake. A W-2 needs employer EIN, employer name and address, employee SSN, wages and tips in Box 1, federal income tax withheld in Box 2, Social Security wages and tax, Medicare wages and tax, and, where state income tax applies, state wages and state tax withheld. A 1099 has its own mandatory field set, but different 1099 variants serve different payment categories, so assuming they share an identical mandatory field set is a coverage design error baked in from the start. A 1040 has a defined set of summary fields that income-dependent workflows depend on, and missing any of them breaks the downstream process that relies on them.

The trickier problem shows up with multi-copy documents. A borrower submits a single PDF containing two W-2s or three 1099s, which happens constantly. A pipeline that only extracts the first instance produces a record that looks coverage-complete for one employer while silently dropping the rest. That's not a partial failure, it's a complete failure wearing a complete-looking output.

Microsoft's Azure Document Intelligence release notes for March 2026 describe prebuilt models for US tax forms updated to support 2025 tax forms, with quality improvements aimed specifically at multi-copy extraction, meaning multiple W-2s or 1099s bundled into one document. Users can now pull data from multi-form filings in a single request, which gets closer to genuine field coverage rather than coverage of the first form found. The rule that has to hold here: for a multi-employer tax package, mandatory coverage means every form instance gets extracted and reconciled, not just one. A pipeline that hits 100% field accuracy on the first W-2 and 0% on the second hasn't half-succeeded. It has failed the document.

Mortgage documents: when a missing field is a compliance event

Mortgage paperwork raises the stakes on coverage because the fields aren't just operationally useful, they're often legally required. The Uniform Residential Loan Application, Form 1003, requires a comprehensive set of mandatory fields covering borrower profile, property, and loan details, and a partially extracted 1003 simply can't be submitted for underwriting. The appraisal, Form 1004, requires a defined set of mandatory fields covering the subject property and the collateral assessment for the appraisal to hold up.

The closing disclosure is governed by TRID, the TILA-RESPA Integrated Disclosure rule, which defines specific loan cost and payment fields as mandatory. A closing disclosure missing line items isn't an operational inconvenience, it's a regulatory document failure. Form 1005, the Verification of Employment, requires mandatory employment detail fields; missing any one of them blocks the underwriting decision outright.

Signature detection deserves its own mention as a coverage field, not an afterthought. Azure Document Intelligence's mortgage model added signature detection for Forms 1003, 1004, 1005, and the closing disclosure in its November 2024 general availability release. A signature isn't decorative. An unsigned closing disclosure isn't a valid closing disclosure, no matter how complete every other field on the page happens to be.

The production numbers back up why this matters at scale. Grooper's 2025 case reporting describes a software company that switched its cloud mortgage platform to a document processing solution and cut implementation time from six months to six weeks. A separate automotive fintech partner classified and extracted 6,000 contracts in 72 to 96 hours, work estimated at roughly 100 human-days. Those speed gains only hold up if mandatory field coverage rules get enforced at the pipeline level rather than relaxed to hit a deadline. In mortgage lending specifically, a missing mandatory field doesn't produce a slightly-off answer somewhere downstream. It produces a document that can't legally close, and can't be sold into the secondary market.

SEC financial filings: what happens when the mandatory field set is 369 fields wide

SEC 10-K and 10-Q filings operate on a completely different scale than anything discussed so far. The ExtractBench 2026 benchmark (arXiv:2602.12247) documents a mandatory field schema for these filings that runs to 369 fields, and that single document type accounted for 84% of all field evaluations across the entire benchmark, 15,498 out of 18,516 total.

The results were not encouraging. Across the SEC 10-K and 10-Q documents tested, no model produced valid output for any of them. On other document types, where models did at least produce valid JSON, field-level accuracy landed between 65% and 80%, averaging 72.9% overall. The end-to-end pass rate across every document type in the benchmark came out to 4.6%.

Sit with that 72.9% figure for a second. On a schema with 369 mandatory fields, an accuracy rate in the low 70s means something close to 100 fields per document come out wrong or missing, even in the cases where the parser didn't collapse entirely. And the 4.6% end-to-end pass rate is the number that actually matters for anyone running this in production: nearly 95% of documents failed to produce a complete, valid output. That's precisely the failure a mandatory coverage rule is supposed to catch and surface, rather than let slide through as a technically-successful JSON blob. No AP process and no compliance workflow can absorb a 4.6% pass rate quietly. The only workable architecture is one built to flag the failure loudly, not one that hands a downstream system a partial file and calls it a win.

How edge cases break coverage rules that worked in testing

The gap between a pipeline that performs well in a demo and one that survives production isn't really a model-quality problem. It's a density problem. Models handle the common 90-plus percent of cases fine. What breaks things is the remaining slice, where edge cases pile up faster than a team can write rules to catch them. Fewer than 10% of in-house parsing pipelines make it to production, largely because that pile grows quicker than anyone expects going in.

PureDocBench (arXiv:2605.07492) documents specific structural failures on a power semiconductor datasheet that illustrate the pattern well. In one case, the product header block, meaning brand and model, was entirely absent from the reconstructed output. A coverage rule requiring a product identifier field would catch that instantly; a pipeline without one just passes along a structurally incomplete record as if nothing were wrong. In another case, tables were preserved correctly but placed in the wrong section of the document, so the data existed but got tied to the wrong context. A coverage rule checking field presence passes that document. A coverage rule checking field-to-section association doesn't, and shouldn't.

A third failure involved a technical symbol misread: a numeric unit rendered incorrectly in a way that sails through character-level checks while producing a specification-level failure in a context where that distinction is safety-critical.

Cross-page tables cause their own version of chaos. A naive text extractor applied to a dense financial table spanning multiple physical pages can split it into disconnected fragments that no longer relate to each other. Exhibit numbers lose their descriptions in the split. Ask a downstream system about Exhibit 4.5 afterward, and it hallucinates a filing date that appears nowhere in the actual document.

Then there's the noise cascade. Research documented in arXiv:2606.24420 traces most extraction errors back to the document itself rather than the model reading it: degraded OCR output feeds a frontier model garbage, and the model generates high-confidence tokens describing that garbage as if it were real content. A coverage rule requiring a vendor tax ID passes, technically, because something got extracted into that field. What got extracted is a garbled string with no relationship to an actual tax ID. Coverage rules only carry weight if the validation behind them checks for plausibility, not just presence. A rule that only asks "is there something here" will wave garbage through the gate every time.

Confidence scores and the validation layer that makes coverage rules enforceable

A mandatory field coverage rule with no confidence threshold attached to it isn't a rule, it's a label stuck on the output after the fact. What actually makes a coverage rule enforceable is routing: high-confidence extractions move straight through, low-confidence ones get pulled for a human to look at before anything downstream touches them.

A standard three-band routing model has become fairly common across the industry. High-confidence extractions pass straight through to downstream systems, mid-range scores get routed to a human review queue, and low-confidence results get rejected or handled as an exception. Simple in structure, but the bands only mean something if the underlying confidence score is actually calibrated to reality.

That's the catch. An uncalibrated model can claim 95% confidence and be right far less often than that at scale, and the danger cuts both ways: high-confidence wrong extractions slide through the gate undetected, while low-confidence extractions that were actually correct get pulled for review that didn't need to happen. Research in arXiv:2606.24420, under the name EXTRACTCONF, found that at 80% coverage, a properly calibrated system reaches very high automated accuracy, a substantial jump over the baseline rate. That trade-off, what coverage level buys what accuracy guarantee, is exactly the number a mandatory coverage rule needs to state explicitly rather than leave implied.

Calibration isn't uniform across field types, either. Separate research (research into LLM-based extraction has found that confidence calibration varies by field type, with free-text fields posing particular challenges of predicted probability. That has direct consequences for mandatory text fields, things like vendor names or line-item descriptions on an invoice, where a model's stated confidence may look reassuring and mean considerably less than it appears to.