The best DPI for OCR on bank statements, invoices and printed tables is 300. At that resolution, ordinary 9 to 12 point print has enough pixels per character for clean recognition. Pages with very small print, such as fine-print footers or shrunk printouts, read better at 400 or 600. Settings above 600 add file size and time, not accuracy.
Why is 300 the best DPI for OCR on most statements?
Three hundred DPI, dots per inch, gives each character on a normal statement enough pixels for an OCR engine to tell similar shapes apart. The open top of a 4, the gap in a 6 and the thin stroke of a 1 all survive. Lower settings blur those details, and the engine starts confusing digits.
The figure is not folklore. Tesseract's guide to improving OCR quality, the documentation for a widely used open-source engine, says it works best on images of at least 300 DPI.
What matters underneath is the height of each character in pixels, not the DPI number alone. DPI is just the link between the physical size of the print and the pixel size of the image. A statement printed at 10 points scanned at 300 DPI gives characters around 40 pixels tall from top to bottom of the type size, with the digits themselves somewhat smaller. That leaves several pixels for each stroke and gap.
Phone photos do not have a fixed DPI, because the distance to the page changes it. The useful equivalent is to fill the frame with one page and use the full camera resolution. A modern phone photo of a single page usually lands near or above the 300 DPI equivalent. Excel's own picture import is built around that kind of photo, and using Data From Picture in Excel shows how it handles one.
When does small statement print need 400 or 600 DPI?
Small print needs 400 or 600 DPI when the characters fall below roughly 8 points on paper. On a bank statement, that usually means the fine-print footer, a tiny reference number column, or a whole page that was reduced to fit. For those pages, raising the resolution restores the pixels each character needs.
Pages worth a higher setting:
- Reduced printouts. A wide report printed with "fit to page" can shrink 10 point text to 6 or 7 points.
- Dense statements. Some banks print transaction lines in small type to fit more on each page.
- Faded or low-contrast print. Extra resolution does not restore missing ink, but it keeps faint strokes from merging with the paper grain.
- Accented or non-Latin characters. Small marks above and below letters disappear first at low resolution, a problem covered in OCR for non-English bank statements.
Brackets and minus signs deserve attention. A statement that shows negatives as (214.60) relies on two thin curves, and at low resolution one can vanish, which turns a debit into a credit. If your spreadsheet later shows negatives oddly, how parentheses for negative numbers work in Google Sheets covers the display side.
Archive paper is a frequent candidate too. Older statements were often printed by impact or dot-matrix printers whose characters are made of separate dots. A higher resolution lets the engine see each character as a whole. Converting old bank statements from archive paper goes through the rest of that job.
Scanning above 600 DPI for OCR: size and speed costs
Scanning above 600 DPI rarely improves OCR on printed documents, and it costs a lot. Doubling the DPI multiplies the pixels on a page by four, so the file grows, the upload slows and the engine has four times as much image to process. Beyond the point where characters are clear, the extra detail is paper texture and noise.
Very high settings can even hurt. At 1200 DPI, every speck of dust and every fibre of the paper becomes a visible object, and some engines treat those specks as punctuation. A decimal point that appears where none was printed is a worse error than a slightly soft digit.
The practical rule is to scan the whole document at 300, then rescan only the pages that fail at 400 or 600. Most statements need no second pass. For bank statements you can download from the bank, skip the scanner entirely: a digital PDF has exact text and needs no OCR at all. FastBankConvert is built for both kinds of file, with scanned pages taking longer to read, and it is getting ready to open; the homepage explains how to join.
Checking character height in pixels at each scan DPI
Character height in pixels is the honest test of whether a scan is sharp enough. A point is 1/72 of an inch, so the arithmetic is simple: point size divided by 72, times DPI. The result is the type size in pixels, and the digits on the page are a little smaller than that figure.
The table below shows that arithmetic for two common print sizes. The pixel counts are calculated, not measured, and the last column compares the total pixels per page with a 300 DPI scan.
| Scan DPI | 8 pt print (pixels) | 10 pt print (pixels) | Pixels per page vs 300 DPI |
|---|---|---|---|
| 200 | 22 | 28 | 0.44 times |
| 300 | 33 | 42 | 1 times |
| 400 | 44 | 56 | 1.78 times |
| 600 | 67 | 83 | 4 times |
To check a real scan, open it in an image viewer, zoom to 100 percent and measure the height of a capital letter or digit with the selection tool. If a digit is only 10 or 12 pixels tall, the gaps that separate a 3 from an 8 are a pixel or two wide, and a higher DPI for that page is the fix. If digits are well over 25 pixels and errors persist, resolution is probably not the cause. Look at skew, shadows or faint ink instead.