.xlsx · local conversion · balance-verified
PDF bank statement to Excel
A statement PDF is not a table — it is text placed at coordinates. That is why an ordinary PDF-to-Excel converter hands you one long column. This one rebuilds the table from the geometry, then proves it worked by checking the running balance.
Drop your bank statement here
PDF from online banking, or an OFX / QFX export. Click to choose, or paste with Ctrl/⌘+V.
Text-based PDF up to 60 MB / 200 pages, or .ofx / .qfx
Why generic PDF to Excel tools fail on statements
Money is right-aligned
806.84 and 15.00 end at the same x position but start at different ones. A converter that looks for whitespace gaps sees a different column boundary on almost every row.
Descriptions wrap
POS DEBIT TERMINAL 0091 usually sits on the line below the merchant name, with no date. Treated literally, it becomes a transaction of its own with no amount.
Headers repeat mid-table
Every page reprints "DATE DESCRIPTION AMOUNT BALANCE". On a three-page statement that is three phantom rows in the middle of your data.
Amounts are ambiguous
Is 88.50 a debit? On some statements yes, on others it is a credit. The minus sign is not printed — the column it sits in carries the meaning.
How this one rebuilds the table
- Rows from baselines. Every text run is grouped with the runs that share its vertical position, with a tolerance that scales with the font size — so a large-print statement does not merge lines and a dense one does not split them.
- Columns from the numbers, not the whitespace. Amounts are right-aligned, so their right edges cluster tightly even when the values are different widths. That gives exact column boundaries for the columns that must not be wrong.
- Continuation lines are folded in. A line with no date and no amount belongs to the transaction above it, so it becomes part of that description instead of a row of its own.
- Page furniture is dropped. Lines that repeat on most pages, and lines outside the region the transactions occupy, are removed.
- The balance chain decides. After the columns are read, the converter checks that each previous balance plus the row amount equals the next balance. That check decides which column is the balance, and it corrects the sign on statements that print debits unsigned.
The check, in one line
A bank statement is self-checking. On every row, previous balance + amount = balance. If that holds across the whole statement, the rows were read correctly. If it fails somewhere, you are told exactly which rows, and why.
42/42 rows reconcile
This is also how the converter knows it has failed. When the chain breaks badly, the output is marked low-confidence and the rows are flagged rather than quietly presented as fact.
Questions people actually ask
Why does a normal PDF-to-Excel converter produce garbage here?
Because a PDF has no table. It has text positioned at coordinates. A general converter has to guess how those coordinates form rows and columns, and it guesses from whitespace. Bank statements defeat that guess: the numbers are right-aligned so their left edges move, descriptions run onto a second line, and every page repeats a header in the middle of the table. You get one column of text, or a column per word.
What does this converter do differently?
It uses what makes a statement a statement. Numeric columns are found by clustering right edges, because money is right-aligned. Rows are rebuilt by clustering baselines, with a tolerance that scales with the font size. Repeated page furniture is detected and dropped. And critically, every row is checked against the running balance the statement prints, which is a verification step no generic converter has.
Do I get one sheet or several?
Three. Transactions holds the data with real dates and numbers. Summary records what was verified — row count, balance check result and any warnings — so you can see at a glance whether the file is trustworthy. Raw keeps the original text line behind every row, so any figure can be traced back to the document.
Will multi-page statements work?
Yes, and the repeated header and footer on each page are removed rather than being turned into transactions. The balance check also runs across the page break, so a row that was half-read on the boundary of page two shows up as a mismatch instead of passing silently.
What if my statement has separate debit and credit columns?
That layout is detected. You get both: the original Debit and Credit columns kept as positive numbers, plus a signed Amount column. Which of the two layouts your statement uses is inferred from the data and cross-checked against the running balance, not taken on trust from the header text.
Does it work offline?
Once the page has loaded, yes. The PDF is opened in the same browser tab, so there is no request to fail. Nothing about your statement is ever sent anywhere, which is why the tool continues to work if you disconnect.