DEV Community

alapha888
alapha888

Posted on

Bank statement PDFs to CSV, part 6: what this converter has not proven yet

Parts 1 to 5 of this series built the case for a small converter: 34 rows across four statement layouts, all fields correct; a GUI and a Windows installer; a scanned-PDF path through OCR; a CSV output with an audit trail. This post is the other half of that case — everything the converter has not proven yet. If you are deciding whether to trust it with a real statement, this is the list that matters more than the first five posts.

1. No real bank statement has been tested

Every number so far comes from statements I built myself: four digital layouts (12, 8, 8, and 6 rows) and six clean synthetic scan pages. The parser recognises columns by header keywords, and banks differ in header wording, column order, summary rows, and multi-page tables. A layout whose wording the parser has never seen is skipped, not guessed at — that is the safe failure mode, but it is still a failure for that statement. The 34/34 result says the converter handles the four layouts I built. It says nothing about the fifth layout I have not seen. What would close this: converting real statements from several banks and reporting the row counts, misses included.

2. No real Windows machine has run the installer

The installer is real — Inno Setup, about 85.6 MB, bundling the CLI exe (about 41.2 MB) and the GUI exe (about 44.0 MB), installing to Bank Statement Converter with Start Menu shortcuts for both and an optional desktop shortcut for the GUI. It compiled clean on CI (run 42246793629, 3 minutes 20 seconds) after one first-run failure: a Flags: checked line in the [Tasks] section that Inno Setup 6.7.1 rejects, fixed by removing it. But "compiles on CI" is not "installs on a machine". The GUI window was opened once on a CI runner and left running for 15 seconds with no traceback — that is a smoke test, not a spot check. Nobody has yet downloaded the setup file on a real Windows machine, run it, and double-clicked both installed shortcuts. What would close this: that exact check, on a real machine, with the result reported.

3. The scanned path is unproven on Windows

OCR works on Linux in my tests: tesseract 5.3.4, Chinese plus English, 300 dpi synthetic scan pages, 6/6 rows with all fields correct. None of that transfers to Windows automatically. Tesseract is not bundled in the installer and not in either exe — a scanned PDF needs a separate tesseract install, which the installer does not provide, and the steps for installing tesseract on Windows have not been tested here. A user with a scanned statement on Windows currently has a documented gap, not a working path. What would close this: installing tesseract on Windows, running a scanned statement through the installed GUI, and reporting what broke.

4. Encrypted PDFs, mixed PDFs, and bad scans are untested

Three inputs the converter has never seen: encrypted PDFs, image PDFs with a partial text layer, and heavily degraded scans. The first version's stated scope is digital PDFs and ordinary scanned statements; badly degraded scans are explicitly out of scope. But "out of scope" is a design decision, and the boundary has not been probed — I do not know where ordinary ends and degraded begins. What would close this: a small set of awkward inputs, run through the converter, with the failure modes written down instead of assumed.

5. There is no auto-update

Upgrades mean re-running a newer installer. That is a deliberate choice for a first version, not an oversight, but it has a consequence worth stating: a user who installs 1.0.0 will not be told 1.0.1 exists. For a tool that handles financial documents, a silent old version is a real risk, and the fix is either an update check or a clear statement at install time. What would close this: either a minimal update check or an explicit note in the installer that none exists.

What this list is for

None of these gaps makes the five earlier posts wrong. The extraction logic, the GUI, the installer build, the OCR path on Linux, and the CSV format are all as described, with the numbers to back them. But a tool is not done when its happy path works; it is done when its failure modes are known. This list is the work between "built" and "done", and it is also the reason the series pauses here — the next post worth writing is one that closes an item on this list with evidence, not another post about what already works.

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/

Top comments (0)