Scanned Bank Statements: Converting Image-Only PDFs Without OCR Garbage
A scanned statement has no text in it at all until OCR creates some. That extra step introduces a specific class of error that is dangerous in financial data because misread digits look completely plausible. Here is how to identify, convert and verify image-only statements.
By Saurav Agarwal
A scanned PDF contains no text — only a picture of text. Optical character recognition has to invent the characters before any conversion can happen, and on financial documents its mistakes are uniquely dangerous: a misread digit produces a valid-looking number rather than a visible error. Verification by balance reconciliation is not optional here.
Key takeaways
Scanned and digital PDFs are different problems. Confirm which you have before choosing a tool.
OCR errors in amount columns are silent —
5,180.00misread as5,l80.00or8as3still looks like money.Scan quality matters more than software. 300 DPI, flat, evenly lit beats any post-processing.
Reconciling extracted transactions against the printed closing balance is the only check that catches every error at once.
How do I tell if my statement is scanned or digital?
Open it and try to select a line of text with your cursor.
Individual words highlight → digital PDF with a real text layer.
The whole page highlights as one block, or nothing does → image-only scan.
A second check: press Ctrl+F (Cmd+F on Mac) and search for a word you can clearly see on the page. If the search finds nothing, there is no text layer to find it in.
Two in-between cases are worth knowing about. A searchable scan is an image with an OCR text layer already added — usually by the scanner. You can select text, but that text is somebody else's OCR output and carries their error rate. And a mixed PDF can have digital pages and scanned pages in one file, which happens when someone photographs one missing page and merges it in.
Why is OCR on financial documents harder than on prose?
Because prose has redundancy and numbers do not.
If OCR misreads a letter in the word "payment", you still read "payrnent" as payment — context repairs the error, and a spell-check would flag it. If OCR misreads £1,830.00 as £1,880.00, there is no context to repair it and nothing to flag. The value is well-formed, plausible, and wrong.
These are the confusions that matter in an amount column:
Confused pair | Typical cause |
|---|---|
| Similar shapes at low resolution |
| Serif and handwriting variation |
| Poor contrast or ink bleed |
| Broken or filled loops in low-quality scans |
| Faded print |
| Speckle noise — turns 1,000.00 into 1.000,00 or 100000 |
The last row is the worst. A decimal separator misread as a thousands separator changes a value by a factor of a hundred, and the result is still a number.
What makes a scan convert well?
Most OCR accuracy is determined by the scan, before any software runs.
Scan at 300 DPI. Below 200, character shapes degrade enough that the confusions above become common. Above 400 gives little benefit and much bigger files.
Keep the page flat and square. Deskewing corrects a few degrees well. A curled page photographed at an angle distorts character shapes unevenly across the page, which no deskew fixes.
Use even light, no shadow. Phone photos in overhead light throw a gradient across the page, and thresholding then loses text in the dark region. If you must photograph, use diffuse light and avoid casting your own shadow.
Prefer greyscale or colour over bitonal. Black-and-white scanning throws away the intermediate tones OCR uses to distinguish 8 from 3.
Ask for the original if you can. This is the single highest-value step. Most banks let you download a statement as a digital PDF for the last 90 days to several years. A five-minute download beats any amount of OCR tuning — the digital file has no recognition error at all.
Why does OCR alone still not give you a spreadsheet?
Because OCR returns characters and their positions. It does not return a table.
After recognition you have exactly the problem a digital statement poses — reconstructing columns, rows, and continuity from coordinates — with the added complication that the coordinates are now approximate and some characters are wrong.
That means a scanned statement needs both stages to work:
Recognition — turning pixels into characters, with an error rate driven by scan quality.
Layout reconstruction — turning positioned characters into a transaction table, which needs the same bank-statement awareness a digital file needs: column boundaries, wrapped descriptions, page continuity, and debit/credit direction.
A tool that does the first well and the second generically gives you accurate characters in the wrong columns. That is not obviously better than the reverse.
How do I verify a converted scan?
Assume errors and go looking for them. On a scan, this is the work — not an optional final step.
Reconcile the balance. Take the opening balance, apply each extracted transaction in order, compare to the printed closing balance. A match to the cent is strong evidence that every amount and every sign is right. This single check subsumes most others.
Sort by amount, both directions. OCR errors often produce outliers. A transaction of 100,000.00 in a personal account, or 0.01 where you expect tens, surfaces instantly at the extremes.
Spot-check the low-contrast regions. Look at the parts of the scan that are faintest — the top of the first page and the edges are common — and verify those rows against the image by eye.
Check dates run in order. A date that jumps backwards usually means a misread digit in the date or a row assembled from two different transactions.
Count the rows. Compare the transaction count in the output against the PDF, page by page.
If step 1 reconciles, you can stop. If it does not, the discrepancy amount often points straight at the error — a difference of exactly 900.00 suggests a leading digit misread, and a difference that is a multiple of 99 suggests a transposition.
Converting scanned statements here
This converter runs a hybrid OCR pipeline for scanned and image-based PDFs, then applies the same bank-statement layout reconstruction it uses on digital files, producing the same fixed schema: date, description, debit, credit, balance, as CSV or Excel.
Two practical limits: files are capped at 50 MB for signed-in users and 10 MB for anonymous ones, and scans are considerably larger than digital PDFs — a 12-page colour scan at 600 DPI can exceed the cap on its own. Scanning at 300 DPI in greyscale keeps files well under it and improves recognition at the same time.
Source PDFs are deleted from storage immediately after processing, and uploaded documents are never used to train AI models. The full retention detail is in the privacy policy. You can convert a scanned statement here — signup includes 50 free credits, at one credit per page.
Frequently asked questions
Can I convert a photo of a bank statement taken on my phone?
Usually yes, but expect a higher error rate than a flatbed scan. Phone photos introduce perspective distortion, uneven lighting and shadow. If you must use one, photograph the page flat on a plain surface in diffuse light, fill the frame with the page, and keep the camera parallel to it rather than at an angle.
Why did OCR read my statement but put everything in one column?
Recognition and layout reconstruction are separate stages. OCR successfully produced characters, but the tool then failed to identify column boundaries and emitted each line as a single value. This is common on borderless statements and is a layout problem, not a recognition problem — a different extraction approach is needed rather than better OCR.
Is OCR accurate enough for accounting work?
Not on its own, and not without verification. Character-level accuracy on a clean 300 DPI scan is high but never perfect, and financial data has no redundancy to absorb errors. OCR output should always be reconciled against the statement's own closing balance before it is imported into an accounting system.
Should I convert a scanned statement or ask the client for a digital one?
Ask for the digital one whenever it is available. Most banks provide downloadable PDF statements covering at least the last 12 months, and a digital file removes the entire recognition error class. Convert the scan only when the original genuinely cannot be retrieved — a closed account, an older period, or a bank that only ever mailed paper.
Does a password-protected scanned PDF need unlocking first?
Yes. A PDF encrypted with an open password cannot be read by any converter until it is decrypted, because the page content itself is unreadable. Open it with the password in a PDF viewer and save an unprotected copy, then convert that. Permissions-only restrictions, which allow opening but block copying, are a different and less obstructive case.