Before you upload a zip of bank statements, open it and look at what is actually inside. Flatten or rename nested folders, remove duplicate copies and anything that is not a PDF, and unlock protected files. A clean archive lets the batch match each statement to the right client and account instead of guessing from a messy path.
What is inside a client's statement zip before you upload it?
A client's statement zip is rarely just twelve tidy PDFs. Most archives are built by someone selecting a download folder and choosing "compress", so the zip holds whatever that folder held: statements, yes, but also receipts, spreadsheets, old copies and the folders a bank's export tool created.
Here is an example listing from a zip a client might send for one year of a checking account and a card. The names are made up.
| Path inside the zip | What it is |
|---|---|
| Statements/Checking/Jan.pdf | January checking statement |
| Statements/Checking/Jan (1).pdf | A second download of January |
| Statements/Card/2026-02.pdf | February card statement |
| Statements/Card/Feb_statement.pdf | The same February card statement, renamed |
| Taxes/1099-INT.pdf | A tax form, not a statement |
| Statements/Checking/export.csv | A spreadsheet export from online banking |
| __MACOSX/Statements/._Jan.pdf | A hidden file a Mac adds when it zips a folder |
Every row after the first one is a small problem. Opening the archive and listing its contents takes two minutes and shows you which of these you have.
Nested folders in a bank statement zip
Nested folders in a bank statement zip are a problem because the folder path often carries the only clue to which account a file belongs to. A file called "Jan.pdf" inside "Checking" is clear to a person. Once the folders are flattened or ignored, two files called "Jan.pdf" from two accounts look identical.
Fix this before you upload, not after. Rename each statement so the file name alone says the client, the account's last four digits and the month. Then the folder depth stops mattering. The post on a bank statement file naming convention gives a pattern you can apply across every client.
Watch for a second kind of nesting: a zip inside a zip. Some banks deliver a year of statements as one archive, and a client may zip that archive again with other files. Extract the inner archive and treat its files like any other statements.
Duplicate and non-PDF files in a statement zip
Duplicate and non-PDF files are the stray items most likely to waste a batch run. A duplicate statement can post a month twice if nobody catches it. A tax form, receipt or CSV export is not a statement at all, so at best it fails, and at worst it sits in the results and confuses the review.
Remove these before upload:
- Second downloads, often ending in "(1)" or "copy". Compare the statement period printed on the first page, not just the file size.
- Renamed copies, which are harder to spot. Two files with the same period and the same closing balance are the same statement.
- Hidden system files, such as a "_MACOSX" folder or files starting with ".". They are not documents.
- Tax forms, receipts and invoices, which belong in the client's records but not in a statement batch.
- Spreadsheet exports, which may be useful later but are not the bank's statement.
Keep a note of what you removed and why. If a file you set aside turns out to be the only copy of a month, you will want to find it again.
Password-protected PDFs inside a statement zip
Password-protected PDFs inside a statement zip cannot be read until they are unlocked. Zipping a file does not remove its password, and some banks protect every statement they send by email. A locked file in an archive will look normal in a listing and then fail when the batch tries to open it.
Unlock these files first, using the password the bank or client gave you, and save the unlocked copies in place of the originals. The guide on how to unlock password-protected bank statements in bulk covers doing this for a whole folder at once. If a file still fails after unlocking, the steps for handling failed statements in a batch conversion apply as they would to any other file.
A zip upload checklist for one client's statements
A zip upload checklist turns the checks above into one pass you can run on every archive. It works for a single client's year or a catch-up bundle. Run it in this order, because each step depends on the one before.
- Extract the archive to a new, empty folder for that client. Extract any zip found inside it too.
- Delete system files, such as "_MACOSX" folders and files whose names start with ".".
- Move out everything that is not a PDF statement: tax forms, receipts, spreadsheets, images of checks.
- Unlock protected PDFs and replace the locked copies.
- Open each remaining statement and note the bank, account ending and period.
- Remove duplicates that share an account and period.
- Rename each file with client, account ending and month.
- List the months you have for each account and mark any gap.
- Upload the cleaned folder and compare the number of statements the batch reports with the number you counted.
Step 8 matters for clients with several products. A zip with checking and a card can be complete for one and missing three months of the other. Card statements also follow their own closing dates, which the guide to credit card statement bookkeeping explains.
When should you unzip statements before uploading?
Unzip statements before uploading whenever the archive came from a client and you have not checked it, which in practice is almost always. The zip is a delivery package. It is not a good unit for a batch, because you cannot see its contents in a converter's queue, and a single bad file inside it hides among the good ones.
AutoBankConvert takes a folder of statements across banks and months and matches each file to its client, so the cleaned, extracted folder is the natural thing to upload. A folder of named PDFs also makes the results easy to read back: one file in, one statement out. If the client's statements come from several banks, the guide to bank statements from multiple banks covers what changes in that mix.
There is one case where keeping the archive whole is sensible: as the original record. Save the zip exactly as the client sent it in the client's folder, untouched, and work only on the extracted copy. If a question comes up later about what the client provided and when, the original archive answers it. When the extracted folder is ready, Get started is where you request a spot.