Why a converted bank statement must tie to its printed balance before you import it

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.

The equation the bank already gave you

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:

opening balance + credits − debits = closing balance

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.

What goes wrong silently

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:

• A digit misread. 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.
• A row dropped at a page break. 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 merged multi-line description. 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.
• A sign flipped in a withdrawals section. 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.
• A duplicated line from a "continued" header. 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.

Why "it looks right" is not a check

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.

One check that catches all of it

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.

When it does not tie

A failed tie-out is not a dead end; it is a pointer. Work it in this order:

1. Find the first row where the chain breaks. Everything above it is right. The error is at that row or immediately before it. Look for a merged description, a sign, or a missing line between it and the previous row.
2. Check for a missing page. If the break falls at a page boundary, the PDF may be incomplete. Compare the page count to what the statement itself says ("page 3 of 5").
3. Scans and photos. If the statement is an image rather than a native PDF, expect digit errors. Compare the flagged row to the image at full zoom. Where possible, get the native PDF from online banking instead; it removes this whole class of error.
4. Bank quirks. Some statements exclude pending items from the closing balance, or print interest and fees in a summary box rather than in the transaction list. If the difference matches a figure in the summary box, that is the missing row.
5. Fix the row, re-check, then export. Edit the grid, not the export. The check should pass before any file is built from it.

Why there is no green light without a printed closing balance

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.

The practical rule is short. Convert the statement. Look for the proof against the printed balances. If it ties, import. If it does not, find the first broken row before you do anything else. Never import a statement that nobody has shown to tie.

All notes