Open the Bank Statement Parser and upload your statement — a PDF (digital or scanned) or an image. When you click Parse, the tool gets the text locally: for a born-digital PDF it reads the embedded text layer with pdfjs and keeps each text item’s X and Y position, then a rule-based engine clusters those items into rows by their Y coordinate and works out where the date column and the right-aligned debit, credit and balance columns sit by clustering the right edges of the numeric tokens. For a scanned page or an image it renders the page and runs tesseract.js OCR, then parses the line text with date and amount heuristics. The reconstructed transactions appear in an editable table — date, description, debit, credit and balance — alongside a summary (count, total debits and credits, opening and closing balance). You can fix any mis-parsed cell, add or remove rows, then export a real two-sheet .xlsx (via exceljs), a CSV (via papaparse), or copy the table straight into Excel or Google Sheets.

The Bank Statement Parser runs completely client-side. The PDF text layer is read with pdfjs and any scan or image is recognised with tesseract.js — both libraries load from the app’s own bundle, with no server, no API, no AI and no CDN call for your document — and the page works offline once cached. The file you upload never leaves the page; nothing is sent, logged or stored. That is the key difference from cloud “PDF bank statement to Excel” converters, which upload your file to their servers — exposing your account number, balances and every transaction, and sometimes using the data to train models. Because your statement stays on the device, the tool is safe for confidential bank statements, and only the .xlsx or CSV you choose to export ever leaves the page.

Each reconstructed transaction has five fields: the date, the description (the narration / payee, with wrapped lines joined back together where possible), the debit (money out), the credit (money in) and the running balance. The engine handles the common layouts — separate debit and credit columns, a single signed amount column, and Dr/Cr suffixes — and normalises amounts across US (1,234.56) and European (1.234,56) formats, treating parentheses and a trailing minus as debits. Above the table is a summary: the number of transactions, the total debits and total credits (summed from the rows, updating live as you edit), and the opening and closing balance (detected from labelled summary rows, or inferred from the first and last balance). The amounts in the exported .xlsx are written as real numbers so they sum correctly, with a separate Summary sheet.

Accuracy depends heavily on the statement. A clean, born-digital PDF reconstructs very well because the tool has the real column geometry from the text layer, whereas a low-quality scan or photo relies on OCR (which misreads characters) and an unusual layout can defeat the column inference. Crucially, a bank statement is text at coordinates rather than a real table, and bank layouts vary enormously — wrapped multi-line descriptions, merged columns, summary rows, separate debit/credit vs a single signed amount — so rows and amounts will sometimes parse wrong: a debit can land in the credit column, a balance can be read as a movement, a description can split, or a row can be off by one. That is why every cell is editable. Use it to do the bulk of the typing and to keep confidential statements on your device, but review every row and verify the totals and the closing balance against the figures printed on your original statement before you rely on it for bookkeeping, reconciliation, a loan application or taxes. It is not an AI, not an accountant, and not a substitute for checking the numbers.