PDF.js reads every text fragment with its position, fragments on the same line are grouped, and any line with a valid date and a currency amount becomes a transaction: Date, Description, Amount. Dates are normalised to year-month-day where the format is unambiguous; amounts are signed, debits negative.
The running balance column is deliberately not extracted, because banks put it in different places and a wrong balance silently corrupts totals. Lines the parser cannot read confidently are skipped, never guessed. Scans need OCR first.
Twelve months of statements for an accountant. A year of card transactions to categorise. A lender who wants the last six months as a spreadsheet. Retyping is slow and error-prone, and the online converters that promise to help want the statement uploaded first, which is the exact document identity fraud is built from. The tool above does the reading locally and hands back a CSV that QuickBooks, Xero, Wave, YNAB and every spreadsheet accept.
How to convert a statement to CSV
Use the bank's own PDF
Statements downloaded from online banking have a text layer and parse cleanly. A photo or a scan of a paper statement is an image and needs OCR first.
Add the PDF
Drop it or browse. It is read into browser memory; account numbers and balances never leave the device.
Press Extract transactions
Lines are grouped from text positions, transactions are recognised by a date and an amount, and the rows appear in a preview table.
Check the preview and download the CSV
Compare the row count and a few amounts against the statement, then download. Import into your accounting tool or open in a spreadsheet.
Date, Description, Amount. Nothing inferred that a bank does not print.
Currency symbols and thousands separators stripped so spreadsheets read numbers.
The single most sensitive document most people own stays on their machine.
How the parser reads a line
A statement page is a grid of positioned text, and the parser rebuilds it in two passes. First, fragments that share a vertical position are joined into lines. Second, each line is tested for the shape of a transaction: a recognisable date somewhere near the start and a currency amount somewhere near the end. Everything between them is the description, kept exactly as printed, reference numbers and all.
- Date, in the bank's formatNormalised to YYYY-MM-DD
- Everything between date and amountDescription, as printed
- The transaction amountSigned decimal, symbols stripped
- The running balanceIgnored on purpose
- Headers, totals, address blocksSkipped: no date and amount together
Which statements work
The parser is generic. It does not know one bank from another; it looks for the date-description-amount shape on each line, which covers text-based statements from almost every bank and card issuer.
Text-based statements with one transaction per line
- Downloaded PDFs from online banking and card portals
- US, UK, Canadian, Australian and EU banks and neobanks
- Credit card statements with a signed amount per line
- Business accounts with reference codes in the description
- Multi-page statements; page breaks are handled
Anything without a readable text layer
- Scans and phone photos of paper statements: OCR first
- Statements where a transaction wraps onto two lines: check the preview
- Password-protected PDFs from some banks: unlock first
- Ambiguous dates like 03/04 with no year hint: verify the month order
- Interest and fee summaries printed without a date
Where a bank formats a date ambiguously, the parser prefers the order it can prove from the rest of the statement and otherwise leaves the date as printed rather than guess. A quick sort of the Date column in your spreadsheet shows immediately if a month and day were swapped.
Three checks before you import
- Row count. The preview reports how many rows were detected. Count the transactions on one page of the statement and compare. A shortfall usually means a wrapped description or a date format the parser did not trust.
- Sum of the Amount column. It should equal the closing balance minus the opening balance for the period. A mismatch points at a specific row: the difference is the amount of the line that was missed or mis-signed.
- First and last rows. The opening and closing lines of a statement are where headers and totals sit closest to real transactions. Confirm neither a total nor a brought-forward line slipped in.
Importing the CSV
- Accounting software. QuickBooks, Xero, Wave and YNAB all import CSV and will ask which column is the date, the description and the amount the first time.
- Spreadsheets. Open directly. A pivot table by month or by merchant takes a minute once the amounts are numbers, which they are.
- Reconciliation. Match card lines against an invoice log or an expense system to find the payment that never arrived.
- Lenders and accountants. Send the CSV alongside the statement PDF; the PDF is the evidence, the CSV is the convenience.
Why this one must never be uploaded
A statement contains the account number, the running balance, every merchant visited and every salary received. It is the document a fraudster most wants and the one a converter's server most casually stores. There is no format-conversion benefit worth that exposure, and there does not have to be, because the parsing runs in a browser tab.
The tool is right above
Everything on this page runs in your browser. Scroll up, drop the file, and keep it on your machine.
Common questions
What people ask with a statement in the preview.
01Which banks are supported?
The parser is generic: it looks for a date, a description and an amount on each line, which covers text-based statements from most banks and card issuers in the US, UK, Canada, Australia and the EU, as well as neobanks. It does not need to know the bank.
02Does it work on scanned statements?
No. A scan has no text layer, so there is nothing to parse. Run it through OCR first, check the text reads correctly, then convert the OCR'd PDF.
03What columns does the CSV have?
Date, Description, Debit, Credit and Balance. Money out and money in keep their own columns, and amounts arrive with currency symbols and thousands separators removed so spreadsheets read them as numbers.
04What is the balance check?
The running balance is read into its own column, then every step is added up: each balance should equal the one before it plus the money in and minus the money out. When a step does not add up the result line says how many, which is usually a line the parser missed. The opening balance row is kept for the same reason, because the first transaction has nothing to check against without it.
05A few transactions are missing. Why?
Usually a description that wrapped onto a second line, or a date the parser could not read with confidence. Rows it cannot parse confidently are skipped rather than guessed. The sum-of-amounts check finds exactly which lines to add by hand.
06Can I import the CSV into accounting software?
Yes. QuickBooks, Xero, Wave, YNAB and every spreadsheet accept standard CSV. Most will ask you to map the three columns on first import.
07Is my financial data safe?
The whole conversion runs in your browser. The statement is read in memory and never sent anywhere. There is no server-side copy to leak.
08Is it free?
Free. Every tool, unlimited use, no signup.