Indian bank statement extraction

Indian bank statements arrive from a dozen different banks, each with its own column order, date format, and label style, and many as password-protected PDFs or scanned copies. The transactions still have to land in the ledger. Dynamite Docs extracts transactions from HDFC, ICICI, SBI, Axis, Kotak, and other Indian bank statements, digital or scanned, into rows you reconcile against instead of a PDF you retype.

Try this workflow free or view pricing.

Same transactions, a different layout per bank

Every Indian bank formats the same transaction differently: transaction date and value date, a description laced with branch codes, debit and credit columns, and a running balance, each in its own order with its own labels.
Statements come as password-protected PDFs, scanned copies, and exports with an embedded text layer, so the reliable reading path depends on the exact file you were given.
Retyping transactions is where transposed digits and dropped fees hide, and those mismatches surface later as reconciliation differences nobody wants to chase.
GST cash-flow review needs the same transactions sorted by date with tax-relevant descriptions flagged, which a transcribed statement provides only after a second pass.

How Dynamite Docs handles Indian bank statements

01 — Upload the statement

Digital PDFs from HDFC, ICICI, SBI, Axis, Kotak, and others parse deterministically from their text layer where one is present. Scanned statements are read by the vision model you choose.

02 — The transaction schema is inferred

Transaction date, value date, description, debit, credit, running balance, and UTR or reference are pulled from the layout automatically. No per-bank templates to maintain.

03 — Verify the low-confidence rows

Confidence scores flag the transactions worth a glance, usually a dense description or a faint scan. Corrections become patterns, so the next statement from the same bank extracts cleanly.

04 — Reconcile and review

Export to Excel, CSV, or JSON, or push rows to Google Sheets for reconciliation against your ledger and a cash-flow review of tax-relevant entries.

Document types this workflow handles

Digital statement PDFs — parsed deterministically from the text layer
Scanned statements — read by the vision model you choose
Password-protected statements — unlocked, then parsed normally
Multi-month & multi-account batches — several statements in one queue

What gets extracted from an Indian bank statement

Inferred per layout. A typical statement run yields these fields, each confidence-scored:

Transaction date — 2026-07-28
Value date — 2026-07-28
Description — NEFT DR/UPI/MKTPLG/RECH
Debit — ₹45,000.00
Credit — —
Running balance — ₹2,84,312.55
UTR / reference — N273410992157
Cheque number — 000127
Account (masked) — XXXX 1234
Opening / closing balance — ₹3,29,312.55 / ₹2,84,312.55

A realistic example

A statement from an Indian bank extracts to rows like these, ready for reconciliation against your ledger:

Date	Value date	Description	Debit	Credit	Balance	UTR
2026-07-27	2026-07-27	NEFT DR/UPI/MKTPLG/RECH	₹45,000.00	—	₹2,84,312.55	N273410992157
2026-07-28	2026-07-29	NEFT CR/SALARY/ACME PVT LTD	—	₹1,20,000.00	₹4,04,312.55	N274118009633
2026-07-29	2026-07-29	IMPS DR/CHQ NO. 000127	₹12,750.00	—	₹3,91,562.55	M27349022108

The layout is the obstacle, not the data

Indian statements share the same core fields, transaction date, value date, description, debit, credit, and running balance, but every bank arranges them differently, and some use columns that change order between account types. Because the schema is inferred from the layout rather than matched against a template library, a statement from any Indian bank extracts without per-bank setup. Depending on the bank’s statement layout, a value date may sit beside the transaction date or be missing entirely, and the extracted rows reflect what the document actually prints.

Reconciliation is the real test. Each transaction has to line up against the ledger, and that match depends on exact dates, exact amounts, and UTRs or references you can trace back to. Retyped statements undermine it quietly: a transposed digit in an amount or a dropped fee hides in plain sight and surfaces as a variance at month-end. Statement extraction turns the PDF into rows the moment it is uploaded, so the close starts from clean data instead of a transcription backlog.

GST cash-flow review is the second consumer of the same rows. The same transactions, sorted by date with tax-relevant descriptions flagged, give a working picture of cash movement without a separate pass over the statement. Extraction does the reading once and serves both the ledger match and the review, which is why the field set matters: dates, amounts, descriptions, references, and running balances all in one table.

Begin with the account you reconcile most often. Its layout is remembered after the first run, the second statement from the same bank extracts cleanly, and the per-account cost drops to near zero. For a practice that handles several client firms, that means a morning of reviewing instead of a morning of transcribing, across every bank layout in the client list.

Why bring-your-own-AI matters for statements

A bank statement is sensitive financial data, and which model reads it should be your call. Bring your own keys and pay your provider’s rate with zero markup, lock sensitive statements to no-training providers, or run fully local with Ollama and keep the account detail on your own machines.

Scanned statements are a vision-model problem; clean digital exports are a deterministic one. Pick your own model for the scans and let the free deterministic path handle the exports, so accuracy and per-page cost stay under your control across the client list.

The layout is the obstacle, not the data: HDFC, ICICI, SBI, Axis, and Kotak each arrange the same fields differently, and the schema is inferred per layout, not templated. Per-bank corrections are remembered, so the accounts you reconcile most often cost near zero after the first run.

Questions, answered

Does it handle statements from HDFC, ICICI, SBI, Axis, and Kotak?

Yes. The schema is inferred from the layout, so statements from different Indian banks extract without templates, including date orders, column arrangements, and masked account numbers. Field presence reflects each bank’s statement layout.

Can it read scanned or password-protected statements?

Scanned statements are read by the vision model you choose. Password-protected PDFs are handled once they are unlocked; then the text layer parses deterministically.

Does it extract the UTR or reference with each transaction?

Yes. UTRs, references, and cheque numbers come out as fields alongside date, description, debit, credit, and running balance, so transactions can be traced back to the statement.

Does it prepare GST filings or returns?

No. Dynamite Docs extracts and structures the transactions. GST returns and filing decisions remain with your CA or team, who review the confidence-scored rows before exporting.