The Bank Statement Export QA Playbook

Most finance teams do not lose time because they lack data. They lose time because they trust the data too early.

A bank statement export can look clean and still fail in small ways that matter: one missing row, one duplicated fee, one date shifted into the wrong month, one amount flipped from debit to credit. Those little mistakes are exactly how reconciliation drifts. By the time someone notices, the bookkeeping team is already debugging a month-end close issue that should have been caught at the source.

This guide is the QA playbook I would want in place before any bank statement lands in Excel, Xero, QuickBooks, NetSuite, or a custom reconciliation workflow. It is written for teams that work with PDF-to-CSV, PDF-to-XLSX, or PDF-to-JSON conversion and want a repeatable way to verify the output before it becomes a ledger problem.

The core idea

Do not treat statement conversion as the finish line. Treat it as a controlled handoff.

Your real job is not “get the file out of the PDF.” Your job is “produce export-ready transaction data that still ties back to the source statement and can survive import without cleanup.”

That means QA should answer five questions:

1. Did we capture every transaction?
2. Did we preserve the right dates?
3. Did we preserve the right amounts and signs?
4. Did we keep the right merchant or description text?
5. Can the exported file be imported or reviewed without hidden manual fixes?

If any answer is shaky, the export is not ready.

The QA stack, from quickest to strongest

The best teams do all five, but if you are short on time, do layers 2 through 4 every time.

What to inspect first, in order

1) Statement period

The statement period is the first place hidden errors show up. A file may say it covers April 1 to April 30, but the rows may start on April 2 or include May 1 by mistake.

Check:

• opening date
• closing date
• whether the export includes both endpoints correctly
• whether any transaction dates fall outside the expected period

If you are converting monthly statements, one out-of-range row can move an expense into the wrong accounting month. That sounds small until it changes accruals or makes month-end look “off.”

2) Opening and closing balances

Balancing is not optional. It is the easiest sanity check in the file.

A clean rule:

Opening balance + credits - debits = closing balance

If that does not work, stop. Do not “fix it later.” Find the mismatch now.

3) Transaction count

Count the rows in the export and compare them to what the statement visually suggests.

Questions to ask:

• Are there any blank lines that got treated like transactions?
• Did OCR split one transaction into two lines?
• Did a wrapped merchant description get duplicated?
• Did a fee line disappear because it was visually small?

4) Date integrity

Date errors are more damaging than they look because they change reconciliation timing.

Watch for:

• MM/DD vs DD/MM confusion
• leading zeros dropped from dates
• invalid rollover dates, like 31 April
• duplicate dates caused by line wrapping
• timezone or posting-date confusion when the bank shows multiple date columns

5) Amount sign consistency

This is one of the most common failure modes.

You want the exported amounts to obey a clear rule:

• money in = positive
• money out = negative

Or, if your downstream system expects the opposite, at least make it consistent.

Never let a file mix sign conventions in the same export. That is how a reconciliation that should net to zero ends up looking wrong by exactly the amount of a duplicated debit.

A worked QA example

Suppose you convert a statement with 143 visible transaction rows.

Your export produces 144 rows.

That alone is not a failure, but it is a reason to inspect the extra row.

When you do, you discover:

• one card payment got split across two OCR lines
• the merchant name repeated on the second line
• one partial payment amount was extracted separately

That means your exporter did not “add a row.” It misread a wrapped layout as two transactions.

Now compare totals:

• statement debits: 78,420.55
• exported debits: 78,920.55
• variance: 500.00

That variance is not random. It tells you the broken row likely involves a round number or fee line. You now know exactly where to look.

This is the kind of fast triage that turns QA from guesswork into a repeatable process.

The QA checklist I would actually use

Before export

• Confirm the source PDF is the right statement period
• Confirm the PDF is complete, not a partial download
• Confirm password protection or image quality is not degrading OCR
• Confirm you know the bank format and whether it uses posted date, transaction date, or both

After export

• Check row count against the statement
• Check opening and closing balances
• Check for duplicate transactions
• Check for missing transaction types, especially fees and reversals
• Check date range boundaries
• Check amount signs and decimal precision
• Scan descriptions for obvious OCR noise
• Validate the file opens cleanly in the target format

Before import

• Confirm column names match the importer’s expected schema
• Confirm currency is correct
• Confirm there are no empty required fields
• Confirm there are no accidental merged rows
• Confirm the file size is plausible for the statement period

CSV, XLSX, and JSON each need a different QA lens

CSV

CSV is the easiest place to catch problems because it is plain and unforgiving.

Look for:

• comma issues in descriptions
• quote escaping problems
• shifted columns
• hidden line breaks inside fields
• accidental truncation

CSV is best when you want a quick “truth file” that humans can inspect.

XLSX

XLSX is easier for reviewers, but it can hide problems behind formatting.

Look for:

• wrong column types
• date cells stored as text
• number cells stored as strings
• hidden rows or filters
• weird sheet names or broken formulas

XLSX is best when finance people need to review or annotate before import.

JSON

JSON is best when systems care about structure.

Look for:

• invalid nesting
• wrong field names
• null values where required fields should exist
• wrong data types for amounts or dates
• duplicated transaction objects

JSON is the format that tells you whether the exporter is structurally trustworthy.

A simple quality scorecard

Use a 100-point score so every export gets judged the same way.

A score under 90 means human review before import. A score under 80 means the export should not move forward.

Why this matters for month-end close

Month-end close is not the place to discover that a bank export had a bad date or duplicated fee.

When QA is weak, finance teams spend time:

• investigating differences that are not real
• reclassifying the same row twice
• checking whether an expense was missed or moved
• manually patching imports

When QA is strong, reconciliation gets boring in the good way. That is the goal.

The practical workflow

Here is the workflow that actually holds up:

1. Convert the PDF to CSV, XLSX, or JSON.
2. Compare transaction count and date range.
3. Verify opening and closing balances.
4. Scan for anomalies in descriptions, signs, and missing rows.
5. Review the file in the format the finance team will actually use.
6. Only then import or hand off.

That is the difference between “converted” and “ready.”

Internal links that help the reader continue

• Bank Statement PDF Guide
• Bank Statement Converter Guide
• Bank Statement Example Guide
• What Is a Bank Statement?

External references worth keeping nearby

• IAS 1, Presentation of Financial Statements
• Xero bank reconciliation help
• QuickBooks bank reconciliation help

Final rule

If the file would make a finance person hesitate, it is not ready.

QA is not about perfection for its own sake. It is about protecting reconciliation from avoidable garbage.

Make the export boring, deterministic, and easy to trust. That is the whole game.