Features
What this actually does
Extraction is imperfect in every tool in this category, including this one. What is worth comparing is what happens next: whether the arithmetic is checked, whether you can see the line a figure came from, and what the software you use will actually accept.
The short answer
What happens to a statement, start to finish
A statement goes through four steps: it is read, its rows are rebuilt, every row is checked against the statement’s own arithmetic, and the result is written in the format your software imports. Digital statements are read in your browser; scanned ones are read with OCR. Each step below has its own page, with what it does and where it stops.
Reconciliation that names the row
Five arithmetic checks on every conversion, from strongest evidence to weakest, with the failing row named.
Limit: What reconciliation cannot tell you
Every row points back at the line it came from
Select a row, and the page it came from is shown with the printed line marked — on digital statements and on scans.
Limit: On a poor scan the band is an estimate
Reading statements that are scans
Scanned pages are transcribed by a vision model on our servers, then put through the same reconciliation as everything else.
Limit: A scan is always less certain than a text layer
Eight formats, because your software only takes one of them
One conversion, eight export formats, with the format-specific requirements handled rather than left to you.
Limit: A format cannot fix what your software will not accept
Categorising transactions, and why we will not guess for you
Bulk-label selected rows and carry the label into exports that support one. No automatic guessing.
Limit: No rules, no learning, no memory between statements
The pipeline
How the features fit together
None of these is useful alone. Extraction without checking hands you a spreadsheet that looks finished whether or not it is; checking without the source line tells you a row is wrong but not why; and a perfect conversion in the wrong format still will not import.
| Step | What it does | Feature page |
|---|---|---|
| Read | Digital statements are parsed from their text layer; scans go through OCR | Scanned statement OCR |
| Rebuild | Wrapped descriptions merged, brought-forward balances recognised, date order and currency settled once per statement | Reconciliation |
| Check | Running balance on every row, page subtotals, opening to closing, printed totals, transaction count | Reconciliation |
| Trace | Every row linked to the highlighted line on the PDF page | Source verification |
| Review | Flip, merge or exclude rows and label them in bulk before export | Transaction categorisation |
| Export | Excel, CSV, QBO, QFX, OFX, QIF, IIF or Tally XML | Export formats |
FAQ
Questions
Does the converter use AI?
Digital statements are read from their text layer in your browser. Scanned pages, and layouts the browser parser cannot handle, are read by an extraction model on our side and then checked against the statement’s balances — the checks are what make the output safe to rely on, whatever read it.
Is the reconciliation check a guarantee?
No. It verifies arithmetic — amounts, balances and totals. It cannot catch a wrong description or date, and two errors that cancel out would pass. That is why every row also links to its source line.
Does it categorise transactions automatically?
No, by design. You can label rows in bulk while reviewing; final categories belong in your accounting software, where its own rules and your chart of accounts live.
Is there an API?
Not yet. Conversion happens in the web app today.