Skip to content

Bank Statement to Excel

Turn a PDF bank statement into a real .xlsx or CSV, with every row’s running balance verified so you know the numbers came out right. Nothing is uploaded.

Private · on device. Runs in your browser: your file is not uploaded. No sign-up.

Nothing is uploaded, it is read on this device
Your statement is not uploaded. It is read in this browser tab and never sent anywhere. That matters here more than almost anywhere: a bank statement lists your name, address, account number, salary, employer, landlord, and every place you spent money for a month.

Converting is easy. Knowing it worked is not.

Pulling numbers out of a PDF is not especially hard, and dozens of tools do it. The hard question is the one none of them answer: did it come out right?

This matters more than it would for other documents. If a converted article has a typo, you notice. If a converted statement has 1,700 where the original said 1,200, you do not, you reconcile the accounts, the figures do not match, and you spend an afternoon looking for a mistake that was introduced by the tool.

The usual answer is a claimed accuracy figure. "99.9% field-level accuracy" is a statement about the vendor's test set, not about your file, and it is unfalsifiable from where you are sitting.

A statement carries its own proof

Here is what makes this document type unusual: a bank statement contains a checksum, and nobody uses it.

Every row has a running balance, and each one must follow from the row above:

balance(n) = balance(n − 1) + credit(n) − debit(n)

That has to hold for every row, because the bank computed it that way. So after extraction, the chain can be recomputed and compared. If a digit was misread, the sum breaks. If a row was dropped, the sum breaks at the next row. If a column was misaligned, it breaks immediately and everywhere.

When every row checks out, that is not an estimate of accuracy, it is a demonstration of it. Hundreds of independent arithmetic checks all passing is not something a corrupted extraction achieves by luck.

The three ways a conversion goes wrong

Columns shift when a cell is empty

The most common bug, and the most damaging. A row with no debit value has one fewer piece of text on it. A converter reading each row independently sees four values instead of five, files the credit under debit and the balance under credit, and every figure on that row is now wrong, plausibly wrong, in the right format, in the wrong column.

The fix is to establish the column positions across the whole page first and assign by position, leaving a gap where a cell is empty. That is what this tool does, and the balance check confirms it worked.

Dates read in the wrong order

03/04/2024 is 3 April in London and 4 March in New York, and a PDF does not record which is meant. A converter that assumes one convention silently shifts transactions by up to eleven months on statements from the other.

The whole column resolves it: as soon as any date has a value above twelve in the first position, that position must be the day. One unambiguous date settles every ambiguous one.

Rows quietly dropped

A transaction whose description wraps onto a second line, a row split across a page break, a subtotal mistaken for a transaction. Each drops or duplicates a row, and a row count alone will not tell you, you would have to know what the count should be.

The balance chain catches this immediately: a missing transaction makes the following row's balance wrong by exactly the missing amount, which usually identifies it on sight.

Why this one runs in your browser

Most converters upload your file to a server. They are usually careful, and generally say the file is deleted afterwards. The question worth asking is whether the trade is necessary at all, because a bank statement is not an ordinary document.

It carries your full name and address, your account and sort code, your salary and who pays it, your rent and who receives it, and a complete record of where you were and what you bought for a month. That is enough for identity theft, and it is enough for a very detailed picture of your life.

None of that needs to be sent anywhere. The conversion is arithmetic and text handling, work a browser does perfectly well. So it happens here, on your machine, and the file never leaves it. You can watch the Network tab while it runs, or disconnect from the internet after the page loads.

More on what is actually in the file in the privacy guide.

Check the result anyway

Even with a clean verification, look at the preview before downloading. Confirm the first and last dates match your statement period, and that the closing balance matches. That takes ten seconds and catches the one class of problem arithmetic cannot: a statement where the extraction was internally consistent but began or ended in the wrong place.

The two-minute checking guide covers the full routine. For tables that are not statements, invoices, reports, price lists, the PDF table tool extracts the columns without trying to interpret them.

Frequently asked questions

What does "verified" actually mean?

It means the extracted numbers pass the statement's own internal check. Each row's closing balance must equal the row above it, plus that row's credit and minus its debit. If a digit had been misread, or a row dropped, the chain would break and the tool would name the row where it broke. That is a genuine proof of correctness, not a confidence estimate, and it is the check other converters do not run.

Is my statement uploaded?

No. It is read in this browser tab and never transmitted. This is the main reason to use this rather than a cloud converter. A bank statement lists your name, address, account number, salary, employer, landlord and every place you spent money for a month, it is arguably more revealing than your bank password, because a password can be changed.

It says some rows do not add up. What now?

Open the original PDF and compare the named rows. Usually one of three things has happened: a figure was misread because the PDF put two numbers unusually close together, a transaction spanning two lines was split, or a page footer was picked up as a row. The rows are listed with the expected and found balances so you can see the size of the discrepancy, which usually identifies the cause immediately.

Why does it need a running-balance column?

Only for the verification. The conversion works without one, but there is then nothing to check the arithmetic against, and the tool says so rather than implying a confidence it cannot justify. Most bank statements include a balance column; card statements often do not.

My statement is a scan and nothing came out.

A scan is a photograph, so there is no text to extract. Download the statement from your bank's website or app instead of scanning a posted copy, a downloaded PDF always has a real text layer. If you only have paper, you need OCR, which is a different kind of tool and considerably less accurate on tables.

Which banks does this work with?

It does not have a list of banks, and does not need one. It works out the column positions from the layout of the page and identifies which column is which from the header row or the shape of the data. That means it handles statements it has never seen, including ones from small banks and other countries that a template-based converter would not cover.

Does it handle UK and European date formats?

Yes, and it works out which by looking at the whole column rather than guessing per row. As soon as one date has a value above twelve in the first position, the column must be day-first. Getting this wrong is a common and quiet failure: 03/04 becomes 4 March instead of 3 April, and every transaction shifts.

Is the Excel file a real .xlsx?

Yes, a genuine spreadsheet, not a CSV with the extension changed. Amounts are written as numbers, so they sum in Excel without anyone retyping them. A renamed CSV makes Excel show a warning on opening and mangles long account numbers into scientific notation, which is a large share of the complaints about statement converters.