*** September 2026 Major Release ***Read and watch
Document type

Extracting data from bank statements

Every bank designs its own statement, and a US applicant might hold accounts at any of several thousand institutions. A mortgage underwriter reads two or three months of them per application to verify funds. A busy lender sees thousands a month, arriving as portal downloads and phone photographs.

An underwriter needs the account holder, the account number, the statement date and the ending balance. A loan origination system matches those against the application and tests whether the balance covers the down payment and reserves.

Page 1 of a sample Bank Statement, with extracted values outlined
19,571Markdown characters
567parse blocks
278fields extracted
The problem

What makes bank statements hard

Registers run past the page break

A month of transactions carries on across sheets, and a long description wraps onto a second line inside its own row.

One statement, several accounts

A checking account and the overdraft line attached to it each carry their own number, summary and running balance.

The same figure, several places

A total prints in the summary, again as a chart label and again in the daily balance table, in three different shapes.

How it works

Parse, extract, verify

1

Parse

Parse turns the document into reading-order Markdown and a hierarchy of blocks (text, tables, figures), and grounds each block to its exact location on the page.

2

Extract

You define the fields in a JSON schema, and Extract returns their values in a consistent, structured format, each linked back to where it appears in the Markdown.

3

Verify

Each value links back to where it appears, down to the character range in the Markdown, and the page and bounding box in the source document, so every result can be verified.

Worked example

One bank statement, end to end

About this document: Carson Bank's own sample checking statement, published on the bank's website. Six portrait pages: a summary and the start of the register on page 1, the rest of 47 transactions on page 2, then checks, a daily balance table and a linked overdraft account. Page 1 is featured. The account holder and address are the bank's specimen data.

Processing objective: The objective is to read what a lender checks before approving a loan: who holds the account, where it is held, and what was in it on the statement date. The statement date is kept exactly as printed, since the sample's year is a placeholder.

Demonstration fields: Institution, Account holder, Account number, Statement date, Ending balance

The document

4 of 6 pages
  • Page 1 of the sample Bank StatementPage 1shown below
  • Page 2 of the sample Bank StatementPage 2
  • Page 3 of the sample Bank StatementPage 3
  • Page 4 of the sample Bank StatementPage 4

Where each value came from

Page 1 of the sample Bank Statement, with every featured field outlined
Institutionbank_name
CARSON BANK
The region of the sample Bank Statement containing Institution, with the extracted value outlined
extraction_metadata["bank_name"]
{
  "value": "CARSON BANK",
  "page": 1,
  "range": {
    "end": 102,
    "start": 91
  },
  "box": {
    "xmin": 0.06829,
    "ymin": 0.0917,
    "xmax": 0.48123,
    "ymax": 0.11921
  }
}
Account holderaccount_holder
JOHN TEST
The region of the sample Bank Statement containing Account holder, with the extracted value outlined
extraction_metadata["account_holder"]
{
  "value": "JOHN TEST",
  "page": 1,
  "range": {
    "end": 225,
    "start": 216
  },
  "box": {
    "xmin": 0.12714,
    "ymin": 0.24127,
    "xmax": 0.20847,
    "ymax": 0.25276
  }
}
Account numberaccount_number
6547
The region of the sample Bank Statement containing Account number, with the extracted value outlined
extraction_metadata["account_number"]
{
  "value": "6547",
  "page": 1,
  "range": {
    "end": 323,
    "start": 302
  },
  "box": {
    "xmin": 0.74063,
    "ymin": 0.34571,
    "xmax": 0.92616,
    "ymax": 0.35959
  }
}
Statement datestatement_date
July 31, 20XX
The region of the sample Bank Statement containing Statement date, with the extracted value outlined
extraction_metadata["statement_date"]
{
  "value": "July 31, 20XX",
  "page": 1,
  "range": {
    "end": 300,
    "start": 271
  },
  "box": {
    "xmin": 0.0701,
    "ymin": 0.34498,
    "xmax": 0.31311,
    "ymax": 0.36041
  }
}
Ending balanceactivity_summary.ending_balance
6,682.22
The region of the sample Bank Statement containing Ending balance, with the extracted value outlined
extraction_metadata["activity_summary.ending_balance"]
{
  "value": 6682.22,
  "page": 1,
  "range": {
    "end": 801,
    "start": 761
  },
  "box": {
    "xmin": 0.06573,
    "ymin": 0.607,
    "xmax": 0.48846,
    "ymax": 0.62367
  }
}

How to try it yourself

Everything on this page is reproducible. The sample, its schema, and the Parse and Extract API outputs are published. You can repeat the same two calls from whichever surface you already build on.

  • Claude Skilldescribe the job; the agent writes it
  • CLIno code at all
  • MCPexpose ADE docs as an agent tool
  • REST APIany language
  • Pythonlandingai-ade
  • TypeScriptlandingai-ade
Why LandingAI?

Documents into data

Accurate

The best accuracy on the difficult documents other tools get wrong, such as messy scans, complicated tables, checkboxes and handwriting.

Auditable

Every answer cites its sources. Values come back with an audit trail (page, bounding box, character range) so a human can review them.

Agentic

Applies multi-step reasoning, and plans before it acts. Handles documents it has never seen before and adapts to variations.

API-first

Composable APIs that drop into any tech stack and can be called from anywhere. Easy to build on and embed in your pipelines and products.

Affordable

Cost-competitive rates with complete price transparency. Spend controls before you run, and every job reports its exact cost.

Enterprise-grade

Built for production and scale from day one. Fully observable and monitored, running securely in our cloud or yours.

Built for high-volume, high-throughput production

  • Zero data retention
  • Priority rate limits
  • Enhanced support
  • VPC and on-prem deployment

Available on Team and Enterprise plans.

Compare plans
Capabilities

Bank Statement processing highlights

Every institution's layout
Full transaction registers
Registers across page breaks
Wrapped transaction descriptions
Check lists and numbers
Multiple accounts per statement
Deposits and withdrawals
Daily balance tables
Summary and detail figures
Scanned and photographed statements
Bounding box for every value
Zero data retention available
FAQs

Questions, answered

Every transaction. Define the register as an array and each row comes back with its date, description and amount, including rows that continue onto the next page and descriptions that wrap.

No. A schema names the fields you want. Where they sit on the statement is not part of it, so one schema reads an institution it has never seen.

Yes. Model each account as its own object and every figure comes back attributed to the account it belongs to, so a line of credit balance never lands in a checking field.

Every value comes back with its page, a bounding box and the character range in the parsed Markdown. The box can be drawn onto the page image, so a reviewer sees the row it was read from.

A bank statement carries an account holder, an account number, an address and a full transaction history. A schema can ask for the balances alone. Accounts are available with zero data retention, alongside SOC 2 Type II, GDPR and HIPAA compliance.

Start extracting bank statement data

Reliable, structured outputs with full traceability in minutes