Why generic PDF-to-Excel tools lose or merge transactions

Generic PDF-to-Excel tools are genuinely good at what they do, which is reconstructing the visual layout of a page. The problem is that a bank statement is not a visual layout; it is a ledger with rules, and the rules are invisible to a generic extractor.

What a PDF actually contains

A PDF does not store a table. It stores positioned runs of glyphs: "draw CARD PAYMENT TO at x=148, y=412". The visual table you see is an illusion assembled by your eyes. Any converter must reconstruct rows and columns from coordinates, and every failure mode below is a reconstruction error that produces a plausible-looking result.

The five classic failures

Wrapped descriptions become phantom rows

A long payee wraps onto a second line. A generic tool sees a new visual row and emits a second transaction with an empty amount, or worse, merges it into the next row's description. Statement-specific parsing knows a continuation line has no date and no amount and joins it back to its owner.

Rows vanish at page boundaries

The last transaction on a page sits close to the footer text. Table-detection heuristics clip it or discard it as furniture. Nothing warns you; the export simply has fewer rows.

Debits drift into the credit column

Money columns are right-aligned, and their exact positions shift between layout versions. A tool that infers columns per page can assign an amount to the wrong side. The sheet still sums, the totals are simply wrong in both directions.

Balance markers counted as transactions

BALANCE BROUGHT FORWARD and CARRIED FORWARD rows are markers, not money movements. Counted as transactions they wreck every total; a parser needs bank-specific rules to treat them as the balance anchors they are.

Numbers reinterpreted

1,234.56 becomes 1.23456 under a different locale, or a text string that will not sum, or loses its minus sign. Amounts must be parsed as exact decimal quantities, never floats.

Why you rarely notice

All five failures produce output that looks like a bank statement. Unless you reconcile (opening plus in minus out equals closing, and every running-balance transition), the error surfaces weeks later as a ledger that will not balance. That is the argument for converters that check their own arithmetic and refuse to call unverified output done, which is exactly how the converter here works: a result is labelled verified only when the statement's own balances prove it.

Reviewed 15 July 2026.