Methodology: how a statement is checked, and what is not guaranteed

The rule

Most statements print a balance after each transaction. Tallyscope recomputes every balance as the previous balance plus the row’s amount and compares it with the printed one. A row is proven when the two agree. A status is never raised without that arithmetic evidence.

The check runs in your browser tab, on the data in memory. Nothing about it needs a server, and no statement content is sent anywhere to perform it; see converting without uploading.

Steps, in order

1. Read. Text PDFs are read from their word positions. Scans and photos go through OCR first (Tesseract compiled to WebAssembly, in your tab). Bank files such as CSV, OFX, QIF, MT940 and camt.053 are read directly. Guides exist for 16 languages, and the parser recognises column headers in more languages than that: Latin-script European languages, Cyrillic and Greek, Chinese, Japanese, Korean and Southeast Asian languages, right-to-left scripts such as Arabic, Persian, Urdu and Hebrew, and Indic languages. Each guide’s worked example is run through the real parser in the test suite. For scans, OCR can use the English model that ships with the site plus 16 language models that are downloaded from the jsDelivr CDN only when needed. The reader is not tied to a list of banks.
2. Recompute. For each row, the expected balance is the previous balance plus the amount read. The direction of a row (money in or out) follows from the sign of the balance change, so it works whichever column layout the statement uses.
3. Compare. The expected balance is compared with the printed one. Opening, closing and any printed totals are compared with the sums of the rows. The first row that breaks the chain is marked, and the app can jump to it.
4. Repair, only with proof. A lost decimal point or thousands separator is restored only when the digits equal what the balance requires, and the row is tagged as repaired. Any other suggested fix is offered to you, never applied silently.
5. Set the status. The result is one of four statuses, set from the evidence above.

The worked example on the verification page shows these steps with real figures: an opening balance of 1,000.00, a payment that proves to 954.80, and a salary row whose printed balance of 2,500.00 more than the amount read shows a digit was lost.

What do the four statuses mean?

Verified means the printed running balance proves the statement: every row is proven, or at least 80% of the rows are proven and the closing balance matches, and no row disagrees with the balances.

Verified

The rule above is met.

Partly verified

Some of the statement is proven and some is not, or a condition below holds it back from Verified.

Needs review

One or more rows disagree with the balances, or the closing balance or printed totals do not match.

Unverified

There is no balance information to check against, so rows are extracted but not proven.

A statement with no running balance column can still be Verified when its printed opening balance plus the money in, minus the money out, equals its printed closing balance, provided no direction had to be guessed and no row was left out.

Even when the balances line up, a statement is held at Partly verified if an amount could not be read, a dated row was left out, rows repeat exactly without being proven one by one, a direction contradicts the balances, or the transaction count printed on the statement differs from the rows read.

Checks beyond a single statement

• Printed row count. When a statement prints how many transactions it contains and the number read differs, the statement is flagged.
• Identical rows. When rows repeat exactly, the statement’s status is downgraded, because repeated rows may be duplicates. You decide.
• Continuity across statements. For a set of statements from one account, the Statements tab reports missing periods and whether one statement’s closing balance equals the next one’s opening balance.
• Batches. With three or more statements a summary card counts statements by status. Statements you mark as reviewed are counted separately and never as verified.

What is not guaranteed

The check shows that the rows are consistent with the balances printed on the document. It does not prove dates, descriptions, or that a statement is genuine, and it is not an audit. For scans, it cannot rescue an image too poor to read; it flags the rows it cannot prove.

• Dates. No arithmetic ties to a date. A misread day can pass every check.
• Descriptions. Merchant names and other text are not verified.
• Authenticity. A forged statement that is internally consistent would pass. The check proves consistency, not origin.
• Offsetting errors. Two equal and opposite mistakes could cancel out. This is unlikely, but possible in principle.
• Scans and OCR. OCR makes mistakes, and heavy blur, glare or very low resolution can leave rows wrong. Those rows are flagged and the statement shows Needs review rather than a guess. We publish no accuracy percentage, because it depends entirely on the scan. See bank statement OCR for the pipeline and its limits.
• No balance column. Without a running balance or printed totals there is nothing to check against, and the statement stays Unverified.
• Other people’s reading of the result. Statuses and the per-row notes travel with exports (a Status and a Review note column), but a lender, tax authority or auditor decides for themselves what to accept.

Where this is encoded

The reconciliation logic is pure code with no user-interface dependencies, and it is tested against synthetic statements with known correct answers, including scans generated with ground truth. The tests use synthetic data only. We do not claim a percentage of statements that will verify, because layouts vary.

Exports keep the evidence: every row carries its status and any review note in CSV, Excel, PDF and JSON, and a reconciliation report (PDF and an Excel sheet) summarises the checks. OFX, QuickBooks CSV and Xero CSV are files for importing into accounting software; see pricing for which plans include them.

Questions or a statement that behaves unexpectedly: contact us, describing the layout rather than sending the document. Or open Tallyscope and see the statuses on your own statement.