Skip to main content
FormatOS

Finance · Methodology

Bank Statement PDF to XLSX — Methodology and Limitations

This page explains how the FormatOS bank statement converter works, what it can and cannot do, its known limitations, and how to use it responsibly. Read this before using the output for accounting, tax, loan, or compliance work.

Last updated: June 30, 2026

What this tool does

  • Reads transaction tables from PDF bank statements using PDF.js
  • Extracts date, description, reference, debit, credit, and balance columns
  • Classifies transaction types (UPI, NEFT, ATM, POS, etc.) using rule-based patterns
  • Assigns draft budget categories — editable, not authoritative
  • Reconciles running balances and flags rows where the balance doesn't add up
  • Produces a multi-sheet XLSX workbook and an optional CSV export
  • Masks account numbers in the output (e.g. XXXX1234)
  • Runs entirely in your browser — files are not sent to any server

What this tool does not do

  • Does not generate, alter, or authenticate bank statements
  • Does not connect to any bank or financial institution
  • Does not guarantee 100% accuracy — always review before official use
  • Does not replace official bank records, audited statements, or accounting software
  • Does not provide financial, accounting, tax, or legal advice
  • Does not retain your file, transactions, account number, or balance data after you close the tab
  • Does not work reliably with password-protected PDFs that cannot be unlocked locally
  • Does not support non-tabular statement formats (e.g. single-column summaries, image-only pages with no OCR)

Supported PDF types

Text-based PDFs (preferred)

PDFs exported directly from internet banking portals where the text can be selected and copied. These give the highest extraction accuracy because the PDF already contains machine-readable text.

Best accuracy · Fastest processing

Scanned PDFs (limited support)

Physical statements scanned to image and saved as PDF. The tool can detect these and run in-browser OCR, but accuracy is lower. Scan quality, resolution, contrast, and font choice all affect results.

Lower accuracy · Requires OCR · Needs careful review

How text extraction works

The tool uses PDF.js, an open-source browser library, to read the PDF content stream and extract the text layer. For text-based PDFs, each character's position on the page is available, which allows the tool to reconstruct the table structure.

Text strings near the same vertical position are grouped into a row. Within each row, columns are identified by comparing horizontal positions against the detected column boundaries. The tool looks for a header row (containing words like "Date", "Description", "Debit", "Credit", "Balance") to establish which column maps to which field.

For banks whose header vocabulary doesn't match the built-in patterns, the tool falls back to a generic heuristic: it assumes the first numeric column is debit or amount, the second is credit or balance, and infers direction from context. This generic path is less reliable and produces lower confidence scores.

How OCR works for scanned statements

When a PDF has no extractable text layer, the tool detects this and offers optional in-browser OCR. OCR (Optical Character Recognition) converts the page image into text before table detection can begin.

OCR accuracy depends on: scan resolution (higher DPI gives better results), contrast (faded or low-contrast prints are harder to read), font choice (unusual or ornate fonts confuse character recognition), physical damage (creases, stamps, handwriting, or correction fluid over printed text), and the distinctiveness of characters (the digit 1 and the letter l, or 0 and O, are common sources of error).

Scanned statement output always requires careful human review. Critical values — particularly amounts and balances — should be checked against the original document before any official use.

Fields extracted and how they are populated

Date

Parsed from the statement's date column. Multiple date formats are recognised and normalised to a real Excel date cell. When both transaction date and value date are present, both are extracted.

Description / narration

The full narration text, including UPI references, merchant names, and bank notes. Multi-line wrapped text is reassembled where possible. Very long narrations may be truncated at the column boundary.

Reference / UTR / cheque number

UPI transaction IDs, IMPS/NEFT UTR numbers, and cheque numbers where present. Some banks embed these in the narration rather than a separate column; the tool attempts to extract them using pattern matching.

Debit and credit amounts

Separated into two columns. Statements that use a single 'Amount' column with a CR/DR suffix are split automatically. The direction (debit or credit) is determined by the suffix, column position, and balance movement.

Running balance

Extracted from the balance column. Used for reconciliation: the tool checks that (previous balance + credit − debit) equals the stated balance within ₹0.01. Rows that fail this check are flagged for review.

Transaction type

Rule-based classification using the narration text: UPI, NEFT, RTGS, IMPS, ATM, POS, cheque, salary, EMI, interest, charges, and others. This is a best-effort categorisation, not a definitive classification.

Category (draft)

A suggested budget category based on the transaction type and narration keywords. Always marked as draft, fully editable, and never authoritative. Do not use for tax classification without review.

Confidence

A per-row score that reflects balance reconciliation success, completeness of extracted values, and the reliability of the column detection. Low-confidence rows are highlighted and listed in the Review Flags sheet.

What happens when a value cannot be read

If a value is unreadable — because of a missing column, OCR failure, or an unrecognised format — it is left blank. The tool never fabricates, estimates, or interpolates values. A blank cell means "could not read this value," not "zero" or "not applicable."

Rows with blank amounts or unresolved balance mismatches are automatically included in the Review Flags sheet of the workbook, which lists the row, the issue type, and a suggested action.

Accuracy expectations

Accuracy varies by statement type and quality:

  • Text-based PDFs from major supported banks — typically high accuracy for amounts, dates, and balances. Narration and reference extraction may vary by bank format.
  • Text-based PDFs from unsupported banks — medium accuracy using the generic layout parser. More rows may be flagged.
  • Scanned PDFs with good image quality — lower accuracy than text-based PDFs. Amounts and balances should be verified against the original for every row.
  • Scanned PDFs with poor image quality — significantly lower accuracy. The tool will flag many rows and the output may require substantial manual correction.

No accuracy guarantee is made for any statement type. The tool is designed to be a starting point that reduces manual data entry — not a certified or auditable record. Always verify before official use.

Known failure modes

Multi-column or non-standard table layouts

If a bank uses an unusual column order or groups debits and credits differently from expected patterns, the parser may assign values to the wrong column. Review all rows carefully for any unfamiliar bank.

Scanned or image-based PDFs

Image PDFs require OCR before any data can be read. OCR accuracy drops with low scan resolution, poor contrast, unusual fonts, handwriting, or stamps overlapping printed text. Numbers sharing similar shapes (1 vs 7, 5 vs 6, 0 vs O) are a common OCR error source.

Wrapped or multi-line descriptions

Long narration text that wraps across two printed lines may be joined incorrectly or split into separate rows. The tool attempts to reassemble wrapped text, but complex layouts can produce truncated or merged descriptions.

Large files and browser memory limits

Statements with many pages (typically over 200–300 pages) may be slow or cause the browser tab to run out of memory. Export shorter date ranges from net banking if this happens.

PDF security restrictions

Some PDFs restrict text extraction even when the file is not password-protected. The tool will return blank rows or low-confidence output in these cases rather than fabricate data.

OD and credit card accounts

Overdraft and credit card statements may show negative or decreasing balances that do not fit a standard debit/credit reconciliation model. The running-balance check may flag many rows as low confidence for these account types.

Generic or unknown bank formats

The parser has specific patterns for major Indian banks. Statements from smaller regional banks, NBFCs, or foreign bank branches may fall back to a generic layout heuristic, which is less accurate.

Privacy and file handling

Bank statements contain sensitive personal and financial information. This tool is designed to minimise exposure:

  • All PDF processing runs in your browser using in-page libraries. Your file is not sent to any FormatOS server.
  • The PDF, its text, your account number, transaction descriptions, and balances are not uploaded, stored, logged, or sent to analytics systems.
  • The account number is masked in the output (shown as XXXX1234).
  • The raw text extraction sheet — which shows unprocessed PDF text — is disabled by default and must be explicitly enabled.
  • Excel output cells are protected against formula injection (values beginning with =, +, -, or @ are escaped).
  • When you close the browser tab, all file data and extracted results are cleared from browser memory.

For full details, see our File Handling Policy and Privacy Policy.

Why the output looks different from the original

The XLSX output is structured for analysis, not visual reproduction. It will always look different from the original bank statement. Specific reasons include:

  • Dates are stored as real Excel date values, not text strings — this enables sorting and filtering.
  • Amount columns are stored as numbers, not formatted currency strings.
  • Multi-line narration text is joined into a single cell.
  • Column order may differ from the original statement's layout.
  • Visual styling (fonts, borders, column widths, bank logos) is not reproduced.
  • Additional computed columns (transaction type, category, confidence) are added by the tool.

The output is intended to make the data easier to work with in Excel or a compatible spreadsheet application — not to replicate the visual appearance of the bank's printed statement.

Responsible use

  • Only process bank statements that belong to you or that you have explicit permission to process.
  • Always review the extracted spreadsheet before using it for accounting, tax filing, loan documentation, compliance, or any official purpose.
  • Do not treat the output as a primary record or authoritative source — it is a derived copy, not the original.
  • Do not send actual bank statement files via the Contact form or email. If you need to report a conversion issue, describe the problem without attaching sensitive documents.
  • This tool is not designed and should not be used for manipulating or fabricating financial records.

How to report an extraction issue

If you find a systematic extraction error — a column being misread, a balance reconciliation failing unexpectedly, or a known bank format not being detected — please let us know through the Contact page under "File Conversion Issue."

Include the following if possible (without attaching the actual statement):

  • Bank name and approximate statement period (e.g. SBI, January–March 2025)
  • Whether the PDF is text-based or scanned
  • What went wrong (wrong column, missing rows, incorrect amounts, etc.)
  • A screenshot of the original PDF section and the extracted XLSX row, with any sensitive data removed

Do not email or submit actual bank statement files — describe the problem in text form only.