How to Fix Bank Statement Conversion Errors
Last updated
Do not start by editing random cells until the closing balance matches. First identify the earliest row where the spreadsheet stops agreeing with the source statement, then correct the smallest supported error.
Missing transaction
A missing row often appears after a page break, repeated table header, wrapped description, or faint fee line. Compare the first broken running balance with the source page and inspect the lines immediately above it. Confirm the document contains every printed page.
Wrong debit or credit sign
Look for parentheses, trailing minus signs, DR or CR labels, and separate debit or credit columns. The reported balance movement can help detect a reversal, but the printed marker should take priority when it is unambiguous.
Dropped decimal point
Scanned statements can turn 4.95 into 495. A correction is defensible when the surrounding running balances prove the intended split. Record the original recognized value and flag the correction for review.
Duplicate row
Repeated headers and overlapping page scans can cause the same transaction to appear twice. Compare date, amount, description, page number, and source coordinates. Do not remove legitimate repeated payments solely because their values match.
Incorrect date or year
Statements often print month and day without a year. Infer the year from the statement period, paying special attention to December-to-January periods. Day-first and month-first numeric dates must not be guessed when the document is ambiguous.
No transaction rows found
Confirm that the PDF is not password-protected, cropped, incomplete, or too low quality for OCR. Try the original bank download rather than a screenshot. If the file remains unreadable, stop rather than exporting an empty spreadsheet.
Before using the corrected export
Rerun row-level and closing-balance validation, review the correction log, and compare material transactions with the PDF. Never send an unredacted statement when reporting a problem.