Which banks are supported?

There is no fixed list. Because Docyield reads the document rather than matching a template, it works across banks, countries, and statement layouts, including ones it has not seen before.

Does it work on scanned statements?

Yes. Scanned and photographed statements are run through OCR before extraction. A clear, straight scan gives the most accurate transaction list.

Will it capture every transaction across multiple pages?

Yes. Multi-page statements are handled as one document, so transactions that continue onto later pages are kept in order in the output.

How are debits and credits handled?

Each transaction returns a signed amount — negative for debits (money out) and positive for credits (money in) — so you can sum the column directly. The running balance is captured alongside it.

How do I know the data is correct?

The opening balance plus the transactions should equal the closing balance, and each running balance should follow from the last. Docyield uses these checks to flag any statement that does not reconcile so you can review it.

Is my financial data kept private?

Files are processed to generate your result and are not used for model training. For sensitive, high-volume workflows, the API and paid plans provide additional handling controls.

Can I convert many statements at once?

The free tool does one file at a time. Batch upload, API access, and webhooks are available on paid plans for teams processing statements regularly.

Can I use this to categorise my spending?

Yes. Export to CSV or Excel and the clean description, date, and amount columns make it straightforward to categorise transactions with formulas or rules, or to import into budgeting and accounting software.

Does it work for business as well as personal statements?

Yes. Personal, savings, and business statements share the same header-plus-transactions structure, and Docyield reads them all without a per-bank template.

Bank Statement Parser

Extract account details and transactions from bank statements.

Drag & drop your document here

Supports PDF, JPG, PNG, WEBP

Docyield's bank statement parser turns a PDF or scanned statement into a clean transaction table you can open in Excel, import as CSV, or consume as JSON through an API. It pulls out the account details and every transaction — date, description, amount, and running balance — so you can stop copying rows by hand and start working with the data.

Bank statements are deceptively awkward to digitise. Each bank uses its own layout, transactions wrap across lines, debits and credits sit in different columns, and balances run down the page. Docyield reads the statement as a coherent document, keeps the rows in order, and reconstructs the table even when the original PDF has no real table structure underneath it.

Inputs

PDF, JPG, PNG, WEBP

Outputs

JSON · CSV · Excel · XML

Price

Free · no signup

What a bank statement parser does

The goal is to convert a statement that was designed to be read by a person into rows that can be processed by software. That means identifying the header information — the bank, the account holder, the account number, and the period — and then extracting each transaction as a structured record with a date, a description, a signed amount, and the balance that followed it.

Getting the transaction list right is the hard and valuable part. A statement might contain a few dozen lines or several hundred across multiple pages, with opening and closing balances that have to tie out. Docyield preserves the order of the transactions and the sign of each amount — negative for money leaving the account, positive for money arriving — so the export matches the original without manual cleanup.

Converting a bank statement PDF to CSV or Excel

The most common request is simply: "I have a PDF statement and I need it in a spreadsheet." Export to CSV and you get one row per transaction with consistent columns, ready for a pivot table, a categorisation formula, or an import into bookkeeping software. Export to Excel and the same data arrives as a typed worksheet where dates sort chronologically and amounts add up.

Because the amounts are returned as real numbers rather than text, totals and running checks work immediately. That matters when you are reconciling: you can sum the transaction column and confirm it moves the opening balance to the closing balance without fighting the spreadsheet over values that look numeric but are not.

Who uses it

Accountants and bookkeepers importing client statements for reconciliation and categorisation.
Lending and fintech teams assessing income and spending for affordability and underwriting.
Finance teams pulling transactions into cash-flow models and forecasts.
Individuals who need a year of statements in a single spreadsheet for budgeting or tax.
Developers adding statement ingestion to an app via the Docyield API.

Accuracy and balance checks

Statements come with a built-in way to verify the extraction: the numbers have to reconcile. The opening balance plus the sum of the transactions should equal the closing balance, and each running balance should follow from the previous one plus the current transaction. These are exactly the checks Docyield uses to flag a statement that did not parse cleanly.

That reconciliation is a genuine advantage over plain OCR. Text recognition can misread a single digit and leave you none the wiser; a balance-continuity check catches the discrepancy and points you to the row that needs a second look. On the majority of statements everything ties out and no review is needed, which is the point — attention goes only where it is warranted.

Categorising and reconciling transactions

Once the transactions are in a spreadsheet, the real work begins, and structured data is what makes it quick. With a clean description column you can categorise spending with a few formulas or rules — groceries, salary, rent, subscriptions — instead of reading every line. A consistent date column lets you group by month or quarter, and a signed amount column lets you total inflows and outflows separately.

Reconciliation is the other everyday task. Because the running balance is captured for each row, you can confirm the statement is internally consistent and then match it against your own ledger or accounting system. Discrepancies surface as differences in a column rather than as a hunt through a PDF, which is the difference between a five-minute check and an afternoon of squinting.

Statement layouts it handles

Personal current accounts, savings accounts, business accounts, and credit-card-style statements all share the same underlying shape — header details followed by a dated list of transactions — even though they look nothing alike on the page. Docyield keys off that structure rather than a specific template, so a one-page savings summary and a forty-page business statement are handled the same way.

Layout quirks that trip up simpler tools are handled in stride: separate debit and credit columns, descriptions that wrap onto a second line, transactions grouped by date, and summary blocks interleaved with the transaction list. The parser reassembles each transaction into a single clean record regardless of how the original spread it across the page.

Exporting into accounting and budgeting software

A converted statement is most useful when it lands somewhere you already work. The CSV export is deliberately plain — one header row and one row per transaction — because that is the format almost every accounting and budgeting tool accepts for import. From there you can map the columns to your software's fields once and reuse that mapping for every future statement.

If you would rather stay in a spreadsheet, the Excel export opens directly with typed dates and amounts, ready for pivot tables, monthly summaries, or your own categorisation formulas. Either way the goal is the same: get the transactions out of a read-only PDF and into a place where you can actually compute with them.

Privacy and handling sensitive data

Bank statements are sensitive, and they should be treated that way. Files are processed only to produce your result and are not used to train models. Account numbers are returned exactly as they appear on the statement, including any masking the bank already applied.

For recurring or regulated workflows — a lending team processing applicant statements, for example — the Docyield API and paid plans add the controls that volume work needs, including batch processing and webhooks so statements can be handled without manual uploads.

What the bank statement parser extracts

Header details plus a full transaction list are returned against a fixed schema, so the columns are identical on every statement you process.

Bank name: The name of the bank that issued the statement.
Account holder: The name on the account.
Account number: The account number, returned as printed (often partly masked).
Statement period: The date range the statement covers.
Opening balance: The balance at the start of the period.
Closing balance: The balance at the end of the period.
Transactions: Each transaction with its date, description, signed amount, and running balance.

How to convert a bank statement to CSV, Excel, or JSON

1Upload the statement — drop a PDF or scanned image above, or click to choose a file.
2Let Docyield read the document and rebuild the transaction table.
3Check that the opening and closing balances and a few transactions match the original.
4Pick your output — CSV and Excel for spreadsheets, JSON for developers.
5Download or copy the result and import it wherever you need it.