How verification works: the running-balance proof

The idea

Most statements print a balance after every transaction. That column is redundant information: each balance should equal the previous balance plus the transaction's amount. If you can recompute it, you can test whether what was read is right. This is the same principle as a checksum.

A worked example

Take a short statement with an opening balance of 1,000.00. Here is what it prints, and what the check does with each row.

Row 1: 1,000.00 minus 45.20 is 954.80, which matches the printed balance. The amount and its direction (money out) are proven. Row 2: the amount was read as 250.00, so the expected balance is 1,204.80, yet the page printed 3,454.80. They cannot both be right. The printed balance moved by 2,500.00 from the previous one, so the likely truth is that the amount is 2,500.00 and a decimal or digit was lost, perhaps by OCR. Because row 3 again agrees with the printed balances (3,454.80 minus 120.00 is 3,334.80), the later balances are consistent and the problem is confined to row 2.

Tallyscope flags row 2 and offers 2,500.00, the amount the balance implies, as a one-click fix. When the digits you read are exactly the digits the balance requires, for example 250000 instead of 2,500.00, only the decimal point and separator are lost, and the number is restored automatically and tagged as repaired. In this example 250.00 is a different digit string from 2,500.00, so the fix is offered, not silently applied. That distinction is deliberate: a repair is applied only when the numbers prove it.

What the check proves

• The amount of each row.
• The direction. Whether a row is money in or out follows from the sign of the balance change, whichever column layout the bank uses: separate debit and credit columns, one signed column, CR/DR suffixes, brackets or trailing minus. Tallyscope learns which column is "money out" for each statement.
• The order. Newest-first statements are detected.
• The totals. Opening, closing and any printed totals are compared with the sums of the rows. A wrong printed opening balance can be detected and repaired.

The four statuses

A status is never raised without arithmetic evidence, and the tool prefers saying "Needs review" over guessing.

What it cannot prove

• Dates. No arithmetic ties to a date. A misread day can pass every check.
• Descriptions. Text such as merchant names is not verified.
• That the statement is genuine. The check proves internal consistency, not authenticity. It is not an audit, and a forged but consistent statement would pass.
• Two equal, offsetting errors. Unlikely, but possible in principle.

Verification is arithmetic evidence, not a guarantee, and you remain responsible for checking figures you rely on. See the terms.

Where it runs

All of it happens in your browser tab, on the data in memory; see converting without uploading. For the OCR side of repairs, read bank statement OCR, or open the app and see the statuses on your own statement.