Bank statement checklist for a new bookkeeping client

A new client sends eleven PDFs, two screenshots and a spreadsheet called "bank final v3". You need twelve months of transactions for two accounts. Before converting anything, you need to know what is present, what is missing and what has already reached the books.

This checklist gives a bookkeeping practice a repeatable way to request statements, check coverage and hand the files to whoever handles the import. It includes a client message you can copy and an example intake register. The example is fictional; it is a workflow, not a customer case study.

1. Send a specific request for statements

"Please send your bank statements" leaves too much open to interpretation. Specify the accounts, dates and file types you need. Ask whether any account was opened or closed during the period, and whether another bookkeeper has already imported part of the history.

Here is a message to adapt and send through your normal client channel:

Please upload the bank-issued statements covering [start date] through [end date] for each account used by the business, including relevant savings accounts, credit cards and separate currency accounts.

Please include every page, including pages without transactions. If your bank also provides a transaction download in CSV format, include that alongside the PDF statements. We use the statements to check the balances and date coverage.

Let us know about accounts opened or closed during this period, any missing statements, and any dates already entered into the accounting software. Upload files through [approved client portal]. Please do not send online banking login details. If a PDF needs a password, tell us so we can arrange access through our agreed secure process.

Adjust the request to the engagement. For example, a business with a EUR account and a GBP account needs two separate coverage lists, even if the bank presents both under one login. Ask for documents relevant to the work rather than requesting every personal account by default.

2. Build an intake register before opening the converter

Use a spreadsheet with one row per account and statement period. Keep account identifiers masked in the working register. Record the exact dates shown on each statement: a filename containing "August" does not establish that it covers 1–31 August.

Add columns for opening balance, closing balance, source filename, conversion status, review status and import status. Keep the last three separate. "Converted" means a table exists; "reviewed" means someone checked it; "imported" means it reached a named destination account.

3. Check pages, dates and balance continuity

Look for page numbering such as "2 of 4", a complete transaction section and the stated opening and closing balances. A missing page can remove transactions without making the remaining PDF look broken. Screenshots may omit headings, account details or the final lines of a page.

For consecutive statements on the same account, compare the earlier closing balance with the next opening balance. If July closes at €4,820.15 and August opens at €5,120.15, record a €300 difference to investigate. Check the account, currency, dates and whether the documents are actually consecutive. Do not insert a €300 transaction just to connect them.

4. Use the bank download when it is usable; convert PDF gaps

If the bank supplied a usable CSV for the required period, start there and check it against the statement. Conversion is useful when the history is only available as a PDF, or the supplied spreadsheet cannot be traced back to a reliable source.

For PDF-only periods, convert a statement with StatementEdge, then review the extracted transactions and balance result before exporting. Keep accounts and currencies separate, and preserve the original file alongside the reviewed export in your own approved records system. Review our security information before uploading client documents.

5. Mark the boundary between existing records and new imports

Ask the person responsible for the books which periods are already present and which account receives the upload. Check the actual records, including any bank feed overlap, before selecting transactions to import. A full statement can be useful for verification even when only some of its transactions need uploading.

Intuit's manual upload guidancerecommends checking existing account records to avoid creating duplicates. Apply that check to each account rather than assuming all of a new client's history is absent.

For example, if a feed already contains 16–31 August, review those lines against the full August statement before importing the missing earlier period. Document the selected rows and the overlap decision. The next reviewer should not have to reconstruct why the import file has fewer transactions than the statement.

6. Finish with a reviewable handoff

• Every requested account and period is present, or a missing item has an owner.
• Original statements and reviewed exports are clearly linked.
• Amounts, dates, transaction counts and balance differences have been checked.
• The destination account and any excluded overlap are recorded.
• Open questions are listed separately from completed imports.

A matching balance is one part of that review. Our worked example on missing transactions in a CSV that still balancesshows why checking the rows matters too. For the wider practice workflow, read our guide for accountants and bookkeepers.

Reuse the request message and intake register for the next client. The objective is a clear handoff: another member of the practice can see exactly what was received, what was checked and what still needs attention.