Bank statement extraction

A bank statement is a periodic record a bank issues to an account holder, listing transactions, balances, and account identifiers over a given period. Finance and compliance teams process these documents constantly: for loan underwriting, KYC onboarding, expense audits, and fraud investigations. Extracting the data by hand is slow and error-prone, especially across dozens of bank formats and languages. Automated extraction turns a scanned PDF into structured transaction-level data that can feed directly into risk models, ledgers, or KYC onboarding workflows.

Fields to extract

Why this document is hard to process

Bank statements are not standardized. Each bank has its own layout, column order, and terminology for debits and credits, and many banks change their template every few years without warning. A single extraction system will encounter statements from hundreds of institutions, in multiple languages, with fonts, logos, and table structures that share almost nothing in common.

Transaction tables are the core difficulty. They span multiple pages, sometimes with running balances that reset per page, sometimes with subtotals inserted mid-table. Rows can wrap onto two lines when a description is long, which confuses naive OCR into treating one transaction as two. Scanned statements photographed on a phone add skew, shadows, and partial cropping. Some statements still arrive as faxed or photocopied paper, with faint print and handwritten annotations from the account holder or a bank clerk.

There is also a fraud dimension. Bank statements are commonly altered to inflate income or hide overdrafts before a loan application, so extraction that ignores internal consistency (does the running balance actually add up?) misses the point entirely. A system that just reads text without checking arithmetic is not doing real extraction, it's doing transcription. See document fraud detection for how these checks work in practice, and OCR vs VLM for why layout-aware models handle this better than plain OCR.

How Sygnet processes it

Sygnet first classifies the incoming file (bank statement, versus payslip or invoice, for example) then infers the document's specific layout rather than forcing it into a fixed template. Each field is extracted with a confidence score, and every value carries field-level provenance: a bounding box pointing back to the exact location on the page, so a reviewer can verify a number in seconds instead of re-reading the whole statement.

Extraction runs the validation rules described below automatically: balance arithmetic, IBAN checksums, date ordering. Where a rule fails or confidence drops below a threshold, the transaction or field is flagged for human-in-the-loop review, rather than sending the entire document back for manual re-entry. This keeps human attention focused on the small fraction of cases that actually need it.

For workflows that combine multiple documents, such as verifying income from a statement against a payslip or a loan application, Sygnet applies cross-document validation to catch mismatches between sources. Output is delivered as clean structured output, ready to post to a ledger or risk engine, with a full audit trail of what was extracted, from where, and with what confidence. Data handling follows the practices described on security and compliance.

Validation rules worth applying

• Recompute the running balance line by line: opening balance plus each transaction amount must equal the next stated balance.
• Verify the IBAN checksum (mod 97) and confirm the country code matches the bank's known jurisdiction.
• Check that every transaction date falls within the stated statement period, with no dates before the opening or after the closing date.
• Confirm the debit/credit sign convention is applied consistently across the whole document, not just the first page.
• Cross-check the statement issue date against the period end date: issue date should come after, never before.
• Sum all debits and credits separately and confirm they reconcile to the difference between opening and closing balance.
• Flag statements where page numbering is discontinuous or a page appears to be missing.
• Compare account holder name and account number against other documents in the same case file for consistency.

FAQ

Can extraction detect an altered bank statement?

It can catch the most common signs: broken balance arithmetic, inconsistent fonts or spacing within the transaction table, and mismatched running totals. It cannot prove intent or catch every manipulation, particularly a well-made forgery with correct arithmetic. Combining automated checks with document fraud detection techniques and selective human review gives the best coverage.

How does extraction handle statements in different languages?

Layout-aware models trained on multilingual documents handle labels like "débit," "crédit," "solde," or "balance" without needing a separate template per language. The system maps these to a common schema (transaction amount, running balance, and so on) so downstream systems receive consistent field names regardless of the source language.

Should we build this in-house or use a vendor?

It depends on volume and how many distinct bank formats you handle. Building a robust parser for hundreds of bank layouts, plus fraud checks and review tooling, takes real engineering time and ongoing maintenance as banks change templates. See build vs buy IDP for a fuller comparison, and pricing if you want to estimate cost against volume.