Bank Statement QA Checklist: Catch Sign Errors and Missing Rows Before Import
Bank Statement QA Checklist: Catch Sign Errors and Missing Rows Before Import
Bank Statement QA Checklist (Before You Import)
A “correct-looking” export can still be wrong in the ways that break reconciliation. The fix is a QA checklist that targets the failure modes you actually see in month-end work: sign polarity mistakes, missing rows, summary-line contamination, and date parsing drift.
This checklist is built for a simple workflow:
- Convert the PDF into a canonical CSV/Excel export.
- Run QA on the export.
- Only then import or finalize.
The QA checklist (run every time)
1) Structure sanity (2 minutes)
| Check | Pass criteria |
|---|---|
| One header row | You see exactly one set of column headers |
| One transaction per row | No merged rows, no blank spacer rows in the middle |
| Parseable dates | Dates are real date values, not text |
| Numeric amounts | Amounts behave like numbers (sum works) |
If any of these fail, stop. Importing a broken structure is how you end up fixing spreadsheets downstream.
2) Sign polarity test (3 minutes)
Pick 5 deposits and 5 withdrawals from the export. Verify them against the PDF.
| Sample | What you expect | Common failure |
|---|---|---|
| Deposits | Positive amounts | Credit/debit swapped |
| Withdrawals | Negative amounts | Signs flipped or currency formatting stripped |
Rule of thumb: if you find 2+ sign mismatches in the first 10 samples, the export is not trustworthy yet.
3) Balance tie-out (fast truth test)
Compare:
- opening balance (statement vs export)
- closing balance (statement vs export)
If both tie out, you have a strong signal that totals are complete. If they do not tie out, the export likely has:
- missing rows
- summary rows included as transactions
- parsing that dropped fee/interest lines
The top 4 “boring” failure modes (and how to catch them)
Failure mode A: Summary lines treated like transactions
What it looks like: a row labeled “Total” or “Beginning balance” sitting among normal rows.
Catch it by filtering for descriptions that match known summary patterns, then verify if they truly represent individual transactions.
Failure mode B: Date formatting drift
What it looks like: dates that sort incorrectly or become text when imported.
Catch it by doing a quick sort on the date column and confirming the order matches the PDF.
Failure mode C: Description truncation
What it looks like: merchant names collapsed into abbreviations or broken narration.
Catch it by scanning 20 rows with long descriptions. If meaning is lost for multiple rows, the export will be painful to reconcile.
Failure mode D: Missing rows from noisy PDFs
What it looks like: export row count is dramatically lower than expected for the period.
Catch it by comparing row counts and doing a spot check on months with unusually high activity.
Build a QA log you can reuse
Your goal is auditability and repeatability, not paperwork.
A minimal QA log entry:
Run: 2026-04-27, Period: 2026-03-01 to 2026-03-31, Rows: 241, Structure OK, Sign checks: 10/10, Opening OK, Closing OK, Exceptions: 0.
Keep this with the export so a reviewer (or future you) can explain why the file was approved.
FAQ
What if the export fails QA?
Stop the workflow. Fix the conversion settings or parsing rules, re-export, then re-run QA.
Do I need to do every checklist item?
Yes. The whole point is to prevent the “I’ll skip this one step” failure cascade.
FAQ