Bank statement PDF to CSV: what our converter gets right and wrong

The short version

• On the 275 transactions in the 9 layouts we built the converter against, 275 (100.0%) came out identical to the PDF row, empty cells included. That number is flattering: we fixed the converter until it passed those layouts.
• On 156 transactions in 6 layouts written after the converter was frozen, 156 (100.0%) were present in the output but only 134 (85.9%) sat in exactly the right columns. That is the number to trust more.
• The failure was a layout whose column headings use none of the words the converter looks for (Date, Description, Debit, Credit, Amount, Balance and their equivalents in a few languages). It says so in a warning instead of pretending.
• A scanned (image-only) PDF is refused with a clear message. There is no OCR in this tool.

How we tested

A script generates each statement as a PDF with a real text layer: a fictional bank, a fictional account holder, made-up merchants, amounts and dates from a seeded random generator. For every statement the script also writes the exact rows it drew, including the empty cells, as ground truth. We then convert each PDF with the same code that runs on this site and compare:

• Found: one output row contains the transaction's date, the start of its description and all of its amounts (lenient about which column).
• Exact: an output row equals the printed row cell for cell. A credit under the Debit heading is a miss.
• Extra rows: output rows that match no transaction (totals, footers, other tables).

The layouts are generic shapes (column order, wrapping, sections, number formats), not copies of any bank's template. We have not tested any named bank, so we do not list supported banks.

Results per layout

Try a layout

Eight of these layouts have their own page with a synthetic sample PDF to download and convert:

• Separate Debit and Credit columns
• One signed Amount column
• Credit card statement with transaction and posting date
• Multi-page statement with repeated headings
• European dates and decimal commas (EUR)
• Opening balance, closing balance and total rows
• Dates without a year, currency symbols, CR credits
• Seven columns with value date and reference

What we learned

1. Empty cells are where converters go wrong. On a statement with separate Debit and Credit columns, a row only has one of the two. A converter that keeps just the non-empty cells shifts everything after the gap one column to the left, so deposits show up as withdrawals. The first version of this tool did that, and it also cut every row to the width of the first multi-column line on the page. Run on the same 9 layouts, it returned 199 of 275 transactions with their text intact. For three layouts (two with Debit/Credit columns and one with a card summary above the table) it kept only the first three columns, so no transaction came out complete. We found this by testing, not from a user report, and rebuilt the extraction around column positions taken from the heading row.
2. The heading row is the single point of failure. Once the heading row is found, columns line up even when headings are centred over right-aligned numbers, split over two lines or written in Vietnamese. When it is not found, the best a converter can do is reading order, and the tool says that.
3. Not every line under the table is a transaction. Opening balance, closing balance, totals, page footers and a second table of daily balances all sit near the transactions. The tool keeps rows that carry a date, joins a wrapped description line to the row above it, and reports what it left out so you can see it.
4. Numbers and dates are copied, not interpreted. 1.234,56 stays 1.234,56 and 02 Mar stays 02 Mar (the PDF has no year). Excel may read a column differently depending on its regional settings.
5. Pictures of statements are a different problem. If the PDF is a scan there is no text to extract. This tool does not do OCR and refuses such files.

Limits of this test

• Every PDF was produced by one generator with clean text. Real bank PDFs have quirks we did not simulate.
• The 9 "built against" layouts were used to tune the converter, so their score says little about new layouts.
• The 6 held-out layouts were also written by us, so they only approximate what we would not think of.
• No real statement, customer file or named bank was used.

How to check any converted CSV in a minute

1. Compare the number of rows with the number of transactions in the PDF (page by page for long statements).
2. Add up the debit and credit columns and compare them with the totals your statement prints.
3. Check that the first and last rows and the closing balance match the original.
4. Look at the warning under the result: lines the tool left out are listed there.