ApexAutomation
Apex Automation

Apex Automation free tools

Bank Statement Converter

Checked against the balance your statement already prints

Converting a statement is the easy half. Knowing whether a row went missing on the way is the half that costs you an evening. Drop your PDFs here and every line is checked against the running balance the bank printed next to it, so a conversion that went wrong says where, and usually what happened.

  • Free to use
  • No account needed
  • Nothing uploaded
  • Works offline once loaded

Drop statement PDFs here

or

Several months at once is the point. They get checked against each other as well as on their own.

How a conversion gets checked at all

Most bank statements print a running balance down the right hand side, and almost nobody uses it for anything.

It is the most useful column on the page. After every transaction the bank tells you what the account now holds, which means the statement is carrying a checksum on every single line. Take the balance from the line above, apply this line's amount, and you should land on this line's balance. Do that all the way down and the first row where it stops working is the row that went wrong.

That turns a bad afternoon into a line number.

The usual check, where it exists at all, compares the opening balance plus the transactions against the closing balance. That is one sum for the whole statement. It tells you something is wrong and leaves you reading two hundred rows against a PDF to find out what. This page does that sum too, but only where there is no running balance to do better with, and when it falls back it says so.

The part we have not seen anywhere else is what happens next. The size of the gap is evidence. If the balance is out by exactly twice a row's value, that row was read as money in when it was money out, because nothing else produces exactly double. If it is out by the value of some other row on the statement, that row was dropped or counted twice. If it is out by a multiple of nine, two digits probably swapped places on the way through. So the page does not stop at naming the line, it says what it thinks happened, and where the arithmetic does not single out a cause it says that instead of inventing one.

What a gap tells you

The balance is out by Which means
exactly twice this row's amountthe sign is the wrong way round
exactly this row's amountthe line was counted twice
the amount of a different rowthat row was dropped or repeated
a factor of ten outthe decimal point was misread
a multiple of ninetwo digits swapped places
none of the abovesaid plainly, with the gap, for a human to look at

Each of these is a piece of arithmetic that only comes out true for one kind of mistake, so a match is evidence rather than a hunch. The last row is the honest one and it does get used.

One statement can be perfect and still be the wrong one

Nothing inside a file can tell you that the month before it is missing from your folder, or that you downloaded March twice under two different names, or that two of your statements overlap by a fortnight and everything in the overlap is about to land in your books twice.

The folder is the thing with the hole in it, not the file.

The join is the same idea one level up. The closing balance of one month is the opening balance of the next, so a run of statements that chains cleanly is a run with nothing missing in the middle. Where the chain breaks, the break sits between two named files, which is a far better place to start than a spreadsheet of two thousand rows.

Overlapping days get flagged with the number of days involved, and the rows caught in the overlap can be left out of the export. Two identical payments on the same day inside one statement are left alone, because coffee twice is a real thing and silently deleting a transaction would be a worse bug than the one being fixed.

The honest limit. This works on what your statements print. A month you never downloaded cannot be spotted as missing if the months either side of it are missing too, and a statement with no printed opening balance cannot be joined to anything. What the page can do is show you the run it does have and exactly where that run stops, which is the useful half of the answer and more than we found anywhere else.

What this will not do

Worth reading before you drop a folder in, because two of these come up often and the page refuses rather than producing something that looks fine.

Refused, by name, with the reason

  • Scans and photographs. Reading one needs character recognition. In a browser tab that is slow and it misreads digits in ways that look completely reasonable, and a wrong number with nothing to check it against is worse than no number at all.
  • Statements with no text layer. Same reason. The file is named and the reason given rather than half-converted.
  • Categorising your spending. Not attempted. Guessing which payments were business expenses is somebody's tax return, not a browser tab's decision.
  • Telling you a statement is genuine. The arithmetic can show that a statement is internally consistent. It cannot show that it came from a bank.

Where dates could be read two ways, with every day below the thirteenth, the page asks you which rather than picking. The amounts are read and checked either way, so only the dates wait.

Common questions

How do I convert a bank statement PDF to Excel or CSV?

Drop the PDFs onto this page and download the spreadsheet. It happens inside the browser tab, so there is no upload and no account. Each row is then checked against the running balance the statement prints, which is how you know it worked rather than hoping it did.

Why does converting a bank statement to Excel produce a mess?

Because a PDF has no table inside it. It holds characters with positions on a page, and the table is something your eye puts together. Generic converters guess at the arrangement, which is how a statement ends up in twenty columns, or with a whole line crushed into one cell. Both of those are in the Adobe forum threads, with five figure view counts and no fix. This page works the columns out by testing them against the running balance, so a wrong arrangement fails arithmetic instead of reaching your spreadsheet.

How do I know the converted data is correct?

The statement checks it for you, if you use the column it already prints. Walking the running balance means every line is verified against the bank's own arithmetic, and the first line that disagrees is named. Where a statement prints no running balance, only the totals can be checked, and that is a much weaker thing which the page describes as weaker.

Can I convert several statements at once?

That is rather the point of it. They are checked individually and then against each other, so a missing month shows up as a break between two named files rather than as a number that quietly fails to match your books in March.

Does it work on scanned statements?

No, and we decided against it on purpose. Character recognition in a browser tab is slow and gets digits wrong in ways that are very hard to spot. We would rather hand you the filename and the reason than a spreadsheet that looks right.

What about password protected statements?

Those work. The password goes straight to the PDF reader running in this tab and is not stored, logged or sent. Banks hand these out by default in several countries, so refusing them would rule out a lot of perfectly ordinary files.

Is my statement uploaded anywhere?

No. There is no upload endpoint in the page and no server behind it. Open your browser's Network tab while you convert, or pull your wifi once the page has loaded and carry on working. A bank statement is about as personal as a document gets, so this is worth checking rather than believing.

Can I send the result to my bookkeeper without sharing everything?

Use the redacted export. It masks the account number and the payee names and leaves the dates, the amounts and the balance check exactly as they are, so the file still does the job it is being sent to do without carrying a list of everyone you paid.

Tell us what would make this better

If a statement comes out wrong, that is the most useful thing you can tell us, and you do not have to send the statement to do it. The line number and what the page said about it is usually enough. toolssupport@apexautomationteam.com

  • A bank whose layout comes out wrong
  • A format your accounting software wants that is not here yet
  • Anything in the tool that is broken, or just quietly annoying
  • A version of this wired into your own platform or workflow
  • Something else altogether, built to your spec

Email our team See what we build

A statement that converts wrongly jumps the queue. Everything else is a feature request and waits its turn.