Why your imported balance doesn’t match the statement

First: find where it breaks

Do not start from the closing balance. Start from the opening one and walk forward, adding each transaction, until your running total stops matching the balance printed on that row. The row where they first disagree is the row with the problem — everything after it inherits the gap and tells you nothing new.

If the statement has no running balance column, do the same per page using page subtotals, or against the printed credit and debit totals for the period.

The gap equals one transaction exactly

A transaction was dropped. Find the amount in the statement and check whether it is in the imported data at all.

• Rows on a page boundary are lost most often, particularly the first row after a page header.
• Multi-line descriptions can be read as two rows or as none.
• A row with an unusual layout — a reversal, a fee bundled into a line — can be skipped by a parser expecting a regular shape.

The gap is exactly twice a transaction

A sign was inverted. A debit of 500 read as a credit moves the balance by 1,000, not by 500 — which is why doubling is the signature of a sign error rather than of a duplicate.

This comes from statements with separate debit and credit columns, or from a "Debit" column of positive numbers where the sign is implied by the heading rather than written.

The gap is a round number, or a factor of ten

A digit was misread. 220,000.00 read as 22,000.00 leaves a gap of 198,000 — not round, but obviously related to a real amount once you look. Dropped zeros are the classic scan error; so is a decimal separator read as a thousands separator, which multiplies or divides by a thousand.

The gap appears at the start and never grows

The opening balance is wrong, and the transactions are fine. Usually the opening balance was taken from the wrong line — the previous period’s closing balance, an available balance rather than a ledger balance, or a figure that includes pending items.

The gap grows steadily through the file

Something is being counted that should not be. The usual candidate is a brought-forward or carried-forward line treated as a transaction: each page adds the running balance again as though it were a movement.

Look at the row after each page break. If it repeats the previous page’s closing figure, that is the double count.

What to do once you have found it

1. 1Fix the specific row rather than adjusting a total. A balancing entry hides the error and leaves the underlying row wrong.
2. 2Re-check the whole ledger afterwards. One cause often has siblings — a parser that lost one page-boundary row usually lost several.
3. 3Compare against the statement’s printed credit and debit totals as a second, independent check.
4. 4Only then import.