Overview

extractbankstatements.com turns a bank statement into rows you can use: date, description, amount, running balance. The part other converters skip is that every figure is then checked against the statement's own arithmetic, so you know whether the numbers add up before you use them.

Two ways in#

The app. Sign in, drop a PDF on the upload area, and take CSV, Excel or OFX back when it finishes. Nothing to install. The free plan reads three statements a month and does not ask for a card.

You can convert one statement before signing up, from the front page, and see the figures and what the arithmetic said about them. That first conversion reads a PDF's own text layer only, so a scan or a photograph needs an account. Signing up afterwards moves the statement into it, where you can download it.

The REST API. Upload from your own code, poll for completion, and pull the transactions back as JSON, CSV, Excel or OFX. Every format the app offers is on the API too. Included in Pro and Business.

Both run the same extraction and return the same figures. The API exists so the result can land in your own product; it is not a different or better reader.

What "reconciled" means#

A statement is reconciled when two separate sums agree with what the bank printed:

• The opening balance plus every transaction equals the closing balance.
• The debits and credits sum to the totals the statement declares.

If both hold, the extraction is proved and marked reconciled. It is never quietly presented as correct otherwise.

This matters because a wrong number looks exactly like a right one. Any tool can produce a table, and the table always looks fine; you find out it was wrong when a reconciliation fails three weeks later, or you never find out at all.

Invoices#

An invoice is not a bank statement and it has arithmetic of its own. Its line items sum to a total it declares, and the amount its tax was charged on plus that tax is what is owed. Both are real checks on figures read off the page, so an invoice can be verified rather than merely read, and 88 of a test corpus of 140 real invoices are.

Which total the lines add up to is not something an invoice states. Some quote their lines before tax and some quote them tax-inclusive, and an invoice can declare a subtotal its lines reach AND a separate figure its tax was charged on, differing by the tax on a shipping charge listed under both. We read those as the different quantities they are and try each, rather than assuming a number labelled one thing is also the other.

Two things about an invoice's rows are worth knowing before you use them.

Amounts are as the invoice prints them. A bank statement has a direction and we work it out: money out is negative, money in is positive. An invoice does not. The same document is money out to whoever received it and money in to whoever sent it, and the page never says which, so we do not invent a sign.

Every line carries the invoice's date. A line item is something that was billed, not something that happened on a day of its own.

You do not have to tell us which you are uploading. Every way of reading the page is tried and the one the document's own arithmetic proves is kept, so the kind we report is what the document turned out to be rather than a guess made before reading it. The API upload takes an optional kind if you already know, or if a file is genuinely two documents and you want a particular reading of it. Saying so restricts which readings are tried and settles nothing on its own: a document declared as one thing and not proved as one still comes back unproved.

The three answers#

Checking a document's arithmetic has three possible outcomes, and every document and every row we return carries which one it got, as verification.

None of the three withholds anything. Whichever answer a document gets, the transactions are there: the table renders, CSV and Excel download, the API returns the rows. The three differ in what we are willing to claim about the figures, not in what you can do with them.

Verified. The document's own arithmetic reaches this figure and agrees with it: the running balance on a statement, the line items summing to a declared total on an invoice. A misread digit anywhere would have broken it, so this is a proof and not an opinion. The app labels this Verified.

Contradicted. The arithmetic reaches this figure and disagrees. We say by how much, and where a check can name the rows involved we mark them. This is the only one of the three that is a warning, and the app labels it Mismatch.

It is also the one where we say whose reading is in doubt, because usually it is ours. If an invoice's line items miss a total, but its own subtotal, tax and total agree with each other, then the issuer's arithmetic is sound and it is our reading of the lines that disagrees with it. You get told that, rather than left to wonder whether your invoice is wrong.

Not verifiable. The document carries no arithmetic that reaches this figure, so nothing on it could confirm or deny what we read. The figures are reported exactly as printed and we say we could not confirm them. This is the ordinary answer for an invoice or a receipt, and the app labels it Ready.

That last one deserves to be said plainly rather than apologised for. A great many documents contain no internal check at all. An invoice with no totals lists what it lists; there is no running balance to walk and nothing declared to sum against. We cannot verify a document that carries nothing to verify it with, and we will not pretend otherwise. What we will do is say so, once, on the document, instead of marking every line of it for a review that has nothing to find. Reading a figure has never been evidence that it is right, and neither is the silence of a page that makes no claims about itself.

It applies to part of a document too. An invoice whose subtotal, tax and total agree with each other has proved something real about those three figures and nothing at all about the lines above them, because that check never reads one. So the totals come back proved and the rows come back not verifiable, and we say which is which rather than letting the first stand in for the second.

What can be read#

PDF, PNG, JPEG, WebP and HEIC, up to 25MB per file. HEIC is what an iPhone camera produces, so a photograph of a paper receipt can be sent exactly as it comes off the phone.

A PDF the bank generated is read from its text layer, character by character, with no guessing. A scan or a photograph has no text layer, so it goes through OCR instead. Both are held to the same arithmetic, and OCR that produces a statement which does not reconcile is reported rather than returned.

There is no list of supported banks because there is no per-bank code: the layout is worked out from the page itself, so a bank we have never seen is read the same way as one we have. Monzo, Barclays, Revolut, Qonto and Fortuneo statements are in the test suite and have to keep reconciling for a change to ship.

Your data#

Statements are stored in the EU and are reachable only by the account that uploaded them. Deleting a statement removes it, and every transaction read from it, from your account.

A statement we have already read is recognised on re-upload and returned as it stands, free, rather than being read and billed a second time.