Handle blank separator pages in an extraction review

Make the absence of rows explainable

Record what was excluded so a reviewer can distinguish a harmless separator from a missing page of data.

For multipage invoices, use ParseMill to review extracted invoice data beside the source and export separate summary and line-item sheets. Include a page break in your trial and check that every required line made it through. Other report types need their own fit assessment.

Keep page coverage independent from row coverage. The register may correctly contain no rows from a divider, but a missing table on another page remains an exception. A single “empty” status for both conditions makes it difficult to distinguish a successful exclusion from a failed extraction.

Record a page disposition for the complete file

Microsoft: Pdf.Tables allows a bounded page range. Microsoft: Table.RowCount counts returned table rows; neither number alone explains a page that produced no data.

1. List every physical page in the selected source range, including covers and separators. Record the file version and the page-count basis.
2. Open each zero-row page at a readable zoom. Mark visible content and whether that content falls inside the agreed extraction scope.
3. For a verified blank page, record “blank separator inspected.” For narrative content, record “non-table page inspected” and preserve any relevant note reference.
4. For an expected table or unreadable page, keep an unresolved exception. Request a clearer original or use an appropriate manual process rather than declaring the page successfully empty.

Copy this coverage map

Synthetic example: a six-page report produces rows from two detail pages and no rows from four other pages.

Fifteen returned rows do not represent complete report coverage. Pages 1, 3 and 5 have explained no-row outcomes, while page 6 remains a failed or unsupported region. The handoff should name that limitation. Do not infer the number of missing records on page 6 unless the source supplies a dependable count.

Handle the ambiguous cases explicitly

A page that looks blank at fit-to-window size can contain faint text, a watermark, a small continuation note or an image that failed to render. Check the original in a trusted viewer and avoid treating a rendering problem as proof of blankness. If permissions or a damaged file prevent inspection, record that limitation.

Also consider whether a separator contains a section title that supplies context for later rows. Even if it has no numeric table, the title may identify a report segment or sample group. Preserve that relationship manually when necessary; excluding the page from row extraction should not erase useful context.

Check coverage before accepting a zero-row result

The page map should account for every selected physical page once. Count explained non-data pages separately from inspected data pages and unresolved pages. Confirm that any table expected by the source is either represented in the register or explicitly unresolved. Recheck an exception after obtaining a better source rather than overwriting its earlier failure record.

ParseMill can OCR clear printed English invoice PDF scans; a faint or unreadable page can still require a clearer source. Use the validation guide to check the received pages and the resulting invoice workbook. A zero-row response should never become invented successful data.