Bank Statement PDF to JSON: A Guide for Developers

Getting structured JSON out of bank statement PDFs — the schema that works, the edge cases that break naive parsers, and how to validate the result.

If you're building anything that ingests bank statements — a lending product, an accounting integration, a personal finance app — you want JSON, not a spreadsheet. Here's what a workable schema looks like and where the hard parts are.

A schema that survives contact with real statements

The instinct is to model a transaction as date, description and amount. That falls apart quickly. You need separate debit and credit fields, because a signed amount loses information about how the bank itself classified the row — and reconciliation depends on that classification.

date — ISO 8601. Never pass through the bank's format; DD/MM vs MM/DD ambiguity is the single most common source of silent corruption
description — cleaned of padding, with the original preserved if you need an audit trail
debit and credit — separate nullable numbers, not one signed field
balance — nullable, because some banks only print it on some rows
reference — kept separate so long numbers never get parsed as amounts
account — needed whenever one PDF covers several accounts

The edge cases that break naive parsers

Continuation lines

A long description wraps onto a second visual line with no date and no amount. Emit it as its own transaction and your record count is wrong. The rule that works: no date means it belongs to the row above.

Reference numbers that look like amounts

A 12-digit reference has no decimal point and no separators. Any amount parser will happily accept it as 512,345,678,901. Rejecting numbers of 10+ digits with no decimal separator eliminates this entire class of bug.

Decimal commas

Much of Europe writes 1.234,56 where others write 1,234.56. Strip the comma as a thousands separator and 960,00 becomes 96000 — a 100x error that looks completely plausible. The reliable disambiguation is to test both interpretations against the printed closing balance and keep the one that reconciles.

Summary rows

"Total withdrawals", "Closing balance", "Statement summary" — these carry amounts and sit in the transaction columns. They're verification data, not transactions, and they must be excluded from the list and used for checking instead.

What this site's JSON gives you

The PDF to JSON converter does not force a statement into the schema above. It returns the table as printed: `columns` holds the bank's own headings, `rows` every cell exactly as printed, `records` the same rows keyed by those headings whenever every heading is usable as a key, and `review` the result of the checks — whether every row agreed with the running balance the bank printed, and which rows did not.

Dates and amounts arrive as the bank's text. Normalising them is left to your code, where you can apply the rules above — and `review` tells you which rows to trust before you do.

Validate, don't trust

The single most valuable thing you can build into an ingestion pipeline is a reconciliation check: sum your parsed debits and credits, walk the balance chain, and compare against the totals printed on the statement. Reject or flag anything that doesn't tie out.

Without it, a parser failure looks identical to a quiet month. With it, you know.

Frequently asked questions

Is there an API?

Yes, on the paid plans: a REST API authenticated with an API key, which takes a statement PDF and returns Excel, CSV or JSON, charged by the page like the site. It is documented on the API page. For a one-off file, the PDF to JSON converter needs no key.

How are multi-account statements represented?

As printed. The JSON keeps the bank's own columns and adds no account field, but the rows stay in printed order, so each account's rows are contiguous and can be split where its section starts.

Convert a statement now

Bank Statement PDF to JSON, or see every format. More in the guides.