How we test
Two things stand behind every conversion: an arithmetic check that runs on your own file, and a release process that validates every build against a fixed test corpus before it ships.
Last updated September 9, 2026
A check on your file, not a percentage on ours
An accuracy figure is an average taken over someone else's documents, on a corpus that is rarely published. It tells you nothing about the statement in front of you. What tells you something about that statement is whether its own printed balances reconcile with the rows that came out, and that is a test you can run yourself on the free tier.
So the product is built around a check that runs on your file, every time, including on the free tier. You do not have to trust an average. You can see whether your own conversion ties.
The balance check
The check rebuilds the account from the rows we extracted and compares it against the figures the bank printed.
- Rebuild the running balance. The opening balance plus each extracted transaction, line by line, has to equal each printed running balance and the printed closing balance.
- Try both orderings. Statements printed newest-first reconcile in reverse; the check runs both ways and the export is written in date order.
- Apply the credit-card convention. Sign convention is flipped and subtotal rows are excluded, so a card statement reconciles on the same arithmetic as an account statement.
- Flag what breaks the chain. Every row where the rebuilt balance and the printed balance disagree is shown with the difference, in the result and in the export.
- Retry when a native PDF fails. A native file that does not reconcile on the fast reading pass is retried automatically with a stronger pass. Scans and photographs go straight to the stronger pass.
The check is arithmetic, so it covers dates, amounts and balances. Descriptions do not enter the calculation. How the check works.
Release validation
Every release is validated against a fixed test corpus with known-correct output before it ships. The corpus covers the layout families the product is built for: Australian transaction accounts, UK current accounts, US checking accounts and Turkish account statements, plus credit-card statements, across the date and number formats of those markets, in three conditions: native text PDFs, scans, and photographs of paper pages taken on a phone.
- Extract through the production path. Every file in the corpus goes through the same code a customer upload goes through, with no bank-specific templates and no per-file tuning.
- Compare against the known-correct output. Date, description, debit, credit and balance are compared cell by cell.
- Reconcile. The balance check runs on every file, in the same configuration customers get.
- Record what the check caught. For every file with a cell error, we record whether the balance check flagged it. That is the measurement the product is built on: an error the check catches is an error you see.
The corpus is fixed, so results are comparable from one release to the next, and a change that degrades extraction shows up as a regression rather than as a support ticket.
When the corpus is re-run
The full corpus is re-run whenever the extraction path changes, and a release ships only after it does. What changed is recorded on the changelog. Layout-by-layout verification against real statements from US, UK, Australian and Canadian banks is in progress and reported on banks.
Convert one and see
Three pages a day are free, and you don't need an account to run your own statement through it.