How to convert a bank statement PDF to CSV or Excel (and what usually goes wrong)

Accountants, bookkeepers and anyone doing their own taxes eventually hit the same wall: the bank only offers a PDF for the months you need, and the spreadsheet you actually want is trapped inside it. Here's why that conversion is harder than it looks, and how to get it right.

First: check for a real export

Before converting anything, look for a CSV, Excel or OFX export in your online banking — usually under statements, documents or "export transactions". A native export is always more reliable than any conversion, because the bank writes the data directly. The catch: many banks limit exports to recent months, which is exactly when the PDF-only problem starts.

Why PDFs fight back

• PDFs describe positions, not tables. A PDF stores "draw this text at these coordinates" — the rows and columns you see are a visual illusion that has to be reconstructed.
• Every bank lays out statements differently — multi-line descriptions, page-spanning transactions, balance columns that appear and disappear, and date formats that vary by country.
• Copy-paste mangles columns. Pasting a statement into Excel typically collapses everything into one column, or interleaves description fragments with amounts.
• Generic OCR misreads money. A misread digit in a description is cosmetic; in an amount column it silently corrupts your books. Scanned (image) statements make this much worse.

What a good conversion pipeline does

1. Parses structured formats (CSV/Excel/OFX) exactly, no guessing.
2. Runs layout detection tuned for statement patterns on digital PDFs.
3. Falls back to AI extraction when a layout defeats the rules — then re-validates every date and amount against the document, so extraction mistakes can't slip into your totals.
4. Outputs the formats your tools import: CSV and Excel for spreadsheets, QIF for Quicken/YNAB/GnuCash, OFX for accounting packages.

That's how the StatementDecoder converter works — and there are dedicated pages for 5,000+ specific banks.

The step most converters skip

A converted statement still reads like SQ *BLUE BTTL 0412 SAN FRANCISCO. If the goal is bookkeeping, categorisation or expense review, you want each row matched to an actual merchant — which is the part we add on top: every transaction comes back with an identified merchant name, category and confidence level, plus detected subscriptions and fees. Convert once, and the understanding comes with it.

Which output format do you actually need?

• CSV — the universal default. Every spreadsheet and most accounting tools import it. Watch two gotchas on import: date columns being reinterpreted in the wrong regional format, and long card numbers being mangled into scientific notation by Excel (import as text, or use a redacted export).
• Excel (XLSX) — CSV with types preserved. Choose it when the file goes straight to a human: dates stay dates, amounts stay numbers, and nothing is reinterpreted on open.
• QIF — the import format for Quicken, YNAB and GnuCash. A good QIF puts the merchant in the payee field and keeps the original statement line in the memo, so imports arrive readable instead of cryptic.
• OFX — structured XML accepted by most accounting packages (Xero, Sage lineage, many banks' own import flows). Pick it when the destination is bookkeeping software rather than a spreadsheet.
• JSON — for scripts and developers; each transaction as a typed object.

Step-by-step: a clean conversion for bookkeeping or taxes

1. Gather the period once. Download every statement for the tax year or engagement in one sitting — banks hide older months behind extra clicks, and doing it piecemeal is how gaps happen.
2. Prefer native exports for recent months, PDFs only where that's all the bank offers. Mixing sources is fine; the formats normalise in conversion.
3. Convert and reconcile. After each conversion, check three numbers against the PDF's own summary block: opening balance, closing balance, and the debit/credit totals. If they match, every row in between is almost certainly right.
4. Deduplicate overlapping statements. Monthly PDFs often overlap by a few days. (The analyzer does this automatically when statements are uploaded to one account — identical transactions across overlapping files are counted once.)
5. Categorise from identified merchants, not raw descriptors. "SQ *BLUE BTTL" can't be categorised; "Blue Bottle Coffee — Cafes" can. This is where merchant identification turns a converted file into finished bookkeeping.

Converting many statements at once

Onboarding a client or reconstructing a year means dozens of files. Two things matter at that scale: batch upload (a zip of statements processed in one pass, available on our paid plans) and consistent output — every file emerging with the same columns, date format and merchant naming, so the year concatenates into one ledger without manual harmonising. If you need the output in a specific shape (your firm's date format, custom columns), the AI export transform applies the change and a deterministic verifier proves amounts, dates and row counts survived intact.

Safety checklist for any converter

• No bank logins — upload a file you exported yourself.
• Sensitive numbers redacted before storage.
• A stated retention window (ours: deleted after 24 hours).
• Amount totals you can reconcile against the PDF's own summary.
• A privacy page that says where files are processed and stored — if you can't find one, don't upload.

Bank-specific notes

Layouts differ enough by bank that we maintain a dedicated converter page for over 5,000 banks — including the fintechs whose PDFs are hardest on generic parsers (multi-currency Wise and Revolut statements are the classic examples, where reference IDs masquerade as descriptions). If your bank's statements defeat a converter, that page also documents where to find the bank's native export.