September 3, 2026
Every bank statement carries its own proof of correctness, printed at the top and bottom of the page. A converted statement that has not been checked against it is a guess with good formatting.
A statement is a closed system. The bank prints an opening balance, lists every transaction in the period, and prints a closing balance. Those three things are bound by one line of arithmetic:
If the transactions you extracted from the PDF do not satisfy that equation against the printed figures, at least one transaction is wrong, missing or duplicated. There is no third possibility. The bank's own ledger produced the closing balance from those same transactions, so any reading of them that lands somewhere else has misread something.
Most statements also print a running balance after every transaction, or at least at the end of each day. That gives a second, finer check: each balance must equal the previous balance plus that row's amount. The chain has to hold from the first row to the last. When it breaks, the row where it breaks is the first row that was read wrongly, and you go straight there instead of scanning three hundred lines.
PDF extraction fails in ways that leave no trace. The output is a tidy table, every cell filled, and one of them is wrong. The recurring cases:
On a scanned or faxed statement a 7 becomes a 1, a 3 becomes an 8, a decimal point disappears. The row is present, the description is right, and the amount is off by an amount nobody would notice by eye.
The last transaction on page 4 sits under the footer, or the first on page 5 sits above the repeated column headings, and the extractor treats it as page furniture. One transaction is simply gone.
A wire with three lines of description swallows the next transaction's line, or the next transaction's amount gets attached to the wrong description. Two rows become one, or the amounts shift by a row.
Many banks print debits as positive numbers under a "Withdrawals" heading. An extractor that ignores the heading reads them as deposits. The row count is perfect and every amount is exactly wrong.
Statements that repeat the last transaction of the previous page under a "continued" banner, or that print a daily subtotal in the amount column, produce an extra row with a real-looking amount.
Each of these leaves a spreadsheet that opens without complaint, sorts by date, and totals to a plausible number.
Bookkeepers are good at spotting a row that looks strange. The failures above do not look strange. A dropped row is invisible by definition. A sign flip on a $1,240.00 rent payment is a $1,240.00 deposit with the landlord's name on it, and on a busy statement it reads as ordinary. A misread digit on a card purchase is a card purchase.
The only thing that exposes them is the arithmetic. A dropped $312.50 row leaves the closing balance $312.50 short. A flipped $1,240.00 leaves it $2,480.00 off. A duplicated line adds exactly its amount. Every failure mode has a signature in the total, and the running-balance chain points at the row.
The same applies to the general-purpose chat tools people now paste statements into. They do a reasonable job on a two-page statement. On a long one they tend to drop rows partway through or collapse a run of similar transactions into fewer lines, and they do not check their output against the printed totals unless asked. The result comes back formatted and confident. Reading a ledger is not a language problem; the check that matters is arithmetic, not fluency.
This is why the tie-out is worth more than any amount of visual review. It is one calculation, it uses only numbers printed on the statement, and it fails on every one of the errors above:
| Extraction error | Effect on closing balance | Where the chain breaks |
|---|---|---|
| Digit misread | Off by the difference | At that row |
| Row dropped | Off by the row's amount | At the row after the gap |
| Rows merged | Off by the lost amount | At the merged row |
| Sign flipped | Off by twice the amount | At that row |
| Line duplicated | Off by the duplicate | At the duplicate |
Two errors can cancel exactly, in theory. The running-balance chain, which checks every row rather than just the total, is the safety net for that. A statement that passes both the total and the chain has been read correctly, row by row.
The tie-out is also what turns "I converted it" into something you can defend. If a client or an auditor asks how you know the imported transactions are complete, "the rows reconcile to the printed opening and closing balances" is an answer. "I looked at it" is not.
A failed tie-out is not a dead end; it is a pointer. Work it in this order:
The tie-out needs two numbers from the statement itself: the printed opening balance and the printed closing balance. Without the closing figure there is nothing to compare against. A converter can still add up whatever it extracted, but a sum with nothing to check it against is not a check; it is the same guess written as a total.
This is why PennyClose will not show a statement as tied unless it has found the printed closing balance and the extracted rows reach it from the printed opening balance. If there is no closing figure it can read, or the figure is ambiguous, the result says so and the export is marked as unproven. That is less satisfying than a green light on every upload. It is also the only honest thing a converter can say.
Try it. Upload a statement and see whether it ties to its printed balances before you download anything. The preview is free and needs no account. Convert a statement