The problem isn't malice, it's structure
Free PDF-to-CSV tools aren't trying to ruin your books. Most of them are generic table extractors: built to pull a grid out of any PDF — an invoice, a research paper, a price list — and to them a bank statement is just another grid.
But a bank statement isn't a grid. It's a formatted financial document with wrapped text, running balances, summary sections, and repeating page furniture. When a generic extractor meets that structure, it fails in predictable ways. Here are the six failure modes we see most, what each looks like, and what it costs you.
1. Multi-line descriptions split into fake rows
What it looks like: Your CSV has a row for "AMAZON MKTPLACE PMTS" followed by a row with no date and no amount that says "AMZN.COM/BILL WA" — or worse, the second line got its own row with a date guessed from a neighboring line.
Why it happens: Statements wrap long descriptions onto a second printed line. A line-based extractor treats every printed line as its own record.
What it costs: Inflated transaction counts, mangled payee names your bank rules can't match, and an afternoon of merging rows by hand.
2. Debit and credit columns merged with wrong signs
What it looks like: Everything imports as money in, or everything as money out. A $4,000 rent payment posts as a deposit.
Why it happens: Statements print two columns — withdrawals and deposits — and the direction is carried by which column the number sits in. An extractor that flattens both into one "amount" column has to infer the sign, and the usual heuristic (first column is negative) breaks the moment a statement prints deposits first.
What it costs: The worst of the six, because the file can look fine. Your books are wrong in a way that only surfaces when the reconciliation won't tie out — and now you're auditing every transaction instead of three.
3. Page headers and footers imported as transactions
What it looks like: Rows containing "Page 3 of 12," "Member FDIC," the bank's customer service number, or "continued on next page" — sometimes with a stray number from the header parsed as an amount.
Why it happens: The extractor scans the full page, and page furniture repeats at the same position and font size as real content. Nothing tells a generic tool to ignore it.
What it costs: Junk rows to filter out, plus phantom amounts that throw off your totals if any slip through.
4. Balance and summary rows extracted as transactions
What it looks like: A $12,483.22 "transaction" that is actually your ending balance. Or rows reading "Total deposits: $48,220.11."
Why it happens: Running-balance columns and summary totals are numbers in the same font as transaction amounts. Context is the only thing that says "not a transaction," and context is what generic extractors don't model.
What it costs: One summary row parsed as a transaction can exceed every real transaction on the page. Import it and you're booking fake revenue or fake expenses.
5. Multi-account PDFs mashed into one sheet
What it looks like: A single CSV with checking, savings, and money market activity interleaved, the running balance lurching between unrelated figures.
Why it happens: Banks bundle several accounts into one PDF package. A generic extractor doesn't notice the document switched accounts on page 9 — same fonts, same layout, same logo.
What it costs: Transactions posted to the wrong account, which means two or three reconciliations that won't tie instead of one. Sorting it out means re-splitting by hand against the PDF.
6. Silent errors — no balance check anywhere
What it looks like: Nothing. That's the point. The CSV imports, the row count looks plausible, everything seems fine.
Why it happens: Failure modes 1 through 5 can each drop, duplicate, or mis-sign a transaction by a few dollars. Generic tools have no idea what the statement says the totals should be, so they can't warn you — the file ships with whatever the extraction happened to produce.
What it costs: The error survives into your books and waits for the bank reconciliation — the worst possible place to find it, because by then you're hunting one $217.40 discrepancy across hundreds of transactions.
The check that catches all six
Every bank statement prints the equation your export must satisfy:
Opening balance + total deposits − total withdrawals = closing balance
Recompute that from the extracted transactions. If it ties to the penny, none of the six failures got through. If it doesn't, you know immediately — and you know which statement, and which account, to fix. This is the entire idea behind ReconCSV: the converter reconciles every statement against its own printed balances and tells you when the numbers don't add up, instead of handing you a plausible-looking file and wishing you luck.
A two-minute audit for any converter
Before trusting any tool with a full year of statements, run one statement through it and check:
- Row count vs. a manual count of the PDF's transaction lines.
- Five spot-checked amounts, including at least one debit and one credit.
- A text search of the CSV for header and footer strings ("Page", "FDIC", phone numbers).
- Multi-account PDFs: did you get one file per account?
- The balance equation, recomputed from the output.
Two minutes here beats two hours in January.