Failed statements in a batch conversion are files the converter could not read or could not balance, so it held them back instead of exporting them. Handle each one in four moves: read the failure reason, fix or replace the file, rerun only that file, then confirm every expected statement for each client converted before you call the batch finished.
Why do statements fail in a batch conversion?
A statement fails in a batch conversion for one of two broad reasons. Either the file itself is unusable, because it is locked, damaged, blurred or incomplete, or the file reads fine but the numbers do not add up. The first is a file problem. The second is a data problem, and it needs a different fix.
It helps to know the specific reasons, because each one points at a different person. Some fixes are yours, and some need the client or the bank.
File problems
- Password lock. The PDF opens only with a password, so nothing inside can be read. Banks and clients both add passwords, often to emailed statements.
- Unreadable image. A phone photo taken at an angle, a faint fax or a low-resolution scan can leave characters the converter cannot make out.
- Wrong document. A "statement" that turns out to be an account summary, a tax form or a screenshot of an app screen.
- Damaged file. A download that stopped halfway, or an attachment that was saved as zero bytes.
Data problems
- Balance gap. The opening balance plus the transactions does not equal the closing balance. A line was missed, read twice, or read with the wrong sign.
- Missing pages. The statement looks complete on page one, but a middle page is absent, so the totals cannot tie.
- Unmatched client. The file converted, but it belongs to a client or account you have not set up yet.
In AutoBankConvert, a statement is marked done only when its opening balance plus its transactions equals its closing balance. Anything that falls short is flagged and kept out of the export, which is why a failure list exists at all.
Reading the failure reason on a flagged statement
The failure reason on a flagged statement tells you whether to look at the file or at the figures. Start by opening the original PDF. If you cannot read it comfortably on screen, the problem is the file. If it reads well but the totals are off, the problem is a missed or misread line.
A few habits make this step quick.
First, check the page count against the statement itself. Most statements print "page 3 of 5" or similar in a footer. A file that holds four pages of a five-page statement will never balance, however many times you rerun it.
Second, look at the size of a balance gap, not just its existence. A gap that matches one amount on the statement usually means one line was dropped. A gap that is exactly twice one amount often means a credit was read as a debit. A gap that matches no single line may point to a fee or interest figure printed in a summary box rather than in the transaction list.
Third, compare the flagged statement with the same account's previous month. If last month converted cleanly and this month did not, ask what changed. A new page layout, a different scanner at the client's office or a forwarded copy instead of a download are all common answers.
Fixes for each kind of failed statement
Each failure reason has a standard fix, and most take a few minutes once you know which one applies. The table below is an example failure log from one batch. The clients, files and amounts are made up for illustration.
| File | Client | Reason | Fix | Rerun result |
|---|---|---|---|---|
| oakridge-hoa_operating_2026-08.pdf | Example Oakridge HOA | Password lock | Client sent the password by phone; file unlocked and saved again | Converted |
| oakridge-hoa_reserve_2026-08.pdf | Example Oakridge HOA | Balance gap of 1,250.00 | Page 2 missing from the download; client downloaded the full PDF | Converted |
| IMG_4471.jpg | Example Tile Works | Unreadable image | Asked for the bank's downloaded PDF instead of a photo | Converted |
| statement (2).pdf | Example Tile Works | Unmatched client | Second account at a new bank; account added to the client | Converted |
| summary_aug.pdf | Example Bike Shop | Wrong document | It was an account summary; client sent the real statement | Converted |
| card_2026-08.pdf | Example Bike Shop | Balance gap of 38.40 | Interest charge printed in a box; keyed by hand after review | Entered manually |
Notice that the two HOA files failed for different reasons. Associations often hold an operating account and a reserve account at the same bank, so one client can produce two unrelated failures in the same month. HOA bookkeeping from bank statements covers why those accounts must stay apart in the books, and that separation matters again when you fix them.
Locked files
A password-locked file needs to be unlocked with the right password and saved as an unlocked copy, then uploaded again. When a whole client folder arrives locked, doing them one by one wastes an afternoon. The guide to unlocking password-protected bank statements in bulk shows how to clear a stack at once and how to ask clients to stop adding passwords.
Unreadable scans
A blurred or skewed scan rarely improves on a second attempt with the same file. Ask for a better source. The bank's own PDF download is best. If paper is all the client has, a flat, straight, well-lit scan comes next. Mixing those scans with clean downloads is normal, and scanned and digital statements in one batch explains how to keep the scanned ones from slowing the rest.
Balance gaps
For a balance gap, find the page where the computed balance first drifts from the printed one. That page holds the missed line. If the gap comes from an incomplete file, get the full statement. If the file is complete and one line still will not read, a person can enter that line and note it.
Should a failed statement be rerun alone or with the next batch?
A failed statement should be rerun on its own, as soon as its fix is in hand, rather than added to next month's batch. A solo rerun keeps the original batch's results untouched, avoids converting good statements twice, and closes the client's month without waiting another four weeks for an unrelated upload.
There are two traps to avoid when you rerun.
The first is uploading the whole folder again. It is tempting when several files failed, because it feels simpler than picking them out. It creates duplicates of every statement that already converted, and those duplicates then need finding and removing before export. Pick out the fixed files and upload only those.
The second is uploading the fixed file next to the broken one. If the replacement and the original both sit in the batch, the converter may see two statements for the same account and period. Remove or archive the failed copy first, then upload the replacement, so there is only ever one live file per account per month.
Keep the failure log open while you rerun. Mark each line with the result as it comes back: converted, failed again, or entered by hand. A file that fails twice for the same reason needs a different source, not a third attempt.
Failed statements worth keying in by hand
Some failed statements cost less to type in than to fix. A short statement with a handful of lines, a page that will never scan well, or a one-off summary the bank cannot reissue are all candidates. Keying them in by hand is a sound choice when the alternative is chasing a client for weeks.
Signs that a manual entry is the better path:
- The statement has fewer than about ten transactions and the client is slow to respond.
- The only copy is a damaged paper original, and the bank no longer offers the period online.
- The same file has failed twice after real fixes, such as a fresh download and a better scan.
- A single line resists reading, and every other line converted and balanced.
When you enter a statement by hand, treat it with the same rule the converter applies. Add up the opening balance and every line you typed, and check that the result equals the closing balance before you post anything. Note on the failure log that the statement was entered manually and by whom. Six months later, when someone asks why one month looks different, that note answers the question.
Manual entry is also the moment to ask why the file failed in the first place. If the cause will repeat next month, such as a client who always photographs paper, fix the habit now. A short message with a clear request saves the same manual work every month.
Confirming the batch is complete once failed statements clear
A batch is complete when every statement you expected has either converted or been handled by a person, and you can show it. Clearing the failure list is not proof on its own, because a statement that never arrived does not fail. It simply is not there, and nothing flags it.
Run this check list once the reruns are back:
- Count expected statements per client. One per account per month, from your client list, not from the folder.
- Count what you have. Converted plus entered by hand should equal the expected count for each client.
- Check every failure log line has a result. No line should still read "waiting".
- Look for duplicates. Two converted statements for one account and one month means a rerun sat beside its original.
- Confirm each client's months run without a gap. An account that shows June and August but no July is missing a file.
- Export only after all five pass. Then each client's export holds the whole month.
Step one is the one that catches the quiet failures. Keep a simple list of each client's accounts and what you expect from each, and compare against it every month. A statement you expected and never received is a request to send the client today.
Once the counts agree, export per client as normal. For the wider picture of how a folder is sorted, converted and exported in one run, see what a bulk bank statement converter does with a folder. To run your own month-end folder through a converter that holds back anything that does not balance, request a spot with AutoBankConvert.