The statement arrives as a photograph of a page. Somewhere in it are three hundred transactions that a business needs in a spreadsheet — and typing them out is how a Saturday disappears. This pipeline reads the scan and hands back the workbook.
The pipeline runs locally against real bank statements, and its output contains genuine account activity. It is described here and deliberately not screenshotted — the sample workbook holds real financial data belonging to a real person.
The source is a photograph, not a text PDF, so nothing can be extracted without optical character recognition.
A transaction line that OCR mangles becomes a wrong number in a financial record, which is worse than a missing one.
The output has to land somewhere the business already works, which is a spreadsheet — not a dashboard nobody opens.
Scanned statement PDFs are dropped into an input folder; the pipeline picks up whatever is there with no per-file configuration.
Each page is read twice — by direct text extraction where the PDF has a text layer, and by OCR where it does not — so digital and photographed statements both work.
Recognised lines are parsed into dated transactions with debit, credit and running balance, each tagged with the file it came from.
The result is written as a four-sheet workbook: every transaction, a cleaned ledger, spend grouped by category, and a summary.
Every row was read off the source, not from a project brief. Line counts, versions and limits are the ones in the files listed above.
The people who need this already live in spreadsheets — that is where their accountant wants the file and where they will filter, annotate and total it. A web dashboard would be a better demo and a worse tool: it would mean exporting to a spreadsheet anyway, with one more step in between.
Verify: The pipeline writes a single `.xlsx` with four sheets and no other output surface; the sample workbook opens with 264 rows in the Transactions sheet.
Some statements are digital exports with a real text layer; most that arrive from a small business are photographs taken on a phone. Running text extraction where it works and OCR where it does not means one pipeline handles both, instead of failing on whichever kind it was not built for.
Verify: Both pdfplumber and an OCR engine are required dependencies, and each transaction row records the source file it was read from.
The verified workbook is genuine, which is exactly why it cannot be a screenshot. It contains real counterparty names, real UPI identifiers and real balances. Publishing a picture of it to prove the pipeline works would leak somebody’s finances to prove a point about engineering.
Verify: This case study cites row and column counts and the sheet names rather than any transaction content, and no image of the workbook appears anywhere on this site.
This is operated by the business owner, not by a developer with a working Python toolchain. Detecting missing packages and installing them on first run removes the single most common reason a tool like this gets abandoned before it is ever used.
Verify: The pipeline checks each required import at startup and installs any that are missing before continuing.
Not publicly disclosed.
No business outcome has been measured against a stated method and confirmed with this client, so no figure is published. We would rather show you the system and let you judge it than print a number nobody verified.
This build uses the following SheetFlow services:
