How to convert scanned bank statements safely

A scan can be converted, but OCR output is evidence to review—not a trustworthy ledger until every amount and balance has been checked against the image. A converter refusing a scan is protecting you from plausible financial errors, not withholding a convenience.

First, ask for the digital original

The bank's PDF, CSV, OFX, or QIF export is safer than OCR because it contains digital characters rather than pixels. Ask the account holder to download the period again from online banking. Use the text-layer checker before choosing a workflow; test transaction pages, not only a digital cover sheet.

Keep the scanned original unchanged. Record the account, currency, page count, period, opening balance, and closing balance. If pages are cropped, missing, unreadable, or mixed between accounts, obtain a better source before entering data.

If a scan is all you have

1. Keep the original image-only PDF and work on a copy.
2. Use an OCR product that exposes the recognised rows alongside the page image.
3. Compare every date and amount against the image; spot-checking is not enough for a ledger.
4. Check debit/credit direction and minus signs separately from the digits.
5. Rebuild the running balance with the running balance calculator.
6. Use the statement balance checker against every printed balance.
7. Mark unresolved rows and do not call the file verified.
8. Save the reviewed working copy separately and retain the source image.

OCR confidence percentages are not reconciliation. A high-confidence 83.50 can still be wrong when the image says 88.50. The statement's own arithmetic is the useful test.

Review in small batches

Work one page at a time and retain Source page and Source row columns. Confirm the opening or brought-forward balance, enter the page's transactions, then compare the carried-forward or next printed balance. A break is easier to locate before rows from twenty later pages are stacked on top of it.

Descriptions need review too, but amounts, signs, dates, and balances come first. A misspelt payee is inconvenient; a dropped minus sign changes the accounts.

Worked check

A scanned page opens at £1,442.61, shows a debit of £88.50 and a credit of £317.29, and closes at £1,671.40:

£1,442.61 - £88.50 + £317.29 = £1,671.40

If OCR reads the debit as £83.50, it predicts £1,676.40. That five-pound difference proves at least one recognised value is wrong and points you back to the page before the data reaches accounting software.

Red flags that require manual entry

• Faint digits, compression blocks, or marks crossing an amount.
• Handwriting over a printed transaction or balance.
• Cropped edges, missing pages, or a page photographed at an angle.
• Mixed currencies or multiple accounts in one document.
• No printed balance column and no trustworthy period totals.
• Repeated OCR substitutions such as 8/3, 0/6, 1/7, decimal points, and minus signs.
• Ditto marks or dates omitted on subsequent same-day rows.

Manual entry is not failure. It is the honest workflow when the source cannot support automatic extraction. Have a second person review high-value or ambiguous rows where the stakes justify it.

When it goes wrong

Do not edit a later row to force the closing balance. Return to the first running-balance break, compare the image, correct the actual recognition or entry error, and rerun the checks. Keep unresolved differences visible and label the file as draft or unreconciled.

Password protection is a separate problem: if you are authorised, save an unprotected local copy without sending the password to a service. Duplicate overlaps require provenance and review; two equal payments are not automatically one transaction.

Reviewed 24 July 2026. This is a verification workflow, not a claim that OCR output is bank-verified data.