Parts 1 and 2 of this series covered the digital-PDF path: 34 rows across four statement layouts, all fields correct, then a GUI and a Windows installer. But plenty of bank statements arrive as scans — image-only PDFs with no text layer at all. This post is about that path: how I tested it, what the result was, and why OCR is deliberately not inside the executables.

The setup

The OCR path is a standalone script, not part of the main converter. It shells out to the tesseract binary, which has to be installed on the system first. On this machine Tesseract was not installed at all, so the first step was installing it — version 5.3.4, with Simplified Chinese (chi_sim) and English language data.

Two things worth stating plainly. First, ocrmypdf was not installed and not used; the pipeline is Tesseract straight to the same line parser the digital path uses. Second, the check script refuses to fake a pass: if Tesseract is missing, it exits with code 2 and prints installation instructions instead of reporting anything as validated.

The test

The test fixture is a clean 300 dpi image-only PDF, rendered from one of the digital fixtures, with no text layer. The command is:

tesseract fixture-s1-scanned.png stdout -l chi_sim+eng --psm 6

Tesseract's output goes through the same row parser as the digital path, and each row is compared field by field against ground truth — date, description, debit, credit, and balance all have to match for a row to count.

Result: 6 out of 6 rows fully correct.

Why OCR is not in the exe

The Windows executables and the installer contain only the digital-PDF path. Tesseract is a separate system binary with its own language data files, not a Python package you can bundle the same way, so the installer does not include it. If you work with scanned statements, you install Tesseract separately and use the OCR script; the digital path keeps working without it.

What this does not prove

The 6/6 result is on a clean synthetic render. It says nothing about real-world scans, and I am not going to pretend otherwise:

  • Real scans are untested. Skew, noise, low resolution, stamps covering text — none of that was in the sample.
  • Real bank statements are untested. Every fixture so far is synthetic. Different banks use different header wording, column orders, summary rows, and multi-page tables.
  • Two PDF shapes are untested. Encrypted PDFs, and image PDFs that mix in a text layer, have not been tried.

One design choice is relevant here: the parser recognises columns by header keywords (date, description, debit, credit, balance, amount, and their Chinese equivalents). If it meets header wording it has never seen, it skips that table rather than guessing. Missing a table is a visible failure; inventing numbers is not.

The Windows side of the OCR setup is also untested by me — the install above ran on Linux. If you set Tesseract up on Windows and it works, or breaks, that is exactly the kind of feedback I want to hear about.

The converter is open source: https://github.com/alapha888/bank-statement-presale

The presale page with the full status, scope and refund terms: https://alapha888.github.io/bank-statement-presale/