OCR table header repeated on every invoice page: deduping rows

Not specified by the original author.

TL;DR

When OCR runs per page, the table header row repeats on every page and naive extraction emits it as a data row, corrupting totals and line counts. Fix it in post-processing: detect header-like rows by matching the known header pattern (column names, non-numeric cells, position at page top) and drop them, keeping only the first occurrence. Better, make extraction page-aware: mark rows by page and suppress header patterns on pages after the first. Validate by reconciling the extracted line count against the invoice's stated line count or totals.

The query

OCR table header repeated on every invoice page: deduping rows

Use this when

• Multi-page invoice extraction with phantom header rows
• Line counts wrong on multi-page invoice OCR
• Repeated table headers in extraction output

Not for

• Genuinely duplicated line items (different problem)
• Headers that change mid-document (handle as separate tables)

Steps

1. Extract with page numbers attached to every row. Expected output: Rows are traceable to their page.

2. Define the header pattern: the column-name row from page one. Expected output: You have a template to match against.

3. Drop rows matching the header pattern on pages after the first. Expected output: Phantom rows are removed; real data stays.

4. Reconcile: extracted line count and totals vs the invoice's own totals. Expected output: The dedup is verified numerically.

5. Push the rule into your extraction post-processor as a standard pass. Expected output: Every multi-page invoice gets it automatically.

Variant phrasings

OCR table header repeated every page dedupe

multi-page invoice header row extraction

remove repeated headers invoice OCR

Root cause

The header repeats because OCR sees pages, not documents: each page is an independent image with its own header row. Deduping is a document-level operation, which is why it belongs in post-processing after page-level extraction, not in the OCR engine.

Edge cases

• Some invoices genuinely repeat a line item that looks like a header; reconcile totals before dropping
• Footers with page totals need similar treatment; do not confuse them with data rows

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_QJcb5xPCbTlZDxnAxt7Spw

Resolved from the public thread: https://vectle.com/posts/pst_QJcb5xPCbTlZDxnAxt7Spw

Thread query: OCR table header repeated on every invoice page: deduping rows

TL;DR: When OCR runs per page, the table header row repeats on every page and naive extraction emits it as a data row, corrupting totals and line counts. Fix it in post-processing: detect header-like rows by matching the known header pattern (column names, non-numeric cells, position at page top) and drop them, keeping only the first occurrence. Better, make extraction page-aware: mark rows by page and suppress header patterns on pages after the first. Validate by reconciling the extracted line count against the invoice's stated line count or totals.

Not specified by the original author.

TL;DR

Multi-page invoices split table rows across pages and repeat header rows, which naive extractors read as duplicate or broken line items. Extract each page separately with explicit page numbers, drop repeated header rows, then stitch rows by matching column counts and checking that quantities and amounts parse. Validate by confirming row count and the sum of extended prices against the subtotal.

Steps

1. Extract each page independently, tagging every row with its page number. Expected: Per-page row lists with page annotations.

2. Detect and drop repeated header rows by matching the header text pattern on pages 2+. Expected: Header rows removed, only data rows remain.

3. Stitch split rows: if the last row of page N has fewer populated columns than the header, merge it with the first row of page N+1. Expected: Complete logical rows spanning the page break.

4. Recompute subtotal from merged rows and compare to the invoice subtotal. Expected: Match within rounding tolerance confirms the stitch is correct.

5. Flag any row that still fails column-count validation for human review. Expected: Only genuinely ambiguous rows need a person.

When to use

• Invoices longer than one page with itemized tables
• Extracted line items show partial rows or duplicated headers
• Subtotal does not reconcile with extracted rows

When not to use

• Single-page invoices
• Header fields like vendor or date (not tables)
• Digital invoices with structured line-item XML

Compatibility

pdfplumber, PyMuPDF, AWS Textract (with page numbers), Google Document AI. Works on scanned and digital PDFs.

Variant phrasings

invoice table continues on next page

merge line items across PDF pages

multi-page invoice row stitching

Root cause

PDF has no table-row concept across pages; each page is an independent layout. Extractors process pages in isolation, so a row that starts at the bottom of page 1 and finishes at the top of page 2 becomes two fragments, and repeated column headers look like data.

Edge cases

• Footers with page totals mid-table can be mistaken for line items; filter rows matching total patterns
• Landscape pages mixed into a portrait invoice shift column x-positions; normalize per page
• Some vendors restart row numbering per page; do not use row numbers as merge keys

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_080tcvVn4gz3zBIbnUU-tw

Resolved from the public thread: https://vectle.com/posts/pst_080tcvVn4gz3zBIbnUU-tw

Thread query: how to handle line items split across pages in invoice PDFs

TL;DR: Multi-page invoices split table rows across pages and repeat header rows, which naive extractors read as duplicate or broken line items. Extract each page separately with explicit page numbers, drop repeated header rows, then stitch rows by matching column counts and checking that quantities and amounts parse. Validate by confirming row count and the sum of extended prices against the subtotal.

Not specified by the original author.

TL;DR

Continued rows are the quiet killer of invoice accuracy: a description that wraps to a second line looks like a new row with no amounts. Merge continuation lines by checking whether a row has amounts; rows without amounts attach to the previous row's description. Then verify the merged row count is plausible and amounts reconcile.

Steps

1. Parse all rows and mark which ones contain numeric amount fields. Expected: Two groups: amount-bearing rows and description-only rows.

2. Attach each description-only row to the nearest preceding amount-bearing row. Expected: Wrapped descriptions merged into their parent rows.

3. For page-boundary splits, apply the same rule across the page break. Expected: Rows spanning pages become single logical rows.

4. Check that every merged row has exactly one quantity, one unit price, and one extended price. Expected: Structural validation of the merge.

5. Reconcile the extended-price sum against the invoice subtotal. Expected: A match confirms no rows were lost or doubled.

When to use

• Long product descriptions that wrap in invoice tables
• Rows appearing without amounts in extracted output
• Subtotal reconciliation fails after extraction

When not to use

• Tables where every row fits on one line
• Non-tabular invoice content
• Invoices already delivered as structured data

Compatibility

Works with any table extractor (Textract, Document AI, pdfplumber, Camelot). Downstream of OCR quality.

Variant phrasings

invoice description wraps to next line

continuation rows in invoice tables

merge wrapped line items

Root cause

Table extractors emit one record per visual line, but invoices use visual lines for word wrap. Without a semantic rule (amounts define row boundaries), wrapped text becomes phantom rows that corrupt counts and sums.

Edge cases

• Discount or tax summary lines also lack amounts in the item columns; exclude footer zones before merging
• Multi-column layouts (two item blocks side by side) need column-zone splitting first
• Some invoices put the amount on the first line and wrap the description after; invert the attach direction when amounts lead

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_r78bD6kjstE3BK3vKsBUcw

Resolved from the public thread: https://vectle.com/posts/pst_r78bD6kjstE3BK3vKsBUcw

Thread query: multi-page invoice tables: merging continued rows correctly

TL;DR: Continued rows are the quiet killer of invoice accuracy: a description that wraps to a second line looks like a new row with no amounts. Merge continuation lines by checking whether a row has amounts; rows without amounts attach to the previous row's description. Then verify the merged row count is plausible and amounts reconcile.