bankstatementparser documentation

The canonical, versioned API reference for each package lives in its own GitHub README — this hub orients you across the suite, explains the shared concepts, and points you to the right README when you need method signatures and options.

Read this page top to bottom for the mental model: the formats it reads, the single Transaction model everything collapses into, the two pipelines that do the work, the privacy defaults, and how to export. Then follow the links to the package you actually need.

Core concepts

A handful of ideas explain the whole suite: the formats it reads, the model they all become, the two pipelines that produce that model, the privacy posture, and how you get data back out.

Formats

The parser reads CAMT (ISO 20022), PAIN.001, SWIFT MT940 and MT942, BAI2, OFX/QFX, CSV, and PDF — both digital and scanned. Each has its own dialect and quirks, but all of them are normalised into the same output. For a format-by-format breakdown of origins and parsing behaviour, see the formats reference.

The Transaction model

Whatever the source format, every statement line collapses into one typed Transaction record. Generically, a transaction carries a booking date, a value date, an amount, a currency, a counterparty, a reference, and a type (for example credit or debit). Because the shape is stable, downstream reconciliation, ledgers and exports are written once rather than per format. Field names and exact types are documented in the core package README.

The two pipelines

Structured formats take the deterministic pipeline: explicit, rule-based parsing that is repeatable, testable and auditable line by line. PDFs take the second pipeline — a local LLM extracts transactions from the text, and a local vision model handles scanned pages as a fallback. The structured path never invokes a model.

Privacy

Processing is on-device by default. Deterministic parsing is entirely local, and the PDF pipeline uses local models (Ollama by default). Your statements only reach an external provider if you explicitly opt in and configure one. See the privacy statement for details.

Exporting

Once you have a list of transactions, the XLSX writer turns them into a clean, formatted .xlsx workbook for analysts and auditors. It is a separate package so the core parser stays dependency-light; install it alongside the core when you need spreadsheet output.

Support & contributing

Found a bug, or want to add a format or feature? Open an issue or a pull request on GitHub — contributions across the suite are welcome. For anything else, get in touch through the contact page.