Why not just paste it into ChatGPT?

Often you should. For one personal statement you want to look at in a spreadsheet, a chat assistant is faster than any converter and this page is not going to pretend otherwise. What follows is the part where it stops working — and none of it is about the model being stupid.

Start with the honest half

Drop a text-layer PDF into a current assistant and ask for CSV, and you will usually get a usable table. It will handle a layout no parser has ever seen. It will read a column heading in a language the parser has no profile for. For a one-off — checking a subscription, splitting an expense, looking at last year — that is the right tool, and the whole category built on charging for that job is losing to it. The operator of the largest converter in this niche published his numbers in August 2026: revenue down 24%, new subscribers down from 184 a month to 45, and he names chat assistants as the reason.

So the question is not which is smarter. It is what you can prove afterwards.

It cannot check its own reading

A statement carries its own proof: an opening balance, a closing balance, often a running balance beside each row. Those came from the bank's ledger, not from whatever read the PDF, so they are an independent test of every number extracted. src/parse/reconcile.ts runs that test — row by row against the balance column where there is one, and opening + Σ(amounts) = closing where there is not — and reports each row that fails.

An assistant can be asked to check its own arithmetic, and it will report that the arithmetic checks out. That is a different claim: it is the same process auditing itself, and a misread amount is wrong in the sum exactly as it was wrong in the row. The check is only worth something when the number being checked against was not produced by the thing being checked.

The file has to be valid, not plausible

If the CSV is for your own eyes, plausible is enough. If it is going into software, it is not.

• QBO is OFX 1.02 in SGML, US-ASCII, with an INTU.BID that Intuit validates against its own registry and a FITID that has to stay stable across re-imports or QuickBooks duplicates every transaction. src/export/qbo.ts derives that id as sha1(account|date|amount|description) with a duplicate counter. An assistant asked for "a QBO file" writes something with the right tags in it.
• DATEV dates a booking TTMM — four digits, no year — and takes the year from the header window, which is why src/export/datev.ts refuses a statement crossing a calendar year instead of posting December into the wrong one. Amounts carry no sign; direction lives in Soll/Haben relative to the account. The file is Windows-1252, not UTF-8.
• CAMT.053 is schema-validated XML. src/export/camt053.ts emits camt.053.001.02 because that is the version the German DFÜ-Abkommen specifies element by element, and its output was checked against the published XSD rather than eyeballed.

None of that is clever. It is a hundred small facts that decide whether an import silently fails, and they are the kind of thing a model reproduces approximately.

The one that is not about quality at all

If you are a bookkeeper, an accountant or a tax advisor, the statement is not yours. In Germany a Steuerberater is bound by §203 StGB; across the EU, handing client data to a processor requires a contract under Article 28 GDPR. A consumer chat product is neither your processor nor covered by such a contract, and pasting a client's bank statement into one is a disclosure decision, not a tooling decision. That is a bar no amount of model quality clears.

What this site does about it is stated on the home page and enforced by the deployment rather than promised: the file is parsed in memory and never written to disk, the container is mounted read-only, and the source is public so you can check both. If that is still not enough for your obligations, the licence is MIT — run it inside your own network and nothing leaves it.

What you can hand to someone else

Every conversion here produces a receipt: a plain text document naming the statement, the profile that read it, the two balances it was checked against, the arithmetic, and every row that did not fit. It is built by src/receipt.ts, in the same six languages as the rest of the site. Its last section says what the check does not prove, because a receipt that only says "verified" invites exactly the reliance it cannot support.

A chat transcript is not that document. It can be edited, it does not survive the tab, and it asserts a conclusion without showing the arithmetic that produced it.

Where this tool is the wrong answer

Said plainly, because the rest of the page is only worth reading if this part is here.

• A scanned statement. A photograph of a page has no text to extract. There is recognition here, but it is slower and its numbers are checked differently — an assistant reading an image may well do better.
• A layout nothing recognises. The generic engine plus the balance check carries most statements, but a bank whose profile is an untested template can be read wrongly. When that happens the check usually says so, which is the point; it is still a worse experience than a model that simply reads it.
• A one-off, for yourself, with no software downstream. Use whatever is faster. Nothing here is worth the extra step.
• Anything needing judgement. Which expense account a payment belongs to, whether a transfer is a duplicate, what a cryptic merchant string means — this program does not guess at any of it, and a model is genuinely useful there.

The short version

Use an assistant when you need a reading. Use this when you need a reading you can check, in a file another program will accept, from a tool you are allowed to send the data to.