PDF bank statements to CSV

For bank and card statements, not every PDF

Use complete checking, savings or credit card statements with their transaction pages. The converter reads text-based PDFs and uses OCR for scanned pages when OCR is available. You review the extracted rows beside their source in the PDF before choosing an export.

This is not a general PDF-to-table converter. Receipts, invoices, mortgage documents and brokerage reports are outside this page's scope. Accounting-software reports, statement guides and check images are not substitutes for transaction pages. A summary-only PDF cannot supply the missing transactions.

Check the date interpretation, account and currency in the review. A balance can add up even when a date or description was read incorrectly. No bank or layout is guaranteed to convert.

A fictional statement, exported for real

This is the made-up Northwind Bank checking statement used in our homepage demo. Every name, account detail and transaction is fictional. We constructed statement data from these rows and ran the real CSV and Excel exporters locally, without uploading a file. This tests export layout, not extraction from a PDF or OCR accuracy.

The opening balance is USD 4182.37; the printed closing balance is USD 5960.14. Positive amounts are money in; negative amounts are money out. The running balances below were supplied as fictional printed balances and checked with exact decimal arithmetic.

The signed amounts sum to 1777.77. Opening 4182.37 + net 1777.77 = closing 5960.14. Both the totals and the supplied running balances agree.

What is in the generic CSV

This is the generic preset with the default signed Amount column and ISO dates. It is a flat transaction table, not a workbook with account tabs. Every column is listed below, in export order, beside the first row read back from the generated CSV.

The exporter writes UTF-8 with a byte-order mark, quotes CSV fields when needed, and writes amounts as plain decimal text. There are no cell types or workbook formatting in a CSV, so check how your spreadsheet reads the dates and numbers.

Blank cells are empty in the file, not the text “(blank)”. Type and Category are suggestions, not approved bookkeeping entries. These columns appear when rows have classifications; Card and Cardholder columns appear when the input includes those details. They are absent from this checking-account sample.

Source File, Page, Line and Transaction ID survive in both formats, along with Statement, Account and Currency. The sample's page and line positions were constructed, not extracted. In a real export, Line is the transaction's position among transactions on that source page, not the line number of every piece of PDF text. Rows added manually can have blank source positions. These are reference columns, not a PDF viewer embedded in your download.

Statement Status repeats the statement's arithmetic result on each row. It does not certify that row's description or category. Generic CSV does not carry opening and closing summary tables, balance-break details or workbook analysis sheets. Excel retains those in separate sheets and can put transactions on a sheet per account; its transaction rows use Notes instead of Statement Status.

What a mismatch looks like

Keep the same fictional statement, but misread Bluebird Grocers as -132.68 instead of -142.68. The net becomes 1787.77, so opening 4182.37 + net 1787.77 = 5970.14, not the printed closing 5960.14. The difference, printed closing minus computed closing, is -10.00.

The reconciliation code flags this changed input as a mismatch. At that transaction, the expected running balance is 5624.69, but the printed balance is 5614.69. Inspect the source row rather than changing a figure just to make the total agree. Without printed running balances, an overall difference alone cannot identify the faulty row.

Missing opening or closing balances can leave a statement unverifiable rather than reconciled. Even a reconciled result is only a statement-arithmetic check: offsetting errors can leave totals unchanged. It does not authenticate the PDF, match your books or decide how a transaction should be categorized.

Choose an import layout deliberately

Generic CSV keeps review detail. A destination-specific CSV preset is a different, narrower layout and can omit source, account, currency and status columns. Keep the detailed export for review, then choose the layout your destination actually asks for. A CSV download does not connect to an accounting application.

Neither format promises successful import into any particular app, edition or region. Check the receiving app's current requirements and review its preview before accepting rows. Importing transactions is not the same as matching them against entries already in your books.

Scanned PDFs depend on readable images and available OCR. Faint, cropped or missing rows still need review; conversion can fail or leave pages unread. Text-based PDFs can also have a faulty text layer. The scanned versus text PDF guide explains the difference. No scan or PDF extraction was tested for this sample.

Already have a CSV? The free statement balance checker can compare its amounts with the balances you enter, without a conversion upload. The statement review guide covers the checks that arithmetic alone misses.

What we checked: on October 17, 2026, we ran the repository's real CSV and XLSX exporters on this synthetic statement, read both outputs back, and recomputed the amounts, running balances and mismatch with Python Decimal. We checked the documented scope and exporter source. We did not upload a PDF, run OCR, open desktop Excel or test an import into a bookkeeping app.