Every extraction tool demos beautifully on a one-page table. The reason teams get burned later is that real documents put the header on page 3 and the last twelve rows on page 4 — and the output still looks like a clean spreadsheet.
What actually goes wrong at a page break
A table is not a single object in a PDF. It is a set of text positions, lines and whitespace that a parser interprets. At a page boundary, four things break at once:
- The header does not repeat. Page two has numbers with no labels, so the parser infers a structure — sometimes from the first data row, sometimes from unrelated text.
- Column widths change. Page two may have different margins. The same column is now at a different x-coordinate, and a fixed-tolerance parser assigns it to the wrong field.
- Rows are re-numbered. Multi-line descriptions that started on page one finish on page two and get detached into their own rows.
- Totals are not re-checked. The document’s printed total is on the final page. If it is captured at all, it sits in a different table from the rows it is supposed to verify.
The open-source Docling project documents the first of these as a structural limitation: tables are processed page by page and continuations are not stitched back together. Turning cell matching on or off, or switching accuracy modes, does not fix it — the failure is above the level those settings operate on.
Borderless tables fail differently
Many financial tables have no grid at all: columns are separated by spaces. A parser has to infer the column boundaries from alignment. When the alignment is imperfect — a wide date column, a wrapped merchant name, a currency symbol — the inference collapses. In the worst case the region is classified as a picture and the content disappears entirely rather than arriving misaligned.
Merged cells shift everything below
Rent rolls are the classic case: one unit number merged across four tenant rows. Expand that merge by one row and every subsequent unit is attributed to the wrong tenant. The sheet still looks plausible, which is exactly why it survives a quick review.
Three checks that catch all three failures
1. Reconcile against the document, not against your expectations
Sum the extracted amounts and compare with the total printed on the document. For statements, recompute the running balance after every row: opening + deposits − withdrawals should equal closing, every time. A single break localises the problem to a row instead of a page.
2. Demand page provenance
If a value cannot be traced back to a specific region of a specific page, you cannot audit it. This matters more than the extraction score: when a client asks about a number, the answer should be a click, not a search through a 90-page PDF.
3. Make uncertainty visible
A tool that reports “zero errors” on a table it could not align is lying by omission. Look for an output that lists disputed cells, failed rows and unreadable regions — and that never auto-corrects a number to make the total work.
What SheetParser does about it
It does not claim to rebuild every cross-page table perfectly. It does three things that make the failure survivable:
- Recomputes the running balance after every row, and flags the row where the chain breaks.
- Maps every extracted value to its source page region, so you can inspect the evidence.
- Lists disputed cells from an independent second read instead of averaging them away.
On a statement, a broken page break almost always shows up as a broken balance chain. That is the point: the check is designed to fail loudly when the extraction is wrong. Run your worst document through it — the first file each day is free up to 10 pages.