How to convert bank statements to JSON: schema, methods and validation
For developers, fintech product teams and lending operations: what a good bank statement JSON looks like, how to get there from PDFs and scans, and how to validate the output before your app uses it.

Key takeaways
- Converting a bank statement to JSON means extracting the header, summary and every transaction from a PDF or scan into a structured, machine-readable object.
- A useful schema has account details, statement period, opening and closing balances, and a transactions array with date, description, debit, credit and running balance.
- Methods range from PDF text parsers (digital PDFs only, one layout at a time) to document AI APIs that handle any bank, scans and multi-page tables.
- Always validate the JSON: opening balance plus credits minus debits must equal the closing balance, and each running balance must follow from the previous one.
- Keep amounts as numbers with a fixed sign convention, dates in ISO 8601 and the source page for every transaction.
On this page
To convert a bank statement to JSON, extract the account details, statement period, opening and closing balances, and every transaction from the PDF or scan, then write them into a structured JSON object with a transactions array. For digital PDFs from one bank, a PDF parser can work; for statements from many banks, or scans and phone photos, a document AI tool or API is the practical choice. Either way, validate the result: the opening balance plus credits minus debits must equal the closing balance.
This guide covers a sample JSON schema, the conversion methods compared, a step-by-step process and the checks that make the output safe to use.
Why convert bank statements to JSON#
- Apps and APIs speak JSON. Lending platforms, underwriting models, accounting tools and data pipelines ingest it directly.
- It keeps the structure. Account, period, balances and transactions stay together in one object.
- It's easy to validate. Balances and running totals can be checked in code before anything downstream uses them.
- It scales. Once statements are JSON, analysis, categorization and fraud checks can run automatically.
Typical uses: loan underwriting and income verification, cash flow analysis, bookkeeping and reconciliation, and feeding transaction data to analytics or machine learning models.
A sample bank statement JSON schema#
This is an illustrative schema. Field names differ between tools, but a good output has the same parts:
{
"document_type": "bank_statement",
"bank_name": "First Bank",
"account_holder": "Acme Supply LLC",
"account_number_last4": "4821",
"account_type": "checking",
"currency": "USD",
"period_start": "2026-07-01",
"period_end": "2026-07-31",
"opening_balance": 12450.00,
"closing_balance": 15230.75,
"total_credits": 48200.00,
"total_debits": 45419.25,
"transactions": [
{
"date": "2026-07-02",
"description": "ACH CREDIT STRIPE PAYOUT",
"debit": null,
"credit": 6200.00,
"balance": 18650.00,
"page": 1
},
{
"date": "2026-07-03",
"description": "CHECK 1045",
"debit": 2150.00,
"credit": null,
"balance": 16500.00,
"page": 1
}
]
}
Design choices that save trouble later:
- Numbers, not strings, for amounts and balances, with separate debit and credit fields or one signed amount, never both.
- ISO 8601 dates (YYYY-MM-DD), because statements print dates in many formats.
- Masked account numbers unless you truly need the full number.
- Page reference for each transaction, so a reviewer can find it on the source.
- Confidence scores per field if your tool provides them.
Conversion methods compared#
| Method | Works on | Strengths | Limits |
|---|---|---|---|
| Manual entry into a spreadsheet, then export | Anything | No tools needed | Slow and error-prone; not repeatable |
| PDF text parser (for example, a script with a PDF library) | Digital, text-based PDFs | Free, fully under your control | Breaks on scans; a new parser per bank layout; tables that wrap or span pages are hard |
| Template OCR tool | Scans and PDFs with fixed layouts | Handles scans | A template per bank and statement version |
| Document AI API | Any bank, digital or scanned, multi-page | Handles new layouts, returns JSON with confidence scores | Needs vendor due diligence on accuracy and security |
For a handful of statements from one bank, a parser is fine. For a lending or fintech product that receives statements from hundreds of banks, a document AI API is the only approach that scales.
How to convert bank statements to JSON with document AI#
- Send the file. Upload the PDF or image through the web app, email, or API. Multi-account and multi-month files are split automatically by good tools.
- Extraction. OCR and layout models find the header, summary and transaction table across pages. Docsumo extracts bank statement data with 99% field-level accuracy.
- Review low-confidence values. A reviewer sees uncertain fields on the page and corrects them.
- Validate. Run the balance checks below, automatically.
- Receive JSON. Download it, or receive it by webhook when processing finishes, then load it into your app or data store.
Docsumo's free trial covers 14 days and up to 1,000 pages, with API and webhook access; see pricing.
Validate the JSON before you use it#
These checks catch both extraction errors and edited statements:
- Balance reconciliation: opening_balance + total_credits − total_debits = closing_balance.
- Running balance chain: each transaction's balance = previous balance + credit − debit.
- Totals: the sum of transaction credits and debits equals the statement's summary totals.
- Dates: every transaction date falls within the statement period, in order.
- Continuity: each month's opening balance equals the prior month's closing balance.
A simple check in Python:
from decimal import Decimal
def reconciles(stmt):
bal = Decimal(str(stmt["opening_balance"]))
for t in stmt["transactions"]:
bal += Decimal(str(t["credit"] or 0)) - Decimal(str(t["debit"] or 0))
if t.get("balance") is not None and bal != Decimal(str(t["balance"])):
return False
return bal == Decimal(str(stmt["closing_balance"]))
Failures point to a misread value, a missing transaction or an altered statement. See how to spot fake bank statements.
Storing and securing bank statement JSON#
- Encrypt at rest and in transit, and restrict access by role.
- Keep the source file linked to the JSON for audit and disputes.
- Set retention rules so data isn't kept longer than your policy allows.
- Choose vendors carefully. Docsumo is SOC 2 Type 2, HIPAA and GDPR compliant.
To go further than conversion, read AI bank statement analysis or how to convert bank statements to Excel.
The bottom line#
Bank statement JSON is only as good as the extraction and checks behind it. Use a clear schema with numeric amounts and ISO dates, pick a method that handles the banks and scans you actually receive, and reconcile every statement before your app trusts it.
Frequently asked questions#
How do I convert a bank statement PDF to JSON?
Send the PDF to a document AI tool or API that extracts bank statements. It returns the account details, balances and transactions as JSON, or lets you download JSON from its interface. Validate the balances before using the data.
Can I convert scanned bank statements to JSON?
Yes, but you need OCR. Text-based PDF parsers can't read scans. Document AI tools apply OCR and layout models and return a confidence score per value so you can review uncertain fields.
Why use JSON instead of Excel or CSV?
JSON keeps the nested structure (account, periods, transactions) in one object and is the native format for web apps and APIs. CSV and Excel are better for people reviewing data in a spreadsheet. Most tools export all three.
How should amounts be represented in bank statement JSON?
As numbers, not strings, with a clear sign convention, either separate debit and credit fields or one signed amount field. Include the currency and avoid floating-point rounding in financial calculations by using decimal types in your code.
Is it safe to send bank statements to a conversion API?
Use a vendor with SOC 2 Type 2 compliance, encryption in transit and at rest, and clear data retention settings. Avoid free online converters for customer data.
Sources
- IETF RFC 8259: The JavaScript Object Notation (JSON) Data Interchange Format
- IETF RFC 3339: Date and Time on the Internet (ISO 8601 profile)
First published . Last updated .