Reviewing a batch of converted statements goes fastest from the outside in. Confirm the batch is complete, clear the statements that failed their balance check, then sample the ones that passed, weighted toward scans, new banks and new clients. A passed balance check proves the lines add up, not that they belong to the right client or month.
What should you look at first in a converted batch?
Look first at the batch's counts: statements in, statements converted and statements held back. If converted plus held back does not equal what went in, a file went missing during the run, and nothing else in the review matters until you find it. Counts take a minute and catch the worst problem.
After the counts, open the held-back list. These are the statements the converter could not read or could not balance, and they are already known problems. Sort them by cause: unreadable scans, missing pages, locked files and real balance gaps each have a different fix, and some need the client.
Only then move to the statements that passed. Starting with the passed ones is the common mistake, because they look reassuring and absorb the time that the failures need.
Counting more than files
File counts can match while content does not. A practice that wants a firmer control can also count pages and transactions in and out of each run. The method is laid out in batch control totals for bank statements, and it suits large or multi-person runs best.
Which converted statements can you trust without opening?
A converted statement can be trusted without opening when it passed a balance check, came from a digital PDF, comes from a bank and layout you have converted cleanly before, and belongs to a client whose account list matches the batch. Those four conditions together leave little room for an error the check would miss.
The balance check carries most of the weight. When the opening balance plus every converted line equals the printed closing balance, no line was dropped, doubled or given the wrong amount, short of two errors that cancel exactly. AutoBankConvert marks a statement as done only when that sum holds, and flags it instead of exporting it when it does not.
Each of the other three conditions removes a different doubt:
- Digital PDF. The characters came from the bank's own file, so there is no optical misread.
- Familiar layout. The converter has read this bank's tables correctly before.
- Known client. The statement's account matches one you expected, so it was filed under the right books.
A statement that meets all four can skip a full read. A statement that misses one moves into the sample.
Sampling a large converted batch
Sampling a large converted batch means opening a set number of passed statements chosen by risk, not at random. Pick every statement that misses one of the trust conditions, then a small random share of the rest. The risk-based picks find most problems, and the random picks tell you whether your idea of risk is right.
The table below is an example sampling plan by batch size. The numbers are a starting point to adjust, not a standard.
| Statements that passed | Open all of these | Plus a random share of the rest |
|---|---|---|
| Up to 20 | Every scan, new bank and new client | 2 statements |
| 21 to 100 | Every scan, new bank and new client | 5 statements |
| 101 to 300 | Every scan, new bank and new client | 10 statements |
| Over 300 | Every scan, new bank and new client | 1 in 25 |
For each sampled statement, a quick open is enough. Compare three lines against the PDF: the first transaction, the last, and the largest. Check that the statement period and account digits on the converted result match the PDF header.
When the random sample finds something
If a randomly picked statement has a problem, your risk rules missed a case. Note what made it different, such as a new page layout from a familiar bank, and add that to the list of things that send a statement into the sample next month. For very large projects running over several weeks, the order of work in converting hundreds of bank statements in one project keeps sampling consistent across batches.
Converted batch review order, step by step
A converted batch review runs in six steps, and the order matters: completeness, failures, filing, sampling, categorization, then sign-off. Each step narrows what the next one has to look at. Here is the routine as a step list, with times for an example batch of eighty statements.
- Completeness (about 2 minutes). Statements in equals converted plus held back. Each client has one statement per account for the month.
- Failures (about 20 minutes). Sort the held-back list by cause. Request replacements from clients, unlock locked files, and rerun the ones you can fix today.
- Filing (about 5 minutes). Scan the client-by-client results for an account that appears under the wrong client, or a period that does not belong to this month.
- Sampling (about 15 minutes). Open the risk-based picks and the random share from the sampling table.
- Categorization (varies). Clear the lines held for review. Transactions the rules are unsure about go to a review queue with a suggested category, and approving one teaches that client's rules.
- Sign-off (about 2 minutes). Record the result, as described in the last section, then export.
The times are illustrative and depend on how many failures there are. The point of writing them down is to notice when one step starts taking far longer than usual, which usually means a new kind of problem.
Splitting the review between two people
In a practice with more than one person, the review splits naturally along the steps. Whoever ran the batch handles completeness and failures, because they know which files came in and which clients still owe a statement. A second person, ideally someone who did not prepare the folder, takes filing and sampling. Fresh eyes are better at noticing that a statement sits under the wrong client, since they read the account digits instead of assuming them.
Categorization usually belongs to whoever keeps that client's books, because they know the vendors and the rules. Sign-off can go to either person, as long as the note says who did which step. Avoid splitting by client instead, with each person reviewing their own clients end to end. That arrangement feels efficient, but it means nobody ever checks the person who prepared the batch, and the filing errors that a second reader would catch go straight into the books.
Converted batch errors that a balance check misses
A balance check misses errors that leave the arithmetic intact. The main ones are a statement filed under the wrong client, a transaction dated in the wrong year, the same statement converted twice, a sign reversed for an entire account, and a line with the right amount but the wrong description. Each needs a person, or a different check.
How to spot each:
- Wrong client. The statement balances perfectly in someone else's books. Check the account digits on the result against the client's account list.
- Wrong year. A December-to-January statement with every January line dated a year early. Sort each statement's lines by date and look at the ends.
- Duplicate statement. The same period appears twice for one account, often from a client upload and a forwarded email. Look for two results with identical opening and closing balances.
- Reversed account. A card account whose purchases came through as deposits. The statement still balances on its own terms, but the client's income jumps.
- Swapped descriptions. Two lines on one page with each other's payee names. Rare, but it misleads categorization. It shows up when a payee is coded to an account it never uses.
None of these is common in a well-run batch. They are worth knowing because a reviewer who trusts the balance check completely will never look for them.
Categorization is a separate review
A statement can convert perfectly and still be coded wrongly. Treat the conversion review and the categorization review as two passes. The first asks whether the lines are right. The second asks whether each line went to the right account.
Recording who reviewed a converted batch
Recording who reviewed a converted batch leaves a trail for the next month and for anyone who later asks how a figure reached the books. A short note is enough: the batch date, who reviewed it, the counts, the statements held back and why, the sample opened, and anything unusual found.
An example sign-off note, with invented values:
Batch 2026-07, reviewed by J. Okonkwo on 2026-08-04
In 82 / converted 78 / held 4 (2 blurred scans, 1 missing page, 1 locked)
Sampled 14 (11 risk-based, 3 random). One new layout found at a credit union.
Exported 78. Held 4 waiting on clients.
Store the note with the batch, not in someone's inbox. A written review step also belongs in the practice's security and quality records. If the practice keeps a written information security plan for bookkeepers, the review note is one of the controls it can point to, since it shows who handled which client files and when.
A batch tool that keeps results grouped by client makes this note quick to write. The mechanics of that grouping are covered in what a bulk bank statement converter does with a folder, and firms can request a spot at AutoBankConvert's Get started page to run their own month through it.