Document AI: Check for Missing Rows Before Trusting a Parsed Table

The extracted spreadsheet looks clean. Its columns line up, its numbers add correctly, and the parser reports a strong benchmark score. Yet one source row is missing. A tidy reconstruction has turned a document problem into a plausible accounting error.

Document AI is increasingly useful for invoices, research tables, and scanned records. The challenge is deciding which output can move into a calculation. That decision needs a source-to-table audit, not just a successful API response or a well-formed JSON object.

An August 10, 2026 research preprint introduces TableParseMap, a diagnostic set of 916 challenging tables across five scenarios and nine failure types. The authors' strongest evaluated parser reached 85.03 TEDS on that set. TEDS—Tree-Edit-Distance-based Similarity—compares a reconstructed table representation with its reference, including structural and content differences. This is a deliberately difficult benchmark, not an estimate that 14.97% of every business's cells are wrong. The practical lesson is to test failure modes that an overall score can hide.

Distinguish four different successes

Table detection finds a region. Structure recognition reconstructs rows, columns, and spans. Text recognition reads content. Business interpretation assigns meanings such as quantity, currency, and tax. Success at one stage does not establish the next.

For example, a parser can correctly locate a table while treating a two-level header as ordinary data. It may recognize every numeral but attach a quantity to the next product. A language model can produce the correct JSON schema while filling a missing field with an inferred value.

The Microsoft Table Transformer repository separates detection and structure-recognition models and supplies evaluation tooling. That separation is useful for designing an audit even if you use a different parser. It does not establish that one tool will handle your document collection without validation.

Choose a test set that resembles the work

The OmniDocBench CVPR 2025 paper evaluates diverse PDF components and document sources. A broad benchmark is valuable context, but a procurement decision also needs the layouts your team actually receives.

Build a small authorized sample with plain tables, merged headers, multi-page tables, low-resolution scans, and documents containing several currencies or units. Keep a separately reviewed reference for each sample. Make difficult cases visible instead of averaging them into a large pile of easy pages.

Separate development and acceptance samples. If you tune prompts on a document, that document no longer provides an independent acceptance test. Keep document-level boundaries so a template's near-duplicate pages do not leak across the split. Record versions of the parser, rendering process, and normalization rules.

Work through an internally consistent error

Consider this synthetic invoice table, with no tax or discount:

The extraction returns A and C, omits B, and calculates a new total of $280. Every returned line satisfies quantity × unit price = line total; the returned total matches the sum of returned lines. An arithmetic-only validator would approve the result.

Source row coverage is two of three item rows, or 66.7%. The monetary omission is $80, or 22.2% of the source total. These describe different consequences. A row count gives each row equal weight; a monetary impact measure gives larger amounts more weight. Neither replaces checking whether a safety-critical or contractual field is missing.

Now consider a second failure: all three item names remain, but the quantity for B becomes 3. If the extracted line total remains $80, arithmetic detects a contradiction because 3 × 40 = 120. If the system regenerates both the line total and total, the output becomes internally consistent at $400. Recalculation can conceal an extraction error rather than repair it.

Keep the source total as evidence

Store extracted and calculated values separately. The value printed on the document is a source field; the sum computed by your system is a derived field. Comparing them creates evidence. Replacing the former with the latter destroys that comparison.

In a real invoice, tax, rounding, freight, and discounts can explain some differences. Specify those rules before flagging every mismatch. An unresolved discrepancy is a reason for review, not proof of fraud. Likewise, a match can be coincidental when two errors offset one another.

For research tables, the analogous problem is a missing subgroup or footnote. Preserving counts and headings matters even when there is no monetary total. Mark unrecognized content explicitly; an empty field is more honest than a plausible reconstruction with no visible uncertainty.

Audit headers and multi-page continuity

A table that continues on another page often repeats its header. Removing the repeated header is useful only when the continuation is correctly identified. Otherwise two independent tables may be joined, or a legitimate first row may be discarded.

Microsoft's layout documentation describes extraction of tables and cells with row and column positions and spans. Its output can support a source mapping; the application still needs to decide which tables belong together.

For each continuation, inspect the last row on the preceding page, the first data row on the next page, column order, units, and section labels. A heading such as “Thousands of dollars” changes the interpretation of every numeric cell beneath it. It is not decorative text to remove during cleaning.

Keep the original page index and region reference after joining. If a reviewer must reopen the entire PDF to locate one disputed value, the extraction pipeline has saved little review effort. A compact source mapping is a practical quality feature.

Report acceptance metrics at the right level

Define a strict document acceptance rule separately from cell accuracy. Suppose a synthetic test has 20 invoices, each with five required fields. The parser gets 98 of 100 fields right, but those two errors occur in two different invoices. Field accuracy is 98%; fully correct invoices are 18 of 20, or 90%.

Neither figure says whether the wrong fields were a harmless reference label or a payment amount. Report error severity and the count of unresolved documents. Also report the sample size: two errors in a small sample are not a precise forecast of production behavior.

Confidence scores, where available, can help prioritize review. Their scale and calibration depend on the tool and field. Do not equate a score of 0.98 with a demonstrated 98% probability that your entire document is correct. Evaluate that relationship on reviewed examples before using a threshold for automatic acceptance.

Design a review queue with a stop condition

Route cases with missing tables, missing required fields, span mismatches, or unexplained reconciliation differences to review. Give the reviewer the relevant source crop, captured values, and a reason. Avoid a queue that merely says “low confidence” without identifying what must be checked.

The TableParseMap preprint also explores selective intervention and visual consistency checks. Its experimental results are not a production guarantee, and visual similarity alone cannot establish semantic correctness. Treat the research as a reason to preserve inspection and rollback, rather than as permission to let one model certify another's output.

Write a stop condition: if the source is unreadable or the required meaning cannot be established, the record remains unresolved. Escalate to an authorized source owner. Retrying a model until it returns a complete-looking answer is not a validation method.

Run a small acceptance exercise

Take five authorized sample documents. For each, count expected item rows, capture printed totals and units, and identify merged or repeated headers. Compare extraction output with a reviewed reference before allowing automatic calculations.

Include one deliberately incomplete output from the synthetic invoice above. Your validator should reject it even though the returned arithmetic balances. Then add the quantity-shift example and explain which check catches it. This exercise reveals whether the workflow checks source fidelity or only the consistency of its own output.

Keep a correction log with the source location, failure type, corrected value, and reviewer. Over time, use that log to improve routing and select harder acceptance examples. The goal is a traceable dataset whose unresolved parts remain visible.

For the downstream dataset, the data quality contract helps turn accepted fields into explicit obligations.

Sources and evidence boundaries

• TableParseMap, August 10, 2026 preprint, with full text. Diagnostic benchmark, not a universal business error rate; peer-review status is not established here.
• OmniDocBench, CVPR 2025. Broader document parsing evaluation.
• Microsoft Table Transformer. Official models and evaluation tooling.
• Microsoft document layout documentation. Product-specific output structure.

Invoice amounts, acceptance samples, and worksheets are original synthetic examples. No vendor API or third-party document upload was tested for this article.