How to extract transactions from a PDF bank statement

Two kinds of PDF, two different problems

A statement downloaded from online banking is almost always a born-digital PDF: the text is stored as text, with a position for every character. Software can read it exactly, no guessing involved. A scanned or photographed statement is a picture, and reading it means optical character recognition, which introduces a second layer of uncertainty on top of layout.

This page, and this converter, are about the first kind. If you can download the statement from the bank’s site rather than scanning a paper copy, extraction quality starts near-perfect at the character level. The hard part is not reading the characters. It is deciding what they mean.

Convert a statement now

From characters to a table

A PDF has no concept of a table. It knows that the characters 0, 3, slash, 1, 4 sit at particular coordinates on page 2. Extraction rebuilds the structure: characters cluster into rows by their vertical position, rows cluster into columns by horizontal alignment, and each column gets classified by what it contains. A column full of date-shaped strings is the date column. Right-aligned number columns are amounts or balances. The wide text in the middle is the description.

Real statements complicate every step. Descriptions wrap onto second lines that must merge upward. Tables break across pages with repeated headers. Some banks print one signed amount column, others split withdrawals and deposits, others mark debits with a trailing minus or wrap negatives in parentheses. Date formats differ, and a statement full of dates like 03/04 cannot even prove which number is the month without more evidence.

How extraction errors are caught: the balance chain

Here is the useful fact about bank statements: they carry their own answer key. Most checking statements print a running balance beside every transaction, and every statement prints at least an opening and closing balance. If extraction read every row correctly, previous balance plus amount equals the printed balance on every single row. If a digit was misread, a sign was flipped, or a row was dropped, the chain breaks exactly there.

This converter runs that check on every conversion. It also uses the chain in reverse: when a bank prints unsigned amounts, the balance movement proves which rows are money in and which are money out, so sign conventions never depend on guesswork. When the statement prints no balances at all, the export says Unverifiable rather than implying a check that never ran.

What you get out

The output of extraction here is not a raw dump but an editable table: date, description, amount, and balance where the statement printed one, each date normalized, each amount held as exact cents. Above it sits the reconciliation result, from Verified row-by-row to Reconciliation failed with the disagreeing rows marked, so you can correct a row and watch the check rerun live.

From there, export to QuickBooks Online CSV, Xero CSV, or a generic CSV with balances for spreadsheet work. Everything described on this page runs inside your browser tab: the PDF is parsed locally and never uploaded.

Multi-account statements and wrapped descriptions

Two layout habits cause most of the subtle failures. Combined statements put checking and savings, or several sub-accounts, in one PDF, each section with its own opening and closing balance. Extraction has to detect the section boundaries and check each account against its own balances; summing everything against one total would hide a broken section inside a passing file. This converter reconciles each detected account section separately and stamps each one.

Wrapped descriptions are the second habit: a long payee line continues onto a second row with no date and no amount. Naive row logic reads that as a new transaction or loses it entirely. The safe rule is strict: a continuation line must have no date-shaped and no amount-shaped token anywhere before it merges upward, so a real transaction row can never be silently swallowed into the description above it.

When extraction should refuse

Good extraction knows its limits. A statement using European decimal commas, an image-only scan, or a layout the classifier cannot read with confidence should produce a refusal or a flagged result, never a silently wrong table. The design rule this tool follows: every conversion ends either verified against the statement’s own math or visibly flagged. Silent errors are the one unacceptable outcome, because a wrong number that looks right is the most expensive thing a converter can produce.

Frequently asked questions

Why do converters struggle with some banks and not others?

Every bank lays out statements differently: column order, sign conventions, date formats, wrapped descriptions. Generic extraction handles most layouts; balance checking catches the cases it gets wrong instead of letting them through silently.

Can transactions be extracted from a scanned statement?

Not by this tool today. Scans need OCR, which adds a layer of character-level uncertainty. This converter reads born-digital PDFs, the kind downloaded from online banking, and says so honestly when a file has no text layer.

How do I know the extracted numbers are right?

The converter re-adds every transaction against the balances printed on the statement. Rows that tie out are verified by the statement’s own math; rows that do not are flagged with both numbers shown.

What does Unverifiable mean on an export?

The statement printed no running balance, totals, or daily balances to check against, so no verification was possible. The export still works; the stamp just refuses to imply a check that did not happen.

Does the PDF leave my computer during extraction?

No. Parsing happens in your browser tab. You can watch the Network tab during a conversion and see that no request carries the document.