Multi-page bank statement PDFs: where table extraction breaks, and how to check it

Published 17 October 2026 · by Tekiba

Why the page is the weak point

A PDF does not contain a table. It contains pieces of text, each placed at a position on a page. A converter rebuilds rows from what sits on the same line and columns from what sits under the same heading. Within a page that works well. Across a page break the layout restarts — new heading, new margin, sometimes a summary line — and the converter has to decide what carries over. Each of the five problems below starts there.

Fictional statement, made up for this page; not any bank's layout.

1. A row split by the page break

Long descriptions wrap onto a second line, and sometimes the break falls between them. In the example, REF 88213 MONTHLY at the top of page 2 is the end of the savings transfer on page 1 — but nothing on page 2 comes before it.

LedgerDrop attaches a wrapped line to a row using the setting under “Columns and date format” (the row above, the row below, or whichever is closer). A line at the very top of a page has no row above it on that page, so it goes to the row below: here, to the Acme payment. That is a guess, and LedgerDrop Pro's reconciliation report lists such rows as one of the places to look. The amounts are not affected; the description is.

Check: the first description on each page. If it starts with a fragment that belongs to the row before, move the text by hand in the CSV.

2. Forward balances read as transactions

Many statements close each page with a “carried forward” balance and open the next with a “brought forward” one. Those lines carry a figure, and to a converter a line with a figure looks like a row. If one is taken as a transaction, the total is out by that figure.

LedgerDrop drops lines it recognises as balance or total lines — opening, closing, “balance forward”, “carried forward”, totals and similar. On the tested layouts the brought-forward line has no date and gives no row either. A forward line worded differently, or printed with a date, may still come through.

Check: search the table for “forward”, “B/F”, “C/F” and “total”, and look each hit up in the PDF. Only delete a row the statement shows to be a carried balance or a subtotal: a payment to a shop with “Total” in its name is a real transaction, and LedgerDrop keeps such rows on purpose.

3. The heading repeated on every page

The bank's name, the account number, “Page 2 of 3” and the column headings are printed again on each page, and they land in the middle of the table. LedgerDrop drops a line that repeats in the same place on at least 60% of the pages. A line that starts with a date and has an amount is never dropped that way, so two real payments that happen to sit at the same height on different pages are both kept.

The rule can miss a heading that moves between pages, or a statement too short for anything to repeat often. A stray heading row is easy to see and easy to delete; a missing transaction is not, which is why the rule leans that way.

Check: rows with no date and no amount, or with words like “Page” or the account number in them.

4. A year that changes partway through

Statements that print Mar 28 or 12/29 without a year leave the converter to supply it, usually from the statement period at the top of page 1. A December–January statement changes year somewhere in the middle, often on a later page. Why your converted bank CSV shows the wrong year explains where LedgerDrop gets the year and how to set the period by hand when it is wrong.

Check: the first January row, and the last December one.

5. An amount in the wrong column

Figures are right-aligned under their headings, so a long one such as 12,480.00 reaches left, sometimes far enough to sit more under the neighbouring heading than its own. A converter that places it by overlap can put a deposit under Withdrawals, which turns it from money in to money out. LedgerDrop places an amount by where its right edge lines up, and only falls back to overlap when nothing lines up.

Check: the largest amounts on each page, and their direction against the PDF.

How to check a long statement in the browser

1. Read the balance check first. Convert the statement in LedgerDrop. The panel above the rows says whether the opening balance plus every row reaches the closing balance, and shows the Difference if not. This part is free at any length.
2. Use the Difference as a lead. It is a single net figure, so it cannot say what went wrong, only where to look first. Equal to one amount: that row may be missing, or a row of the opposite direction may be in twice. Twice an amount: that row may have the wrong sign, since a sign error moves the total by double — or two smaller errors may add up to it. Equal to a balance on the statement: a forward or summary line may have been read as a transaction. Confirm against the PDF before changing anything.
3. Read the page joins. For each break, compare the last row before it and the first row after it with the PDF: date, description, amount, direction.
4. Fix what is wrong. Date order, signs, where wrapped lines go and the statement period are under “Columns and date format”; each change re-reads the PDF in the tab. Anything left is a hand fix in the CSV; clean up a bank statement CSV before you import it covers the spreadsheet side.
5. Check again. A net total can match with two errors that cancel, so a match is strong evidence, not proof. How to check a converted bank statement CSV for errors covers what it misses.

The statement stays on your computer throughout: LedgerDrop reads the PDF in the browser and does not upload it.

What this page cannot tell you

How your bank lays out its pages. The behaviour above is tested on the layouts listed on the formats page; a statement from another bank may break in a way not described here. Scanned statements are a different problem — there is no text to read at all; see is my bank statement PDF scanned or text?

Questions