Verification method
How the verification works
Extraction is only the first step. RowSure then asks a separate question: do these numbers agree with what the bank itself printed? When a statement provides opening and closing balances, the transactions in between must bridge those two control totals; printed running balances can make the check more granular.
The four levels of validation
Statements come in different shapes, so the check runs in levels, strongest first.
Row by row, against the running balance
Many statements print a running-balance column: the balance after each transaction.
Where it exists, we verify balance[n] = balance[n−1] ± amount[n] for every
row. This check can identify where the chain first breaks — it is what
lets us show "row 47 looks wrong" instead of "something is off somewhere".
Aggregate reconciliation
Some banks (Intesa Sanpaolo, for one) don't print a running balance. The fallback is the
identity opening balance + Σ movements = closing balance. It still proves the
extracted amounts reconcile — but if it fails, it tells you that there's an error, not
which row caused it.
Credit card statements
Card statements don't always list every transaction, or list them in a way that resists
full extraction. There we verify the period summary instead:
Previous balance − Payments + Purchases + Fees + Interest = New balance.
It's a coarser check, but it still anchors the output to numbers the issuer printed.
"Unable to verify", said out loud
If a document contains no usable balance anchors at all, the result is reported as unverified — not dressed up as a pass. Failing loudly is the product. A converter that can never say "I don't know" can never be trusted when it says "done".
Proof strength and result state are separate. Every check ends in one of four states: VERIFIED when the applicable arithmetic and source guards pass; REVIEW REQUIRED when the balances close but the independent source check needs attention; BALANCE MISMATCH when the available balance evidence identifies a difference; or NOT VERIFIABLE when the evidence is insufficient to make either claim.
The anti-fabrication metric
A reconciliation that always passes would be worthless — an extraction engine could, in theory, "adjust" numbers until the arithmetic closes. So we run a separate embedded-text check: how many extracted amount occurrences can be matched, after numeric-format normalization, to distinct numeric occurrences in the PDF's text layer? One occurrence can support only one extracted movement. This is a global source check, not a claim that a value was found verbatim on the same visual row.
If the PDF has no reliable text layer — a scan or damaged embedded font — the metric is reported as unavailable and RowSure requires a separate corroborating reading instead of inventing a 0% score. If the arithmetic closes but text coverage is below the required 95%, the result is REVIEW REQUIRED, not a balance mismatch. The measured percentage and source-review diagnostics appear on the result and in the Excel Verification sheet.
What we've measured, not promised
- Corpus of 64 real statements from 48 banks across the US, UK, Canada, Australia, India, Italy, Spain, Germany and New Zealand — court filings, charity registers, council packets and official bank samples: 47 reconcile via vision-based extraction. The other 17 do not receive a green verdict: each keeps its actual result — source review, balance mismatch or not verifiable — and a reason instead of a silent pass (as of August 2026). On a bank we have never seen before the rate is 72%, against 75% on one we have — three points, because we read documents, not banks.
- Numeric conventions parser (EU/US/UK/FR/CH formats, accounting parentheses, trailing minus): 17/17 ambiguous cases handled correctly.
- Our own hand-written deterministic parser, by contrast, produced 155 perfectly plausible-looking transactions that were off by €3,752 — invisible in the Excel, caught only by the balance check. That experiment is why verification is the product.
What the check does not cover — said plainly
The reconciliation verifies amounts. It does not verify dates, descriptions, or per-row categorisation. And two errors that exactly cancel each other out would pass the aggregate check.
We think amounts are the right proxy: a wrong amount breaks your books, a slightly off description usually doesn't. But it's a proxy, and you deserve to know that — verification that overclaims is just marketing with extra steps.