Repeated PDF headers in bank exports: remove them without losing rows

Remove confirmed headings and footers from the transaction view, while keeping their source positions in a separate log. Do not filter on a word such as ‘date’ or ‘total’ alone: genuine descriptions can contain those words.

Classify source rows before filtering

1. Identify the full repeated pattern and its page position. Compare several pages instead of assuming every page uses the same heading.

2. Assign row types before filtering. A heading usually has column labels rather than a coherent transaction, but check the PDF to confirm.

3. Filter only reviewed non-transaction types. Compare the retained first and last payment on every page with the source.

Fictional example

A fictional repeated row says Date | Description | Debit | Credit, with no amount. It is a heading. A payment description TOTAL OFFICE, debit 18.40, is a real transaction and stays. Deleting every row containing ‘TOTAL’ would lose it.

Build an exclusion rule you can inspect

As a proposed review method, add source page, original row number, row type and reason before hiding anything. Use separate types for confirmed header, confirmed footer, transaction, continuation, balance checkpoint and unresolved. For a candidate header, check the complete set of column labels and its position against the PDF. Repetition supports the decision but does not establish it: a real recurring payment can also repeat. A line with no date is not automatically a footer, and a numeric page number is not automatically an amount.

Filter by the reviewed type. For a small sheet, a filter on the type column is enough; copy the excluded rows into the log with their source positions. Filter on the reviewed row type; the condition selects rows but cannot establish their meaning. Keep unresolved lines visible in a review view instead of letting a condition such as “has a date” discard them.

Extend the fictional example to six physical source rows: one confirmed heading, three transactions, one description continuation and one confirmed footer. Excluding heading and footer leaves four physical rows representing three transactions. The continuation still belongs to its payment; it is not a fourth payment and is not discarded merely because it lacks a date. If the three debits are 18.40, 12.00 and 4.00, they total 34.40 before and after the layout exclusions.

Check the excluded set itself, not only the clean result. It should contain the two documented layout rows, no TOTAL OFFICE payment and no balance checkpoint whose amount is needed for a separate check.

Decide what each physical row contributes

Use the following classification on the six-row fictional EUR page. The decision follows a visual check of that page; it is not a rule based on the text alone.

Source row	What the PDF shows	Treatment in the working table
1	Date / Description / Debit / Credit labels	Confirmed header; exclude from transactions, retain in log
2	TOTAL OFFICE, debit 18.40	Transaction; keep its date and amount
3	First part of a description, debit 12.00	Transaction start; keep
4	Remaining reference for row 3, no new amount	Continuation; attach to row 3 with its source position
5	Another payment, debit 4.00	Transaction; keep
6	Page 2 of 5, outside the transaction area	Confirmed footer; retain only in the layout log

Do this classification before filling blank dates down. Otherwise a copied date can make the footer look like a payment. Equally, join row 4 only after confirming that it continues row 3: physical proximity alone is insufficient when the page contains two account sections.

Recheck the rule when the page layout changes

Keep a raw view, an annotated view and a filtered view. In the annotated view record the complete matched pattern, page and decision; a new label or unexpected amount goes back to review. Do not reuse a rule merely because last month’s PDF came from the same bank.

Combining similar page tables can hide boundaries; compare the last and first transaction on each page explicitly. A combined preview therefore does not remove the need to compare page boundaries. On the fictional page, verify the count equation: six physical rows = two layout rows + three transaction starts + one continuation. After joining the continuation, there should be three transactions and debits of 34.40 EUR. If the count fails while the sum matches, inspect merged or lost descriptions; if the sum fails, reopen the exclusions and the first/last retained amounts. Restore an uncertain row to the review view instead of extending the filter to make the totals fit.

Checks and limits

Record how many headings and footers were excluded on each page. An extra heading may indicate another account section requiring separate mapping. A missing expected footer is a clue, not proof of a missing page. Keep balance-report lines distinct from text headings so they can still support checks.

Keep the original file unchanged and record any unresolved item before using the table.

Related checks

Separate headings and carried balances from transactions at page boundaries. Carried-forward bank balances: keep them out of transaction rows · Bank statement columns shift at a page break: check the boundary · Diagnose a bank PDF before choosing a table extraction tool.

BankStatementScan is in preparation. The site offers an access request and a fictional example; it does not currently convert your bank files. See the planned service.

Sources checked on 16 October 2026

• W3C — Running headers and footers in PDF.
• W3C — Model for Tabular Data and Metadata on the Web.