Bank statement parser
A parser turns a statement into fields a program can use: a date, a description, an amount, one set per transaction. Upload a file and take the result as JSON or CSV.
Upload a file
What the parser returns
- One record per transaction, in statement order
- Fields separated: date, description, amount, and balance where present
- JSON for code, or CSV and Excel for a spreadsheet
- No page-coordinate assumptions, so wrapped lines stay whole
What the JSON file looks like
Parsed output as JSON: a currency, a transaction count to check against the statement, and one object per transaction with date, description, a signed amount and the running balance where the statement prints one. Dates are ISO 8601, so any language parses them without a format string.
{
"currency": "USD",
"transactionCount": 3,
"transactions": [
{
"date": "2026-03-02",
"description": "Direct Debit 4471 Acme Insurance",
"amount": -120,
"balance": 1880
},
{
"date": "2026-03-04",
"description": "Card Payment Corner Grocer",
"amount": -38.4,
"balance": 1841.6
},
{
"date": "2026-03-06",
"description": "Transfer Received J Smith",
"amount": 500,
"balance": 2341.6
}
]
}How to convert
Upload the statement
A PDF straight from the bank, or a scan.
Choose JSON or CSV
JSON if the next step is code, CSV if a human will read it.
Use the records
Import them, or feed them straight into your own pipeline.
Statements it handles
Layouts differ from bank to bank, so nothing is matched against a fixed template. An unusual statement still produces a table you can check before exporting — which is what makes it usable for bookkeepers and accountants who receive statements from every client.
PDF statements and CSV exports
A statement downloaded from your bank, or the CSV your bank lets you export. Both arrive as the same clean table.
Multi-page statements, read as one table
A statement that runs over several pages — or several statements uploaded together — is read as one continuous table, not one file per page.
Amounts and dates kept as your bank prints them
Debit and credit signs, decimal places and date formats are left as printed, so the numbers still reconcile against the statement.
Scanned, image-only PDFs, read with OCR
A statement with no text layer is read with OCR and may need a quick review — the one case where a row can come out wrong.
- CSV
- Scan
Why this is more accurate than OCR
OCR reads a statement by position on the page, so a wrapped description or a pair of narrow amount columns sends the text to the wrong row. Reading the content instead of the coordinates is what keeps each transaction whole.
01
A wrapped description becomes two rows
The second line of a description sits below the first, so it is read as a new row — and the amount follows it down, onto the wrong transaction.
02
Debit and credit collapse into one column
Two narrow amount columns are read as one, so a payment and a deposit come out identical — the sign that told them apart is gone.
03
The totals block becomes transactions
Opening balance and closing balance are printed like rows, so they are read like rows — and land in your books as money that never moved.
Why OCR mangles bank statements — the four failures in detail.
Frequently asked questions
What is a bank statement parser?
Software that turns the printed transactions of a statement into structured records — the date, description, and amount of each line as separate fields.
Can I convert a bank statement to JSON?
Yes — JSON is preselected on this page. Upload the PDF and download one object per transaction, shaped like the sample above.
Is there an API?
Not yet. Today the parser is the converter on this site; JSON output is the machine-readable form of it.
Which output formats are available?
JSON for developers, plus CSV, Excel, QIF, OFX, QBO, Tally XML, and MT940 for the tools those belong to.
Is my file kept?
Only until it is converted, or 24 hours if it is never paid for. The result stays at your private link.
Do I need an account?
No. It works without signing up.