OCR pages per minute has no single honest figure, because speed depends on the scan, not only the software. Resolution, the number of recognition languages, how dense the layout is and the quality of the paper all change the time per page. Measure your own scanned statements with a timed batch and treat any advertised figure as a best case.
How many OCR pages per minute is realistic for scanned statements?
A realistic OCR rate is the one you measure on your own statements, not a vendor's headline. OCR, optical character recognition, turns a picture of a page into text. A clean, straight, text-light page recognises quickly. A crowded bank statement with small type, tables and stamps takes longer per page.
Advertised speeds are usually measured on easy pages: one language, clear print, generous margins. Your statements may share none of those traits. The useful question is how long your batch takes and whether its output needs fixing afterwards.
Timing a sample batch
The worked example below shows the method. All values are made up for illustration, not results from any tool.
| Example run | Pages | Time | Pages per minute | Pages needing fixes |
|---|---|---|---|---|
| Greyscale, 300 dpi, English only | 10 | 2 min 0 s | 5.0 | 0 |
| Colour, 600 dpi, English only | 10 | 4 min 10 s | 2.4 | 0 |
| Greyscale, 300 dpi, English and Spanish | 10 | 2 min 50 s | 3.5 | 0 |
| Black and white, 150 dpi, English only | 10 | 1 min 20 s | 7.5 | 3 |
To run your own test:
- Pick ten pages that look like your real work, including a dense one and a faint one.
- Time the full run from the start of the upload to the finished file.
- Divide pages by minutes.
- Check each page's amounts against the paper and count the pages that needed a fix.
The last column matters as much as the speed. A fast run that leaves three pages to correct by hand is slower overall than a steady one that needs no fixing.
Scan resolution and OCR time per statement page
Higher scan resolution makes each page a larger image, so OCR takes longer to process it. Too low a resolution is also a problem, because small digits blur and recognition errors rise. For printed statements, a moderate resolution in greyscale is usually the best balance of speed and accuracy.
The guide to improving Tesseract OCR quality, from the open-source Tesseract project, says the engine works best on images of at least 300 dpi. It also warns that line detection gets much worse when a page is too skewed, so a crooked scan can cost accuracy no matter how fine it is.
Resolution also drives file size. A full-colour 600 dpi scan can weigh many times more than the same page at 300 dpi in greyscale, which slows the upload before OCR even starts. Why a PDF gets so large explains where that weight comes from, and fixing a scanned PDF that is too large shows how to bring it down without losing readable digits.
Do extra OCR languages lower pages per minute?
Extra recognition languages can lower pages per minute, because the engine compares what it sees against more character sets and word lists. Use only the languages your statements actually contain. An English-only statement gains nothing from a second language and may run slower with one switched on.
Tesseract's command-line usage guide shows how to combine languages with a flag such as -l eng+deu. It also notes that OCR time and output can differ depending on the order in which the languages are listed. If a statement mixes languages, put the main language first and test whether the order changes the result.
Statements from banks abroad often mix a local language with English headings. For those, two languages may be worth the extra time, since a missing language can turn accented payee names into junk.
Dense statement layouts that slow OCR page speed
Dense layouts slow OCR because each page holds more characters and more structure to work out. A statement page with fifty narrow transaction lines, running balances, reference codes and a footer of fine print takes far longer than a cover letter with a few paragraphs. Speed varies from page to page within one statement.
Watch for these page types in a batch:
- Transaction pages packed edge to edge. More text per page means more time per page.
- Pages with stamps, signatures or handwriting. The engine tries to read the marks and may slow down or produce noise.
- Faint or uneven backgrounds. Recycled paper and faded thermal print make it harder to separate text from the page.
- Blank or near-blank pages. They are quick but still count as pages, which inflates your page total without adding data.
Blank backs are a common hidden cost. A duplex scanner captures both sides of every sheet, so a ten-sheet statement becomes twenty pages. Scanning a double-sided bank statement covers how to drop the empty backs before they reach OCR.
When faster OCR pages per minute costs you accuracy
Faster OCR costs accuracy when the speed comes from a weaker input, such as low resolution, black-and-white thresholding of faint print, or skipping a language the page needs. The rate improves, but misread digits rise, and every misread amount is a correction you make by hand later.
Do not chase speed in these cases:
- Amounts in small type. Dropping the resolution to save time can merge a decimal point into the digit beside it.
- Faded statements. Pure black and white can erase light characters entirely.
- Records you will rely on for taxes or lending. A minute saved is not worth a wrong balance.
A balance check is a good guard. When the opening balance plus every transaction does not reach the closing balance, a digit was misread somewhere. FastBankConvert, which is getting ready to open, is built to tell you before download when a statement's balances don't add up, and it expects scanned statements to take longer than digital ones. You can join through Get started to hear when trial conversions open.