Bank statement PDF to CSV converter that checks every balance

Why the balance check matters

A bank statement carries its own answer key. Most statements print a running balance after each transaction, or at least an opening and a closing balance. If the extracted amounts are right, they must add up: the previous balance plus this row's amount equals this row's balance, to the cent.

Most converters skip this check and leave you to find a dropped row or a misread 8 that was really a 3. This tool runs the check on every row and tells you the result:

• "All 143 rows reconcile." Every row with a printed balance matched the running total, and the opening and closing balances tie out.
• "3 rows need review." Those rows are highlighted and show the expected and printed balances. Compare them with the PDF.
• No balances to check against. Some statements print neither a running balance nor an opening and closing balance. The tool says so instead of implying the data was verified.

A few failure patterns are recognized. If a printed balance is misread but the next row agrees with the running total, the misread balance is the likely cause, and the note on that row says so. When a statement prints the balance only at the end of each day, the day's rows are checked as a group. "Total deposits" and "Total withdrawals" lines, when printed, are compared with the extracted rows.

How the extraction works

1. Text, not pixels. pdf.js, Mozilla's PDF engine, reads the text layer of each page: every piece of text and its position. Nothing is uploaded; pdf.js is fetched once from a public CDN and runs on your device.
2. Lines. Text at the same height becomes a line. Pieces of text close together become one cell, so a description split into separate words is put back together.
3. The transaction table. A transaction row starts with a date (01/05, 01/05/2026, Jan 5, 5 Jan 2026 and similar) and ends with one or more amounts. The table is the dense run of those rows. A stray dated line elsewhere on the page doesn't count, and neither do page headers, footers or "continued" lines.
4. Columns. Amounts are right-aligned, so their right edges line up into columns. When the statement has a header row ("Withdrawals", "Deposits", "Balance"), the header names the columns. When it doesn't, the tool tries each plausible reading (one signed amount column, separate debit and credit columns, amount plus balance, newest-first order) and keeps the one that reconciles.
5. Wrapped descriptions. Lines indented under a description with no date and no amount are joined to the transaction above.
6. Dates without years. Many statements print 01/05 or Jan 5. The year comes from the statement period, and a December row on a January statement goes into the previous year.
7. Signs. Separate debit and credit columns set the sign. On a single amount column, a minus sign, parentheses, a trailing minus, or a CR/DR suffix sets it. If the amounts carry no sign at all, the change in the running balance decides it.

What it cannot do

• Scanned or photographed statements. These are images with no text to read. The tool detects this and says so, including when only some pages are images. Extracting them needs OCR, which is a different and much harder problem.
• Password-protected PDFs open only once you enter the password. It is used locally to open the file.

• Layouts that still fail. Measured on published sample statements in October 2026 (see below):

  • Two columns of statement printed side by side on one page are read as one line.
  • Rows that print the date after the description are missed.
  • Amounts printed without cents ("5,000") are not read.
  • A description printed on the line above its date, as in some loan sections, is not attached to the row.
  • Charges listed without a date, such as interest on some card statements, do not become rows. The balance check reports the difference.
  • A loan payment printed over two lines, principal on one and interest on the next, is read, but its balance is flagged for review.
  • In annotated guides, callout text printed inside the table can end up in descriptions. Brochures that stack several statement images on top of each other cannot be read.

  The balance check catches most of these as rows or totals to review, but not all. A printed line that holds two transactions becomes one row, and without a running balance the totals still add up. With no balances printed, nothing can be verified. - Credit card statements are signed as the change in what you owe: purchases, fees and interest are positive; payments and credits are negative, including amounts marked "CR". That is the reverse of a bank account, so you may want "Flip signs" before importing the rows into an accounting system. - Header words are matched in English. On statements in other languages, dates and amounts still work and column roles are inferred from the numbers. - Very long statements are fine. Everything runs in memory in your browser, so a few hundred pages is practical on a laptop.

How accurate is it? We tested it on 17 sample statements that banks, credit unions, government agencies and educators publish to teach people how to read one (measured 7 October 2026, default settings). All rows reconciled on 3. Rows or totals needed review on 9, six of them because the sample's own figures disagree. Two had nothing printed to check the rows against. Three gave no rows: one has no transaction list, one is an image-only statement, and one prints its amounts without cents. On five of the samples we typed every transaction by hand: the converter got all 137 rows right. Those five were also used to fix the converter, so that score checks the fixes. It is not a general accuracy rate. These are teaching documents, not statements as your bank sends them, and the side-by-side comparison with other converters is still to come. The methodology page has the sample list, the method and the result for each sample. For your own statement, the reconciliation check is still the honest answer.

When a paid tool is worth it

• Scanned statements. You need OCR plus the same balance checks. DocuClipper is built for bank statements, including scans, and exports to CSV, Excel and QBO. Whatever you use, verify its output: take the CSV it produces and check that opening balance plus rows equals closing balance.
• The same document layout every week. For recurring documents like invoices, purchase orders or one bank's statements at volume, a rules-based parser such as Docparser lets you define the layout once and run it automatically. The setup only pays off if the volume is there.
• Everything else. Use the free tool, read the reconciliation result, and only pay when the reconciliation keeps failing on your bank's layout or the PDFs are scans.

Also available as Markdown.