Bank statement PDFs into structured transactions
Every lender, accountant, and bookkeeping product eventually hits the same wall: the customer has a PDF and the system needs rows. Open banking solves this where it is available and the customer consents, but plenty of the market still runs on documents, and statements are among the most stubborn documents there are. I have built this before, in production, at volume.
- Starting at
- from £1,200
- Refresh
- On upload, or scheduled against a document store
- Access
- authenticated
What comes out of it
- Transaction date, description, and amount
- Running balance with arithmetic reconciliation
- Account holder, account number, and statement period
- Transaction categorization where required
- Confidence flags on rows that failed reconciliation
What makes Bank statement PDFs awkward
Statement layouts differ by bank, by account type, and by year, and the same bank will change format without warning. Multi-line transactions, balance columns that only appear on some pages, and continuation rows across page breaks all break naive table extraction. A parser has to reconcile running balances against transaction amounts as a self-check, because that arithmetic is the only reliable way to detect that extraction went wrong.
AussieBankStatements runs about 8,000 pages a month through a dedicated parser per bank rather than a general model, and writes nothing to disk. That design choice is the point: a per-bank parser gives deterministic output you can test and reason about, while a general model gives plausible output that is wrong in ways nobody notices until a lending decision has been made on it.
Why not just use an AI model
Models are good at reading documents and bad at being checkable. For a bookkeeping summary that a human reviews, a model is fine. For a lending decision, an affordability assessment, or anything that ends up in an audit, you need to be able to explain why a number is what it is, and reproduce it exactly next month.
A per-bank parser is deterministic. Given the same document it produces the same rows every time, it can be unit tested against known statements, and when it fails it fails visibly rather than inventing a plausible figure. The balance reconciliation check makes that concrete: if extracted transactions do not sum to the stated closing balance, the document is flagged instead of passed through.
The pragmatic answer is often both, with a parser as the primary path and a model as a fallback for unrecognised layouts, clearly marked as lower confidence so downstream systems can treat it differently.
How it is built
Bank and layout detection comes first, identifying the institution and format version from structural markers rather than asking the user. From there the document routes to the matching parser, which extracts transactions along with the metadata needed to verify them.
Reconciliation then runs as a hard gate. Opening balance plus transactions must equal closing balance, and where it does not the document is flagged for review rather than emitted as clean data. This single check catches the large majority of extraction failures, and it is what allows the output to be trusted without a human reading every statement.
Storage is designed around not keeping things. Processing can run entirely in memory with nothing written to disk, which removes a whole category of compliance obligation, and where retention is required it is encrypted with an explicit deletion schedule.
Scope, cost, and honest limits
Workflow automation starts from £1,200 for one agreed digital document layout with structured output and sample-based acceptance checks. Reusing existing parser infrastructure can make a smaller extension possible. Multiple bank formats, an upload application, OCR and reconciliation workflows need a separate quote.
A full document pipeline with categorization, reconciliation reporting, an API for your product to call, and a review interface for flagged documents is quoted separately against the agreed sources, delivery requirements and acceptance checks.
The honest limit: scanned or photographed statements are meaningfully harder than digital PDFs and accuracy drops. If your customers upload phone photos of paper statements, expect a review step in the workflow rather than full automation, and I would rather set that expectation now than have you discover it after launch.
Where the line is
Requires your own authorised account or API access. I do not build around logins you do not hold.
This is the one category on this site where I do not build anything that fetches data itself. The documents are your customers' own statements, supplied by them with consent, or accessed through your existing authorised connections. I do not build systems that log into banking portals on a customer's behalf using shared credentials, which breaks bank terms and puts the customer at risk. Statements are also highly sensitive personal data, so retention, encryption, and deletion are designed in at the start rather than added later.
MathersLabs is not affiliated with or endorsed by Bank statement PDFs. Work is scoped to publicly accessible data and to compliance with applicable terms and law, and feasibility is assessed per engagement before any fixed price is agreed.
Related work
AussieBankStatements
Bank statement converter and categorizer that never stores what it reads
A custom full-stack app on GCP that parses Australian bank statement PDFs into clean CSV. No AI, a dedicated parser per bank, and nothing written to disk. Built for people who want the extraction without handing their spending history to a chatbot that keeps it.
Questions people ask first
Other sources
Is your source on this list?
Tell me what data you need and where it lives. I will tell you whether it is feasible, what it would take, and whether it is worth building before you commit to anything. Working hours overlap with US Eastern and Pacific.