Bank Statement Data Extraction
Statements are the one document type with a built-in correctness check: the running balance. If your extracted transactions do not reconcile the opening balance to the closing balance, something was missed, and you know it without a human reading the page.
Discuss your projectFirst, check whether you need this at all
Where a data feed exists, use it. Open banking in the UK and Europe, and aggregators such as Plaid in the US, give you clean categorised transactions with no extraction and no error rate. If the accounts you need are accessible that way and the account holder will connect them, that is strictly better than parsing PDFs and we will tell you so rather than selling you a pipeline.
Extraction is for the cases where a feed is not available: a lending application where the applicant sends statements as PDFs, historical periods that predate any connection, business accounts at banks with no API, foreign accounts outside the aggregator's coverage, or an applicant who will not grant ongoing access to their account but will send a document.
Those cases are common enough to be worth automating, and the honest framing is that this is a fallback done well rather than the first choice.
What gets extracted
Account and period
Account holder, account and sort or routing number, statement period, opening and closing balance. The balances are what make validation possible.
Transaction lines
Date, description, amount, direction, and running balance where the statement prints one. Across page breaks, which is where naive parsers lose rows.
Transaction types
Card payment, direct debit, standing order, transfer, cash, fee, interest — inferred from the description and the bank's own codes.
Counterparties
Normalised from the description, so the same merchant appearing in four different formats is recognised as one.
Categorisation
Against your own category scheme rather than a generic one, since the categories that matter differ between bookkeeping and credit assessment.
Validation built on the balance
This is the strongest validation available in any extraction work, and it is why statements can be automated to a higher confidence than most documents.
- Opening balance plus the sum of all extracted transactions must equal the closing balance. If it does not, rows are missing or misread, and the statement is flagged rather than accepted.
- Where the statement prints a running balance per line, each line is checked against the previous one — which localises the error to a specific row instead of telling you the page is wrong.
- Page continuity: page numbers and carried-forward balances checked, so a missing page in a submitted set is detected.
- Date ordering and period bounds, catching rows picked up from a neighbouring section.
- Duplicate detection where a submitted set has overlapping periods.
- Tamper indicators for lending use: PDF metadata, font inconsistency within the document, and totals that do not reconcile. These are signals for human review, not conclusions.
Common questions
Tell us what you need
Describe the problem and we will come back with scope, timeline, and a rate. No obligation to proceed.
Get in touch