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 15, 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.

A closed loop running from a document to a table to a check and a flag, and back again

The balance check

The check rebuilds the account from the rows we extracted and compares it against the figures the bank printed.

  1. 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.
  2. Try both orderings. Statements printed newest-first reconcile in reverse; the check runs both ways and the export is written in date order.
  3. 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.
  4. 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.
  5. Put right what arithmetic can put right. A debit read as a credit, or a running balance misread on one line while the amounts around it agree, is corrected from the printed balances to the cent and marked as corrected. Nothing is corrected on trust: a change that does not make the printed balances tie is not made.
  6. Re-examine where the chain still breaks. A picture page whose chain still breaks is examined again, and a row from that examination replaces the first only when it makes the printed balances tie; a row the first reading lost is put back the same way. Wording alone never marks a row.
  7. Tie the totals where no running balance is printed. On a statement that prints only period figures, the previous balance plus money out minus money in has to reach the new balance, and printed totals for money out and money in are tied to the rows.
  8. Check what the arithmetic cannot see. A date that falls outside the statement's own sequence is marked for review, and a cell the reader could not make out is marked for review with the cell named. A doubt about an amount that the printed balances confirm is not a doubt, and is not marked.
  9. Read every picture page at full resolution. Scans and photographs are read on the stronger pass at the model's full resolution, and a page that arrives as a picture with a text layer under it, the way copiers and scanning apps produce them, is read as the picture, not the text layer.

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.

  1. 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.
  2. Compare against the known-correct output. Date, description, debit, credit and balance are compared cell by cell.
  3. Reconcile. The balance check runs on every file, in the same configuration customers get.
  4. 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

During the launch offer ten pages a day are free, and you don't need an account to run your own statement through it.