How Continuation Pages Break Structured Data Extraction (and How to Fix It)

Multi-page tables, ledgers, and forms rarely repeat their header on every page. Page one says whose record it is; page two just continues the grid and assumes you remember. A human reading the stack in order gets this for free. An extraction pipeline that processes each page independently gets nothing — and that gap is where a surprising amount of structured-data extraction quietly goes wrong.

The problem: a page that doesn't say whose data it is

This shows up anywhere a paper or scanned record runs longer than one page: handwritten data tables, multi-page intake forms, ledgers, inspection logs. The first page identifies the record. Every page after it just keeps going — same columns, same handwriting, no repeated name or ID, because the person writing it never needed to remind themselves whose page it was. That's a reasonable thing for a human to skip. It's exactly the assumption an automated pipeline can't afford to make.

Why row-position and page-order extraction fail

The naive fix is to assume page order carries meaning — page N+1 belongs to whatever page N was about, or row 12 belongs to the twelfth record in a fixed roster. Both are proxies for identity, not identity itself, and proxies break under completely normal conditions: a page scanned out of order, a record skipped mid-batch, two records' continuation pages interleaved in the same stack. One skipped line or reordered scan, and every downstream attribution shifts — quietly, because nothing about the output looks wrong.

Identity resolution: the fix

The reliable approach is to resolve identity per record, never by position: attach every page to the record it belongs to using an identifier the record carries, or that the continuation page names in its surrounding context — a margin note, a repeated partial label, a reference back to the first page. Position can be a hint, but it should never be the only evidence. When a page genuinely carries no identifying signal, that's not something to paper over with an assumption; it's a case for the next section.

Fail loud, don't guess

When identity genuinely can't be resolved — no identifier anywhere on the page or in the surrounding context — the correct behavior is to stop and flag it, not to attach the page to whatever record seems most likely. A flagged page gets a human's attention and gets fixed in seconds. A silently misattributed page looks exactly like a correct one, and it can sit in a dataset indefinitely before anyone notices the numbers don't add up.

How to test whether a pipeline actually handles this

1. Feed it a continuation page with no identifying text. See whether it flags that it can't attribute the page, or silently guesses.
2. Reorder the pages and reprocess. True identity resolution shouldn't depend on page order. If the output changes, the tool is using position as a stand-in for identity.
3. Remove one page and reprocess. Check whether the pipeline flags the resulting gap, or silently reattributes the remaining pages to cover for it.

NoteMerge was built around this exact rule. Every page is resolved to a record by the identifier it carries or that a continuation page names — never by counting rows against a fixed roster — and anything it can't resolve gets flagged for your review instead of a guess. See reconciliation vs. OCR for how this fits into the bigger picture of what a document-extraction pipeline actually needs to do beyond reading pixels.

Frequently asked questions