Why bank statement PDFs are so hard to convert
Updated 2026-08-19
A bank statement looks like a table. To the file format it is a set of characters placed at coordinates on a page, with no concept of a row, a column or a cell. Every extraction problem follows from that one fact.
There are no columns in a PDF
What you read as a column is a set of characters that happen to share a horizontal position. Nothing in the file says they belong together. Reconstructing the table means inferring structure from geometry, and that inference has to be right on every page.
Banks do not agree on layout
One bank prints a single signed amount column. Another splits paid in and paid out. A third groups transactions into five separate sections by type and prints balances only in a summary at the end. There is no standard to code against.
The five things that break
Almost every failed conversion is one of these:
- Descriptions wrapping onto a second line and becoming phantom rows
- Sections where the sign is implied by a heading rather than the number
- Balance summary grids being mistaken for transaction tables
- Dates without a year, taken from a statement period in the header
- Scanned pages where the text does not exist as text at all
Why a language model helps here
Rule-based parsers need a template per bank, which is why they fail on the long tail. Reading the document the way a person does, using headings and context to decide what a number means, generalises to layouts nobody wrote a rule for, including the small credit union nobody has ever templated.