The balance check
This is the part that makes StatementTable different from a converter that hands you a spreadsheet and hopes for the best.
Last updated September 9, 2026
| Date | Description | Amount | Balance | Check |
|---|---|---|---|---|
| 2026-03-03 | Card payment | -42.60 | 1,866.31 | |
| 2026-03-05 | Deposit | 2,140.00 | 4,006.31 | |
| 2026-03-08 | Utilities | -118.75 | 3,887.56 | |
| 2026-03-12 | Supplier | -960.00 | 2,837.56 | Check 90.00 |
| 2026-03-15 | Card payment | -63.40 | 2,774.16 | |
| 2026-03-19 | Transfer in | 500.00 | 3,274.16 |
One row is 90.00 away from the balance the bank printed. It is exported with the others and marked, so you check one line instead of eighty.
The problem with "it converted fine"
A converter gives you 80 rows. They look plausible. One of them says 43.26 where the statement says 433.26, because a scan smudged a digit. You import it, and three weeks later a reconciliation in your accounting software is off by 390.00 and you have no idea which row did it.
The failure mode of automated extraction isn't that it breaks loudly. It's that it produces something that looks right.
What we do instead
Bank statements contain their own proof. Every line prints a running balance, and that balance is the sum of everything above it. So after extraction, before you see anything:
- Sort. Transactions are put in date order. Statements printed newest-first are detected and reversed.
- Rebuild. Starting from the printed opening balance, each transaction is added or subtracted in turn to compute what the running balance should be.
- Compare. The computed balance is checked against the balance printed on that line, to the cent.
- Flag. Any line where the two disagree is highlighted, with the size of the difference shown next to it.
Then the closing balance is checked: opening balance plus every transaction has to equal the closing balance printed on the statement.
A worked example
Five rows from a bank statement. Opening balance 1,250.00. The same five rows arrive in one of three states, and the check reports each one differently. Pick one.
What the badge means
| Badge | Meaning | What to do |
|---|---|---|
| Balances reconciled | Every printed balance matched the rebuilt one, and the closing balance agrees. | Import it. Spot-check if the file matters. |
| N rows flagged | The chain broke at N lines. The difference is shown on each. | Open those rows against the PDF. Usually one misread digit. |
| Closing total checked | The statement prints a closing total but no line-by-line running balance. Opening figure plus every transaction was reconciled against that total. | Import it. The column total is confirmed even though the individual lines have nothing to check against. |
| Check unavailable | The statement prints neither a running balance nor a closing total. Common on credit-card statements. | The transactions are extracted and the badge says plainly that the arithmetic had nothing to verify against. Read them before importing. |
A green badge proves the amounts and dates are internally consistent with what the bank printed, to the cent. It is arithmetic on the document in front of you, not an opinion about it. Descriptions sit outside the chain, so a merchant name is still worth a glance before the file goes into your books.
Credit-card statements
Credit-card statements work differently: the "balance" is what you owe, a purchase increases it and a payment reduces it. The check flips its sign convention accordingly and reconciles opening debt plus activity against closing debt. Subtotal and section-header lines ("Previous balance", interim totals) are excluded from the transaction list so they are not double-counted.
Many card statements print no running balance at all, only a previous balance, a list of transactions and a new balance. The check reconciles the closing total there instead: opening debt plus purchases minus payments has to equal the new balance, and the badge says "closing total checked". Where the statement prints no usable total either, the badge says "check unavailable" and the export carries that status on every row, so nothing about the file implies a check that did not run. More on credit-card statements.
Why this beats an accuracy percentage
Every converter on the market can quote a figure from a test set you will never see, measured on statements that are not yours. An accuracy number tells you how a tool behaved on someone else's documents. It says nothing about the file on your desk this morning.
The document is the reference
The bank already printed the answer. Rebuilding the running balance and comparing it to that printed figure is a test run against your statement, on the day you convert it, not against a corpus from some earlier release.
You run the test yourself
Three pages a day are free and need no account. Convert the statement you were about to convert anyway, read the badge and the flagged rows, and decide from there rather than from a percentage on a marketing page.
Every release is validated against a fixed corpus of statements with known-correct output before it ships. That work is why the arithmetic is trustworthy, and the method is described on how we test. The check is what carries it through to your file.
The scope of the check
The check is arithmetic, and arithmetic has edges. Knowing exactly where they fall is what lets you rely on the badge for everything inside them.
- Amounts and dates, not descriptions. A misread figure breaks the chain and gets flagged. A misread merchant name leaves the arithmetic intact, so read descriptions with your own eyes.
- Statements that print a balance. Where a statement prints neither a running balance nor a closing total, the export carries the check-unavailable status on every row instead of a pass.
- Offsetting errors. Two mistakes that cancel each other out leave the chain whole. That is a property of arithmetic rather than of the reader, and it is why the flagged-row view shows you the difference instead of a single verdict.
- The extraction, not the document. The check confirms that the rows match what is printed on the page. Whether the page itself is genuine is a separate question, and one no converter can answer.
The four kinds of error the chain catches, with the arithmetic worked through on each, are in what a reconciliation check really catches.
Questions
Does a green badge mean the export is perfect?
It means every amount, and the order they are in, is consistent with the balances your bank printed. It doesn't check descriptions, and it can't catch two errors that cancel each other out. Treat it as strong evidence, and still glance at the file before it goes into your books.
Why flag rows instead of fixing them?
Because a fix would be a guess. If our reading of a number disagrees with the printed balance, we know something is wrong but not which side is right. Showing you the row and the difference takes you ten seconds. Silently rewriting your financial data to make our own check pass would be the worst thing this tool could do.
My whole statement is flagged. What now?
Usually one of three things: the opening balance was misread, so every row after it is off by the same amount; the statement is printed in an order we didn't detect; or the scan is too low-quality. Send it back through. A native PDF is retried with a stronger reading pass automatically. If it still fails, email us the bank and layout, not the file.
Do I get charged for a conversion that fails the check?
Yes, if it converted: the pages were processed and you got a result, just one with flags on it. But if the output is clearly wrong, tell us within 7 days and we credit those pages back. Conversions that error out entirely are never charged.
Convert one and see
Three pages a day are free, and you don't need an account to run your own statement through it.