Skip to content
user@convertitive:~$convertitive

Bank Statement to Excel Converter

The only converter that checks its own math before handing you the file.

Bank statement PDFs are the hardest table-extraction case in finance, and it isn't close. Most statements print debit and credit as two separate columns, or merge them into a single signed amount column — a naive parser that assumes one shape breaks on the other. Transaction descriptions routinely wrap across two to four lines, and a layout-based extractor (one that follows ruled lines and x-coordinates rather than column meaning) splits each wrapped line into its own phantom row, quietly duplicating transactions. Scanned statements add a third failure mode: OCR engines confuse S/5 and l/1/Iin amount fields, turning a real number into garbage silently. Extract's pipeline is semantic, not geometric — it identifies what a column means(a date, a balance, a debit) rather than where it sits on the page, joins wrapped description lines back into one cell, and flags any digit-like character it can't confidently parse instead of guessing.

./extract

Reconciled bank statement exports

Upload a statement and see the reconciliation verdict before you pay for anything — opening balance plus credits minus debits, checked row by row against the printed running balance.

How to use

  1. Upload the statement PDF

    Drop your bank or credit-card statement in. The first page extracts free so you can see the column shape (debit/credit or single amount) before signing in.

  2. Review the reconciliation verdict

    Extract re-derives the closing balance from the opening balance plus every credit minus every debit, and compares it against the statement's own printed closing balance. Rows that don't add up are flagged individually.

  3. Fix anything flagged

    OCR-ambiguous digits, rows with a mismatched running balance, and any cell the model couldn't confidently type are highlighted inline — correct them in place before export.

  4. Process every page and export

    Sign in (free — two full exports included) to run the remaining pages, then download a typed .xlsx or .csv where SUM() works immediately.

  5. Repeat per statement for multi-month batches

    Each monthly statement is its own document with its own opening/closing balance, so a 12-month backlog is 12 separate uploads — each gets its own reconciliation verdict, not one blended across months.

Frequently asked questions

Does it work on scanned (photographed or faxed) statements?
Yes, with a caveat: scanned pages have no digital text layer, so extraction runs through OCR first, and the tool marks the page "wasScanned" so you know it's working from image recognition rather than embedded text. Ambiguous characters — especially the classic S/5 and l/1/I amount confusions — are flagged rather than silently resolved, and the reconciliation check will usually catch a bad OCR digit anyway, since it throws off the running balance.
Does it detect debit/credit columns vs. a single signed amount column?
Yes. The extractor targets date, description, reference, debit, credit, and balance columns, but only splits debit/credit into two columns when the statement actually prints it that way. If your bank uses one signed "amount" column instead, it extracts that single column rather than forcing a split that doesn't exist on the page.
Is my financial data private, and is it deleted afterward?
Files are processed on encrypted infrastructure in the EU and deleted automatically one hour after export — see the privacy policy for the full retention policy. The free first-page preview never requires an account.
What happens if the reconciliation check fails?
You still get the extracted table — reconciliation is a verdict, not a gate. Rows where the running balance doesn't match the credits/debits the model read are flagged individually, so instead of re-checking every row by hand, you check the handful that were actually flagged. A failed reconciliation usually points to one misread digit, not a systemic problem.
Can I batch a full year of statements at once?
Each statement PDF is uploaded and reconciled separately, since each one carries its own opening and closing balance for its own period. A 12-month backlog means 12 uploads, but each takes under a minute once you know the column shape, and each gets its own independent reconciliation verdict.
What column headers end up in the Excel file?
Whatever the statement actually uses: date, description, reference, and either debit/credit or amount, plus balance — extracted by meaning, so a merged two-line description keeps its full text in one cell instead of splitting across two rows.
Does it handle credit-card statements the same way as checking accounts?
Yes — the same bank-statement extraction targets apply to credit-card statements, which almost always use the debit/credit or single-amount shape and carry a running balance the reconciliation check can verify against.

About

Semantic extraction vs. geometric extraction

A geometric extractor reads a PDF's ruled lines and character x-coordinates and reconstructs a grid from them — it's fast and works fine on simple tables, but a bank statement routinely breaks the geometry: a description that wraps to a second line has no ruled boundary telling the parser "this is still the same row," so it gets read as a new row with blank date/amount cells. Extract's pipeline instead asks a vision model what each column means — this is a date, this is a running balance — and reconstructs rows by that meaning, joining wrapped lines back into a single cell. The reconciliation verdict (opening balance plus every credit minus every debit should equal the closing balance) is the same technique a human bookkeeper uses to sanity-check a statement, run automatically on every extraction so a misread digit surfaces as a flagged row instead of a silent error two clicks later in a spreadsheet.

A real scenario: clearing a 12-month statement backlog before a tax deadline

A freelance bookkeeper takes on a new client in tax season with twelve months of PDF statements from three different banks, none of which use the same column layout — one prints debit and credit as separate columns, one uses a single signed amount column, and one is a scanned copy from a bank that stopped mailing statements years ago. Retyping 12 months by hand across three formats is a day of work with a high error rate on the scanned file alone. Uploading each month gets a typed table with the correct column shape auto-detected per bank, and the reconciliation verdict tells the bookkeeper in seconds which of the twelve is worth a manual look — instead of eyeballing all twelve for a single mistyped balance.

Sources & references

Authoritative references behind the math, constants, and tables on this page. Verified by Buğra Sözeri on the dates shown and re-checked at every deploy.