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 19, 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
Pages are free every day 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 review workbook 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
Is this an accurate bank statement converter?
Accurate enough to prove it on your own file, which is the only kind of accuracy that matters for your books. Every conversion rebuilds the running balance from the transactions it read and compares it, row by row, with the balances your bank printed. When they agree, the amounts and their order are right to the cent. When they don't, the row is flagged in the review workbook with the difference, instead of being passed along as if it were fine. That is why this page shows how the check works rather than a percentage: a figure measured on someone else's statements says nothing about yours.
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. Where the printed balances prove a correction to the cent, such as a debit read as a credit, it is made and marked as corrected. Anywhere else, 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 in the review workbook 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. Correct the opening balance on the workbook's Statement details sheet and upload it, or send a sharper picture through. 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 read and you got a result, with the rows to check marked in the review workbook. If something looks wrong, email us and we will look into it; credits used for a completed conversion are not returned on the basis of its output. A conversion that fails because of a problem on our side is not charged.
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.