Extracting tables that span pages, merge cells, and hide their totals in footnotes
Tables are among the most structurally treacherous objects in document extraction, and the three failure modes that expose pipelines most reliably are spanning tables, merged cells, and footnote-buried totals. Each one fails differently. Each one fails quietly. That combination is what makes them expensive to discover.
Why Multi-Page Tables Break First
When a table runs across a page break in a PDF, the underlying document representation frequently treats it as two separate objects with no programmatic relationship between them. The header row lives on page one. By page three, it has vanished from the data layer entirely, even though any human reader carries it forward without thinking. Their eye does that work automatically.
A naive extraction tool sees two orphaned grids. It will duplicate the header, drop it, or silently treat the second fragment as a standalone table with no column context. You end up with rows that have no intelligible relationship to the values they contain.
The first time I watched this happen on a regulatory filing, the pipeline completed cleanly. No errors surfaced. The output looked reasonable. It was only when someone tried to reconcile a subtotal three days later that we traced the discrepancy back to a header that had been silently dropped at the page break. The column values had shifted one position. Every figure in that fragment was attributed to the wrong field, and nothing in the extraction log had flagged it.
That is the specific danger here. The error is not anomalous. It looks like data.
The difficulty scales badly with document length. A two-page span is manageable. A table that runs eight pages with slightly different column widths on each page, which happens more than you would expect in long government reports, compounds reconciliation errors in ways that are genuinely hard to audit after the fact.
Merged Cells and the Attribution Problem
Merged cells are a design choice made entirely for human readers. They communicate hierarchy through spatial proximity. The cell that reads "North American Operations" and spans four rows beneath it is immediately legible to anyone looking at the page. To an extraction algorithm working from coordinate space or raw XML, that merged cell is a geometric anomaly. Its bounding box does not align with the grid. The value appears once but semantically belongs to multiple rows.
Most tools either drop it or assign it to the first row it occupies, leaving every subsequent row in that group without categorical attribution. The extraction completes. The data lands in your target format. Nothing throws an error. You find out later, when the hierarchy you needed to reconstruct has been replaced by a flat list that has lost all organizational meaning.
There is an additional complication that evaluation frameworks tend to obscure. Vertically merged cells break row-level attribution. Horizontally merged cells break column-level attribution. Many tools handle one meaningfully better than the other. Testing against a single merge type and declaring the tool viable is a methodological mistake, and it is a common one, partly because horizontal merges are easier to construct artificially in test documents. Real-world tables contain both, in combination, often within the same structure. The evaluation has to reflect that.
Why the Silence Is the Problem
Extraction errors that surface as exceptions are manageable. You see the failure, you fix the logic, you rerun. The merged cell problem is worse than that because nothing breaks. The pipeline succeeds. The downstream system receives data. The error is only detectable through domain knowledge applied to the output, and in high-volume extraction contexts, that kind of manual verification is not always happening systematically.
Footnotes: The Most Underappreciated Failure Mode
In financial statements, government filings, and technical appendices, it is standard practice to place qualifying figures, restated totals, or currency-adjusted subtotals in footnotes rather than the table body. The reader traces the asterisk to the bottom of the page, reads the note, adjusts their interpretation of the figure. The relationship is obvious in print. It is not encoded anywhere in the document structure.
For extraction systems, that asterisked cell and its corresponding footnote are spatially distant objects with no programmatic link between them. A tool that does not explicitly model this relationship will pull the table and pull the footnotes as separate items, with nothing connecting them. You capture the number without the condition that governs it. A restated total arrives as a clean total. A value adjusted for currency conversion carries no indication it was touched.
I have seen this cause real compliance problems, not theoretical ones. In audit contexts, the distinction between a raw figure and a restated figure is not a rounding issue. It is a material difference in what the number means. Extraction that loses that context does not produce incomplete data. It produces confidently wrong data, which is a different category of problem.
What Reliable Extraction Actually Requires
No single off-the-shelf tool handles all three of these failure modes well simultaneously. The solutions exist along a spectrum from rule-based parsers to machine learning systems trained on document structure, and each makes real tradeoffs.
Rule-based systems are interpretable and fast, but brittle. The moment a document deviates from the format the rules were written against, errors accumulate without announcement. ML-based systems generalize better across document variation, but they require large, high-quality training sets, and their accuracy on real-world documents is not always reflected in vendor benchmarks that evaluate against clean, well-formed source material.
What actually works in practice is layering. Heuristic logic detects table boundaries and flags suspected spanning structures. Coordinate-based reconstruction handles merged cell geometry. An explicit footnote-linking pass scans for reference markers and resolves them before the data leaves the extraction layer. None of this is elegant. It is the kind of engineering you arrive at after your totals do not reconcile and you spend an afternoon tracing a discrepancy back to a footnote restatement your pipeline never captured, on a document you thought you had already solved.
The Test Worth Running
The right evaluation for any pipeline handling these document types is not a clean, single-page table with uniform column widths. The right test is a table that starts on page four, ends on page nine, contains merged category headers spanning three columns, and references a restated subtotal in footnote twelve. That is a document that exists in the real world, routinely, across industries.
If the output from that test is indistinguishable from what a careful human analyst would produce, you have a pipeline worth trusting. Most pipelines fall short of that bar in ways that matter operationally. Knowing precisely where they fall short, and building compensating logic around those gaps, is the actual work. Extraction that you can trust and extraction that merely appears to work are indistinguishable until you need to rely on one of them.
