OCR is required for a scanned bank statement because an image-only scan carries no text layer. The page is a photograph of text, not text, so standard converters that read embedded text tokens return nothing at all.¹ Some scans do arrive with a text layer their scanner produced during capture, which brings its own problem covered below. Conto runs OCR on the image, rebuilds the table structure from pixels, and codes the resulting transactions against the client’s existing chart of accounts before exporting IIF, QBO, or XLSX for QuickBooks. This guide explains why the failure happens, what accuracy to expect on real bank scans, and how to tell a fixable scan from one worth re-requesting.

Table of Contents

• Why Scanned Statements Break Standard Converters
• How to Tell If Your PDF Has a Text Layer
• What OCR Accuracy Looks Like on Bank Scans
• The Fields That Break First
• Improving Scan Quality Before Conversion
• Getting Scanned Statements Into QuickBooks
• When the Statement Includes Handwriting
• Frequently Asked Questions

Why Scanned Statements Break Standard Converters

Standard PDF converters read embedded text tokens and their coordinates. A scanned statement has neither, so the parser finds an empty page and returns an empty file rather than an error.

A digital bank statement, downloaded straight from the bank, stores each character as a text object with a position on the page. Converters read those objects and rebuild rows and columns from the coordinates. It works well, and it is why most converters advertise high accuracy.

A scanned statement works differently. Someone printed the statement, ran it through a scanner or photographed it, and saved the result. Every character is now a cluster of pixels. A parser that expects selectable text tokens with position data has nothing to work with, so the layered extraction approaches described for banking PDFs fall back to reconstructing tables from pixels.¹

This produces the failure that sends most bookkeepers searching for a fix. The converter does not crash. It reports success and hands back a file with headers and no rows. Some tools return only an image rendition of the page with no text elements whatsoever.²

Three client habits produce scanned statements constantly:

• Portal printing. The client opens online banking, prints to paper, then scans the stack for you.
• Phone photos. The client photographs statements on a desk, often at an angle and under uneven light.
• Fax and re-scan. The statement passes through a fax or a photocopier before it reaches you, compounding quality loss at each step.

None of these are unusual. For firms serving older businesses, or any client whose bank feed does not connect, scanned statements are the normal case rather than the exception.

How to Tell If Your PDF Has a Text Layer

Open the PDF and try to select a transaction line with your cursor. If the text highlights, the file has a text layer. If you get a selection box over the whole page instead, the page is an image and OCR is required.

This ten-second test tells you which pipeline the document needs before you waste time on a converter that cannot read it. A second confirmation: press Ctrl+F (Cmd+F on Mac) and search for a dollar amount you can see on screen. No match means no text layer.

A third case catches people out. Some files carry an invisible text layer laid over the image, produced when a scanner ran its own OCR during capture.³ These files select and search normally, so they look digital, but the underlying text came from a low-quality recognition pass. The extracted numbers may be wrong even though the file behaves like a text PDF. If the amounts you pull do not foot to the statement total, suspect this.

What OCR Accuracy Looks Like on Bank Scans

Resolution drives the outcome more than any other single factor. At 150 DPI, character-level accuracy drops below 90% for most engines, and documents scanned below 200 DPI routinely lose 10 to 20% of character-level accuracy.⁴

For high-stakes text extraction the current standard is 300 to 600 DPI, and anything below 300 DPI causes a measurable drop in character recognition accuracy.⁵ The trouble is that you rarely control the scan. The client chose the setting, and many office scanners default to 150 DPI or to a compressed mode intended for email.

Skew compounds the damage. A 5-degree page skew increases word error rate by 10 to 15% for traditional OCR engines, and past 10 degrees the loss can exceed 30%.⁴ A statement photographed at an angle on a desk carries more skew than that.

Character accuracy also understates the practical impact on a bank statement. Character error rates run below 1% on clean printed text,⁵ which sounds close to perfect until you consider that a single misread digit in an amount column changes a number rather than producing an obvious typo. Prose tolerates a wrong character. A ledger does not.

This is why reconciliation matters more than any vendor accuracy claim. A statement that fails to foot against its own printed totals tells you something went wrong, regardless of what the extraction tool reported.

The Fields That Break First

Amount columns and dates fail most often on scanned statements, because OCR confusions that look trivial in text (0 for O, 1 for l, a dropped decimal point) silently change the value of a transaction.

Engineering write-ups on banking PDF extraction group the failure modes into four kinds: characters misread one for another, values landing in the wrong row or column because the detected boxes drift, rows tilting out of alignment when the page is skewed, and compression noise inventing or erasing table rules.¹

Ranked by how much trouble each causes in practice:

1. Amounts. A missing decimal point turns $1,250.00 into $125000. Large enough to notice. A 3 read as an 8 is not.
2. Column assignment. Skew shifts a value one column left, and a debit becomes a credit. The total still looks plausible.
3. Dates. A misread month moves a transaction into the wrong period, which surfaces at close rather than at import.
4. Check numbers. Sequence gaps are the usual tell, and they only help if someone checks.
5. Payee descriptors. The most tolerant field. A garbled descriptor is annoying but visible.

Conto ties extracted transactions back to the source image, so any line can be checked against the pixels it came from. The reconciliation step catches what character accuracy alone hides: whether the extracted transactions actually foot to the printed statement totals. For a fuller treatment of extraction time and error rates on check images specifically, see our analysis of manual check data extraction from PDFs.

Improving Scan Quality Before Conversion

The cheapest accuracy gain comes before conversion, not during it. Asking a client to rescan at 300 DPI in black and white, flat on the glass, costs one email and outperforms any post-processing.

When you can influence how the client sends documents, ask for these in order of impact:

• The original PDF from online banking. Always ask first. Most clients do not realize they can download rather than print, and it removes the OCR problem entirely.
• 300 DPI or higher. The current standard for high-stakes extraction is 300 to 600 DPI.⁵
• Flat on the scanner glass, not photographed. Phone photos add perspective distortion that skews every row.
• Black and white or grayscale, not color. Color scanning adds noise without adding information for text recognition.
• No fax. Faxing drops the page to a low resolution and adds compression noise, which is the combination the resolution and skew figures above both punish.

When you cannot influence the source, which is most of the time, these help:

• Deskew before OCR. Rotation is the single largest driver of column misassignment.
• Convert to grayscale and increase contrast so characters separate from background.
• Crop out the bank’s marketing inserts. They add pages of low-value text that confuse table detection.
• Split multi-account statements into one account per file before extraction.

Some scans are not worth saving. A photograph taken at an angle, in poor light, of a faxed copy will not produce a reliable ledger no matter what tool processes it. Re-requesting the document takes less of your time than reviewing every line of a bad extraction.

Getting Scanned Statements Into QuickBooks

A scanned statement can reach QuickBooks Desktop by either route. OCR the scan, code the transactions, then export Web Connect (.qbo) for the bank feed or IIF for a pre-coded import. Conto generates both, plus XLSX.

The two formats do different jobs. QuickBooks Desktop reads .qbo through its bank feed interface, which means you still match each transaction against the register afterwards. The format carries transaction data only, so it cannot represent category assignments, splits, or class tracking.

IIF carries all three. If Conto has already coded the transactions against the client chart of accounts, IIF preserves that work and you skip bank feed matching entirely. Use .qbo when you want the familiar bank feed flow, and IIF when you want the coding to survive the import. XLSX is there for review before either.

The workflow for a scanned statement looks like this:

1. OCR the image to recover characters and their positions.
2. Rebuild the table structure from the pixel layout, since no coordinates survived the scan.¹
3. Reconcile against printed totals to catch misreads that character accuracy hides.
4. Code transactions against the client’s existing chart of accounts and prior general ledger.
5. Export IIF, QBO, or XLSX and import.

Step four is where scanned statements stop being a conversion problem and become a bookkeeping one. Extracting text from a scan gets you a list of transactions. It does not tell you which GL account each one belongs in. Conto reads the chart of accounts and prior ledger you already keep for that client, learns which account each payee routes to, and applies it to new transactions.

For a comparison of how the major converters handle scanned input, including which ones support it at all, see our bank statement converter comparison for accountants.

When the Statement Includes Handwriting

Handwriting drops OCR accuracy far below anything printed text sees. Recognition falls from 99.9% on clean printed documents to about 64% on cursive samples, which is why handwritten fields still require human verification.⁶

Scanned statements arrive with handwriting more often than you would expect. Clients annotate them. They circle transactions, write account codes in margins, and note which charges are personal. Check images attached to statements carry handwritten payees and amounts.

Two related problems worth separating:

• Annotations on a printed statement. Usually harmless. The printed transaction data still reads normally, and the handwriting sits in the margin.
• Handwritten source documents, such as check images or a check register. These carry the full accuracy penalty and need review.

We cover the recognition problem in depth in handwritten check OCR and the documentation side in handwritten checks in tax prep.

Frequently Asked Questions

Why does my bank statement converter return an empty file? The PDF is almost certainly a scan with no text layer. The converter read the page, found no text objects, and returned an empty result rather than an error.¹ Try selecting text in the PDF: if the whole page selects as one block, you need OCR.

Can I OCR a bank statement myself before converting? Yes. Adobe Acrobat Pro can add a text layer through its Enhance Scans tools. Quality depends on the scan, and the resulting text layer inherits every recognition error, so reconcile the output against the statement totals before trusting it.

What DPI should I ask clients to scan at? 300 DPI. It is the working standard for document OCR, and scans below it show measurable accuracy loss.⁵

Does Conto output .qbo files? Yes. Conto generates Web Connect (.qbo) built against the OFX Banking Specification, plus IIF and XLSX. IIF is usually the better choice when transactions are already coded, because .qbo cannot carry category assignments, splits, or class tracking.

Does Conto work with Xero? No. Conto exports IIF, Web Connect (.qbo), and XLSX for QuickBooks.

Is OCR accurate enough to trust for client books? Character accuracy alone is the wrong test. A 99% character rate still leaves misread digits in amount columns. The question is whether the extracted transactions reconcile against the statement’s printed totals, which is a check you can automate and a claim you can verify.