· 5 min read
Scanned bank statements: what works
How scans and phone photos are read, what makes a page readable (resolution, skew, light), what to check afterwards, and why scans get a balance check.
A native PDF from online banking carries its text as text. A scanned statement or a phone photo carries pixels, and every digit has to be recognized before it can be tabulated. That difference decides how fast the conversion is, what kind of mistakes it makes, and how much checking you should do afterwards. This article is about the second kind of file.
What extraction from a scan actually does
Whatever a converter calls it, the job on an image has three parts.
First, the page is prepared: rotated to upright, cropped to the paper, and sometimes sharpened or de-noised. A page scanned a degree off true is corrected here; a page photographed at a steep angle can only be partly corrected, because the far edge of the table is genuinely smaller than the near edge.
Second, the table is read. Older systems recognized characters one at a time and then guessed which characters belonged to which column. Current systems read the page as a whole, so they see that a number sits in the balance column and that a description wrapping onto two lines is still one transaction. That is why extraction from scans became usable in the last few years. It is still recognition of marks on paper, and the classic confusions survive: 3 and 8, 1 and 7, 5 and 6, 0 and 6, a decimal point lost in a fold.
Third, the rows are checked. Because misreads on scans are mostly single digits, the one test that reliably exposes them is arithmetic: recompute the running balance from the extracted amounts and compare it with the balance the bank printed on each line. A misread digit changes the amount, the amount changes the computed balance, and the row is flagged. Description misreads are not caught this way, which is worth knowing when you decide what to check by hand.
What makes a page readable
Most scan failures are decided before upload. These are the variables that matter, roughly in order.
Resolution. A scanner at 200 to 300 DPI is comfortable. 150 DPI works but leaves little margin for the digit confusions above. A phone camera has plenty of pixels; the problem is what happens next, because messaging apps recompress images heavily. If a client sends photos, ask for them as files or documents rather than as pictures in the chat.
Framing. The whole page, including the header with the account and period, and the bottom of the table with the closing balance. A cropped closing balance means the arithmetic check has nothing to close against. One page per photo: two pages in one frame halves the resolution of each.
Angle. Shoot from directly above. A few degrees of tilt is fine. Thirty degrees is not, because the columns stop being parallel.
Light and shadow. Even light from the side, such as a window, beats an overhead lamp, which puts the photographer's shadow across the page. A shadow that crosses the amount column is the most common cause of a misread digit on an otherwise good photo.
Flatness. A fold across the transaction table breaks rows. Flatten the page; if it will not stay flat, weigh the corners.
No digital zoom. Zoom throws away detail. Move closer.
The test that covers all of these: if you cannot read every digit in the balance column on your own screen, do not expect a converter to.
Scans get the balance check too
It is tempting to treat the check as a bank-statement feature and scans as a separate, best-effort category. The opposite is true: the check matters most on scans, because that is where amount errors actually happen.
A scan is harder to read than a native PDF, and the errors it produces land in the amounts: a 3 read as an 8, a decimal point lost in a fold. That is exactly what the balance check tests. A digit read wrong breaks the running total, and the row is flagged with the difference rather than passed through. Scans and photos go through a stronger reading pass than native PDFs for this reason, which is also why they take longer. How we validate releases.
The result: a good scan comes back clean, a poor one comes back with a handful of flagged rows, and in both cases you are told which rows rather than finding out at month end. There is no single accuracy figure for scans worth publishing, because the figure belongs to the scan, not to the software.
What to check afterwards
Assume the conversion is done and the result is on screen.
- Flagged rows first. Each one names the first row where the computed balance and the printed balance disagree. Compare that row, and the row before it, with the image. The size of the difference tells you what happened: equal to a nearby amount, a dropped or doubled row; twice an amount, a flipped sign; divisible by nine, transposed digits. Reading a flagged row has the full list.
- Opening and closing balances. If the opening balance was misread, the very first row fails and everything after it carries the same difference. If the closing balance was cropped, the check cannot finish, and the file says so instead of reporting a pass.
- Page boundaries. The last row of one page and the first of the next are where duplicates and drops happen, especially on photos where the bottom of the page sits at the edge of the frame.
- Descriptions. The check does not see them. Skim for cut-off payee names and for accented characters that came out wrong. Amounts are the priority; descriptions are usually fixable in bulk later, in your software's rules.
- Dates. A misread day stays invisible to the check as long as the rows are in order. Look at the first and last few dates on each page.
If a page comes back with more than a few flagged rows, re-shoot it with better light before fixing cells by hand. A better image fixes more in one pass than editing does.
Time and limits
A scanned PDF takes about 20 to 40 seconds a page and a full-resolution phone photo 40 to 60 seconds, against 10 to 60 seconds for a whole native PDF. Several photos of consecutive pages are treated as one statement with one check; the current limit is 10 photos, under 5 MB each after the browser shrinks them, or a scanned PDF up to 20 MB and 100 pages. Screenshots of a banking app are not statements: there is no printed balance, so there is nothing to check against. The scanned statements page keeps the current limits and the same numbers.
If the native PDF exists, use it. It is faster, more accurate and the same price per page. Scans are for when it does not.