Drop a statement PDF and get clean rows out: date, description, money in, money out, balance. Every line is reconciled against the statement's own running balance, so a misread is flagged instead of quietly landing in your books. The file never leaves your machine.
| Date | Description | Money in | Money out | Balance |
|---|
Most converters hand you rows and wish you luck. But a statement already contains the answer key: if it prints a running balance, then every row's amount must equal the change in balance from the line above. That is arithmetic, and arithmetic can be checked.
So every line gets checked. A row that adds up is marked with a tick; one that does not is flagged in red and stays flagged until you fix it. A single digit read as an eight instead of a three is exactly the kind of error that is invisible in a list of numbers and expensive in a set of books.
Statements disagree about almost everything. Is 03/08/2026 the third of August
or the eighth of March? Is 1.234,56 a thousand or one and a bit? Are debits in
their own column, or negative numbers in a shared one?
Rather than asking you, the converter reads the whole document and decides from the evidence in it — a day above twelve settles the date order, the decimal separator settles the number format, and the horizontal position of each figure settles the columns. Whatever it concluded is shown above the table, so you can see the reasoning rather than trust it.
Your statement is opened by your own browser and stays there. No request carries it, nothing is stored, no account is needed — which is the whole point when the document lists every payment you made last month.
To be exact about the one network request that happens: the first time you use this page your browser downloads the PDF reader from a public code repository, the way it downloads any script. After that it is cached and the page works offline. The site also counts anonymous page views. Neither touches your file.
When it is one amount or one IBAN off an invoice rather than a whole statement, running the document through a converter is a lot of work for one figure. Snip2Field sits on your Windows desktop: press a hotkey, drag a box around just that field, and it reads it, validates an IBAN against its checksum, and copies it. Fully offline, like this page.
See Snip2FieldNo. The PDF is opened and parsed by your own browser and never leaves your machine. There is no account, nothing is stored, and no request carries the file or anything read out of it. The page fetches its PDF reader from a public code CDN the first time you use it, and that is the only network request involved.
If the statement has a running balance column, each row's amount should equal the change in balance from the row above. That arithmetic is checked on every line. Rows where it does not add up are flagged rather than silently exported, which is how a misread digit gets caught before it reaches your books.
Any PDF with a real text layer, which is what banks issue when you download a statement. The converter works out the date convention and the decimal convention from the document itself, and handles both separate debit and credit columns and a single signed amount column.
A scan is an image, so there is no text layer to read. Run it through PDF to Text first to see what comes out, but treat recognised figures with suspicion: for money, a misread digit is worse than no output at all.
Yes. Every cell in the table is editable, and the reconciliation check re-runs as you type — you can watch a flagged row turn green when the correction is right.
There is nothing to meter. The work happens on your machine, so there is no server cost per statement and no reason to put a wall in front of it.