How to tell a scanned bank statement from a text one in five seconds

You selected a block of transactions in a statement document, pasted it into Excel, and the whole thing landed in one cell as a run of characters that looks nothing like the table on screen. Or nothing pasted at all. Either result raises the same question, and it is worth answering before you reach for another tool: is the page a picture of a statement, or a statement whose text has no table structure to hand over? Both produce that symptom, they are different problems with different fixes, and one test separates them.

Every downstream decision follows from that one distinction. Which tools can read the file, how long the conversion takes, what class of error you have to check for, and whether a bad row will look obviously broken or quietly plausible. So establish it first, in five seconds, before you try anything else.

The five second test

Open the statement document in any viewer. Find a transaction row. Put your cursor to the left of a single amount and drag across it, as though you were about to copy it.

• The number highlights cleanly, character by character. You have a text statement. The digits are stored as characters with coordinates on the page.
• Nothing highlights at all. The page is an image. There is no text to select because there is no text, only pixels arranged to look like text.
• The whole page highlights as one rectangle or one object. Same answer: the page is an image, and you have selected the image.
• A loose block of text highlights but the characters do not match what you see. The page is an image with an OCR layer already applied by a scanner or an earlier tool. The visible numbers are pixels; the selectable ones are somebody else's guess at them.

That fourth case is the one that catches people out, because the document behaves like a text document right up until the numbers turn out to be wrong. If a search for an amount you can plainly see on the page returns no result, or returns a different figure, treat the file as a scan.

A second confirmation takes another five seconds. Search the document for an amount you can read on the page, typed exactly as it appears including the thousands separator. A text statement normally finds it, and a scan carrying no OCR layer cannot. Treat the search as confirmation rather than as a replacement for the selection test, because neither result is conclusive alone: a text statement with broken character encoding will fail the search, and a scan with a good OCR layer will pass it.

Why the two kinds exist at all

Most statements you download from online banking are generated by the bank's own system, which places the figures on the page as characters with exact positions, so the amount 1,890.00 is stored as those eight characters. Nothing has to be recognised, because nothing was ever lost. A minority of institutions flatten or rasterise the documents they issue, which is the reason to spend five seconds on the test even when the file came straight from the bank rather than through a scanner.

A statement becomes a scan the moment paper enters the chain. Someone printed it and scanned it, or an archive service imaged a box of old statements, or a client photographed the pages on a phone and mailed them over. At that point the characters are gone and only their appearance survives. Getting data back out means recognising the shapes, which is a fundamentally different and less certain operation. The same applies to statements you only have as a phone photo, which are scans with worse lighting and geometry.

There is a third case worth naming: a text statement that copies badly. Text statements store characters with coordinates, not rows and columns, so a copy generally gives you a stream in reading order rather than a table. How bad it looks depends on what you copied from. A full PDF application will often work out the columns as you copy and insert tabs and line breaks to approximate the table; a browser viewer usually will not, and hands you the raw reading order. Either way it is a layout problem rather than a recognition problem, and it is why a text statement can paste into Excel as a mess without being a scan at all.

Why OCR misreads bank statements specifically

Any OCR accuracy figure you have seen quoted was measured on prose, and it does not transfer to a statement. This is not a matter of degree. Recognising prose and recognising a ledger are different problems, and the thing that makes prose recoverable is absent from a statement by construction.

Prose is redundant. A misrecognised letter is corrected by the word around it, the word by the sentence, the sentence by the paragraph, and a general purpose engine exploits all three layers without being told to. A statement has none of that redundancy. In a column of amounts, 1,890.00 and 1,390.00 are equally valid, equally well formed and equally consistent with everything else on the page. There is no linguistic model that prefers one, because there is no language in the figure. An engine tuned on documents can be excellent at prose and still have nothing to offer here.

So the accuracy of a statement conversion does not come from the recognition step at all. It comes from what the tool does afterwards, and specifically from whether it holds the extracted rows against the arithmetic the statement itself publishes. Four failure modes account for most of what goes wrong, and every one of them is invisible to inspection and visible to arithmetic.

Thousands separators and decimal points

A comma and a full stop occupy a handful of pixels each, and at 200 dpi on a slightly grey scan they are the least distinct marks on the page. Three things happen. A separator drops, and 1,890.00 becomes 189000. A separator is invented inside a description, splitting one field into two. Or the decimal point is read as a comma, which in a mixed locale document silently changes the magnitude of the amount by three orders. Any of these produces a number that is wrong but formatted plausibly.

DR and CR suffixes

Many UK, Irish, Indian and Commonwealth statements mark direction with a DR or CR suffix after the amount rather than a minus sign. OCR frequently reads DR as OR or D8, and CR as CB or GR. When the suffix is mangled, the sign is lost, and a debit is imported as a credit. The amount is correct, the direction is not, and the row looks entirely normal in the output file. This is the quietest of the four, and if your bank marks amounts DR and CR, turning those suffixes back into signed numbers is the repair.

Wrapped narration lines

Transaction descriptions wrap. A card payment with a long merchant reference occupies two or three visual lines while its date and amount sit on the first line only. Recognition works on the page as it is laid out, and depending on the engine it hands back words, lines, blocks or table cells; what none of those granularities carries is any statement about which fragments belong to the same transaction. So those continuation lines arrive as rows with narration and no figures. A naive assembler either promotes each one to its own transaction, inflating the row count, or discards it, losing half the description. Neither is visible from the totals.

Column drift

Statement columns are held apart by whitespace, not by ruled lines. A scan with two degrees of rotation, a fold shadow down the middle of the page, or a slightly compressed print run will shift the amount column a few millimetres relative to the balance column. Halfway down the page, a value crosses the boundary the reader inferred at the top, and from that row on, debits land under credits. The output looks structurally fine. Only the arithmetic exposes it, which is exactly why a balance check on the converted file catches more than a visual scan does, and why skewed pages deserve straightening before conversion rather than after.

What to do once you know which one you have

If the test said text, most tools will get something out of the file, and your remaining risk is structural: merged columns, split rows, a wrapped description that became its own transaction. If it said scan, recognition risk is added on top, and verification stops being optional.

1. 1

   Run the selection test

   Drag across one amount. Selectable characters mean text; no selection means an image.
2. 2

   Search for a visible amount

   Type an amount you can see on the page into the document search. No match on a document that looked selectable means an unreliable OCR layer is already present.
3. 3

   Straighten and clean a scan before converting

   If pages are rotated, skewed or cropped mid-column, fix that first. Column detection depends on alignment, and a few degrees is enough to break it.
4. 4

   Convert the statement as issued

   Upload the original file rather than a screenshot, a re-export or a photograph of the screen. Every re-encoding loses detail that recognition needs.
5. 5

   Reconcile before you use the output

   Compare the closing balance in the converted file against the closing balance printed on the statement, and compare the row count against the statement's own transaction count.

That last step is the whole game on a scanned statement. A misread digit is small, plausible and invisible on inspection; it is only ever caught by arithmetic. A reconciling balance chain is the strongest automatic check available, and it catches the error class that matters most, a wrong digit in an amount, because a misread amount breaks the chain arithmetically and has nowhere to hide. It does not verify dates or descriptions, and errors that perfectly offset one another can survive it, so give the dates a glance against the statement period and read a few descriptions against the page. If the chain breaks at row 84, the error is at or just before row 84, and you can go and look at it, which is the reason to keep the balance column in the output rather than discard it once the file is built. Digit-level checking of a converted file is covered in more depth in the guide to catching OCR digit errors in statements.

The verification is the point, not a feature attached to the end of one. Recognition on a ledger will always be a probabilistic step; checking it against opening balance, movements and closing balance is what converts a probable answer into one you can put your name to.

Checking a scanned conversion

Four figures tell you almost everything about whether a scanned conversion is sound. Take them straight off the statement and compare.

Check the largest amount by hand regardless of what the totals say. It carries the most digits and the most separators, so it is the value most exposed to a dropped comma, and a dropped comma there distorts a total more than anything else on the page. The debit subtotal is worth taking separately from the closing balance, because a debit read as a credit leaves the row count intact and moves the closing balance by twice the amount rather than by the amount, which is a distinctive signature once you know to look for it.

When a text statement still converts badly

A clean text statement is not a guarantee. The characters are exact, but they arrive as positioned fragments in reading order, with no notion of which fragment belongs to which column. A converter still has to infer the table. Multi-column layouts, running balances printed in a side panel away from the transaction table, and descriptions that wrap across lines all break naive extraction on text statements just as reliably as on scans. The difference is that the failure is structural rather than numeric, so it tends to look obviously wrong instead of quietly wrong.

That is the practical summary of the distinction. On a text statement, errors announce themselves: a column is empty, a row has too many fields, a description is sitting under the amount header. On a scan, errors hide: every column is populated, every row looks like a transaction, and a figure somewhere in the file is wrong. The first kind you find by looking. The second kind you find only by reconciling.

If you are unsure after the selection test, run the search test as well rather than guessing, because the guess is not free in either direction. Treating a text statement as a scan pushes a page through recognition when exact characters were already available, which introduces a digit risk you did not have. Treating a scan as text leaves you checking for the wrong class of error. What is never wasted is the reconciliation itself: on a text statement it confirms the table was assembled correctly, on a scan it is the only evidence that the figures were read correctly, and on both it takes about a minute.