Skip to content
Ztract
Bank & credit card statements

Every transaction, every balance, every page.

Bank name, account holder, IBAN, currency, opening and closing balances, plus every dated transaction with debit, credit, and running balance — reconciled across multi-page statements.

Live demo

See it on a real document.

Click a field on the right and we'll highlight where it came from on the left.

Click any field or any boxed region to link them.
Bank Statement — page 1

Extracted fields

Transactions

Date Debit Credit Balance Description

Sample data. Real engine output.

Overview

What is bank statement data extraction?

Bank statement data extraction turns multi-page PDFs of transaction history into clean, reconcilable structured data. The use case sits at the heart of loan underwriting, cash-flow forecasting, forensic accounting, and any consumer app that aggregates accounts across institutions that don't expose an Open Banking API. Done by hand it's an hour of typing per statement; done with regex it breaks the moment a bank tweaks its layout.

On a typical statement, Ztract extracts the bank name, account holder, account number, and IBAN; the currency and statement period; the opening and closing balance; the summary total debits and total credits; and the full transactions table with date, description, debit, credit, and running balance for every line. The sample above is a 15-transaction HSBC euro account — balances reconcile to the closing total exactly because nothing was dropped or misaligned across the page break.

Statements that run 20+ pages are the norm. Column headers repeat at the top of each page, summary blocks shift between formats, and pending vs cleared transactions live in different sections. Ztract keeps the transaction order intact, deduplicates the repeated headers, and tags pending lines so downstream reconciliation doesn't double-count. Multi-line transaction descriptions — common on wire transfers and SEPA credits — stay attached to the right row.

Hard parts

Where this gets tricky.

The reasons this doc type is harder than it looks — and how we handle them.

  • Tables that span 20+ pages

    Statements run long. Column headers repeat on every page; we keep columns aligned and transactions in chronological order across the entire document.

  • Multi-line transaction descriptions

    Wire transfers and SEPA credits carry two or three lines of memo. We keep the lines together as one transaction rather than splitting them into orphan rows.

  • Foreign-currency transactions

    A USD account with EUR purchases: both the booked-currency and the local-currency amount come back distinctly, with the exchange rate when the statement prints it.

  • Pending vs cleared

    Pending transactions live in their own section with their own format. We tag them so downstream reconciliation doesn't double-count a transaction that hasn't settled yet.

Who uses it

Workflows this lands in.

  • Loan underwriting

    Pull 12 months of statements into a reconciled cash-flow view without ops staff retyping every line.

  • Budgeting apps

    Categorize transactions across institutions that don't expose an Open Banking API — no PDF-uploaded-then-typed step.

  • Forensic accounting

    Trace funds across statements and parties with every value anchored to its source page for audit defensibility.

FAQ

Common questions.

Does Ztract handle multi-page bank statements?
Yes. The engine stitches the transactions table across page breaks back into a single array, preserving date order. Column headers that repeat on each page are deduplicated, and totals that appear only on the cover or last page are still mapped to the right field.
What about foreign-currency transactions?
When a statement shows both a local-currency and a booked-currency amount for one transaction (e.g., a USD account-holder making a EUR purchase), both values are returned distinctly. The exchange rate is captured when the statement prints it.
Can the extracted balances be reconciled?
Yes. Opening balance + credits − debits should equal closing balance. Ztract returns the engine's view of all four; if the math doesn't add up, per-field confidence scores flag the suspect rows so a reviewer can investigate before pushing data downstream.
Does bank statement parsing work for non-English banks?
Yes. The schema (date / debit / credit / balance / description) is consistent regardless of layout language. We've tested statements in English, French, German, Spanish, Portuguese, Japanese, Korean, and simplified Chinese.
What output formats are available?
JSON, CSV, or Excel. The transactions array typically becomes a multi-row sheet or a flat CSV; header fields like IBAN, opening_balance, and closing_balance are returned as scalars in a separate header block.

Try it on your own document.

Start free with 30 pages. No credit card, no subscription, no setup.