# How to Upload Client Bank Statements Securely

- Author: AutoBankConvert (https://www.autobankconvert.com)
- Published: 2025-05-03
- Updated: 2025-05-03
- Category: Security and trust
- Canonical: https://www.autobankconvert.com/blog/upload-client-bank-statements-securely

> How to upload client bank statements securely to a converter: the encryption, retention and access controls to expect, and the questions to ask a vendor.
To upload client bank statements securely, send them only to a service that encrypts files in transit and at rest, lets you set how long originals are kept, and limits who can open each client's files. Skip email attachments and shared logins. Ask the vendor ten plain questions before the first upload, and write down the answers.

## What is on a bank statement that needs protecting?

A client's bank statement holds more than a list of payments. It shows the account holder's name and address, a partial account number, every payee and payer, and the balance on each day. That mix makes it useful to a thief, so treat each statement as sensitive from the moment it arrives.

### The fields that matter most

Statements usually mask the account number to its last four digits, but the rest of the page is still revealing:

- **Name and address** of the account holder, which on a sole proprietor's account is a home address.
- **Payees and payers**, which show who the client buys from, who pays them and which employees or contractors they pay.
- **Balances**, which tell a stranger how much cash the client holds.
- **Check images or reference numbers**, on banks that print them in the statement.

None of these is a password. A statement cannot be used to log in to the bank on its own. The risk is different: someone can use it to impersonate the client, craft a convincing phishing message, or learn the client's business. A bookkeeper who holds fifty clients' statements holds fifty such files, so the practice is a more attractive target than any one client.

### Why the bookkeeper carries the duty

The client gave you the statements so you could do a job. They did not agree to have them sit in an inbox, a downloads folder or a vendor's server for years. If a file leaks, the client will ask you what happened, not the vendor. That is why a bookkeeper needs a short list of checks to run on any tool that touches statements, and why the rest of this post is organized around that list.

Security here is mostly about limiting where copies exist and who can open them. Every extra copy of a statement is another place it can leak from. A secure upload therefore does three jobs: it protects the file while it travels, it protects the file where it is stored, and it keeps the number of copies small.

## Encryption in transit and at rest for uploaded statements

Encryption in transit protects a statement while it moves from your computer to the converter. Encryption at rest protects the stored copy on the vendor's disks. A secure upload needs both, because each covers a stage the other does not.

### In transit

Data in transit is encrypted when the connection uses HTTPS. You can see this in the browser: the address starts with `https://` and the browser shows a lock icon. If a vendor offers an upload page that loads over plain `http://`, do not use it. The same goes for any upload link sent to you by email that you did not expect, since a fake page can look identical to a real one.

HTTPS protects against someone reading the file on the network between you and the vendor, such as on a hotel or cafe connection. It does not protect the file once it arrives, and it does not tell you the site is the right one. Check the domain name yourself before you drag files onto a page.

### At rest

Encryption at rest means the files are scrambled on the vendor's storage, so a stolen disk or a misconfigured storage bucket does not hand over readable statements. The vendor holds the keys, so the term does not mean the vendor cannot read your files. It means an outsider who gets the raw storage cannot.

AutoBankConvert states on its homepage that files are encrypted in transit and at rest, and that you choose how long originals are kept after export. Whatever tool you use, expect that sentence, or a stronger one, in the vendor's own words. If you cannot find it, ask in writing.

### What encryption does not cover

Encryption is only one layer, and it does not answer these:

- Who at the vendor can open your files, and under what conditions.
- Whether a file stays on the server after you have exported your results.
- Whether another user of the same service can ever see your clients' files.
- What happens to the copy sitting in your own downloads folder.

Those gaps are why the checklist in the next section goes beyond encryption.

## Questions to ask before uploading client statements

Ask the vendor these ten questions before the first upload, and keep the answers with your practice records. A good answer is specific and written down. A vague answer ("we take security very seriously") is a reason to keep asking, or to look elsewhere.

### The vendor checklist

The table below is a template. The right-hand column describes what a good answer looks like, so you can judge a reply quickly.

| # | Question | What a good answer looks like |
| --- | --- | --- |
| 1 | Are files encrypted in transit? | Yes, over HTTPS for every upload and download, with no plain HTTP option. |
| 2 | Are files encrypted at rest? | Yes, stored files are encrypted, stated in the vendor's own documentation. |
| 3 | How long do you keep my original files? | A stated period, and you can choose it, not "as long as we like". |
| 4 | Can I delete a statement or a whole client on request? | Yes, with a clear way to do it and a note on when copies are gone. |
| 5 | Are each client's files kept apart? | Yes, each client has a separate workspace and no file or rule crosses between them. |
| 6 | Who inside your company can open my files? | A short, named category of staff, only for support you request. |
| 7 | Is my clients' data used to train models or shared with others? | No, stated plainly in writing. |
| 8 | Can I control who on my team sees which client? | Yes, with roles or per-client access, not one shared login. |
| 9 | What do you do if there is a breach? | A described process, including how and when you would be told. |
| 10 | Where do I report a security problem? | A named contact, such as a dedicated address. |

### Reading the answers

Questions 3 and 4 matter most for a bookkeeper, because they decide how many copies of a client's statement outlive the job. The related post on [how long to keep client bank statements](/blog/how-long-to-keep-client-bank-statements#originals-versus-converted-files-which-to-keep) explains which files to keep after conversion and which to delete.

Question 7 matters more than it looks. Your engagement letter probably promises the client that their data is used only for their books. A vendor that trains its models on uploaded files would break that promise on your behalf. Get the answer in writing, not in a sales call.

Question 8 is where small practices go wrong. If three staff share one login, you cannot tell who opened what, and you cannot remove one person without changing the password for everyone. The [practice security checklist](/blog/bookkeeping-data-security-checklist) covers per-client access and former staff in detail.

### What the product says

AutoBankConvert is in early access, so read what it publishes and ask about anything it does not. Its homepage says that each client keeps their own accounts, rules and history, that clients never need an account unless you invite them, and that files are encrypted in transit and at rest. The site footer also has a mail link for reporting a security issue. For anything beyond those statements, such as staff access inside the vendor or breach handling, ask through [the get started page](/get-started) before you upload real client files.

## Upload habits that expose statements by email

The most common leak is not a hack. It is a statement forwarded through email, saved to a shared folder, or left in a downloads directory. These habits are quiet and constant, so a practice loses control of its files long before a breach shows up.

### Email attachments

Email is convenient for clients, who often send statements as attachments. The problem is that a copy then lives in the client's sent folder, your inbox, any phone that syncs your mail, and every backup of each. Ordinary email is also not guaranteed to be encrypted between servers.

A few habits reduce the damage:

1. Ask clients to use a secure upload link or a forwarding address you control, rather than a personal inbox that others read.
2. Move each statement out of the inbox into the client's folder or the converter as soon as it arrives, then delete the email.
3. Never reply to a statement email with the file attached again. Send a link to the secure location instead.
4. Turn off automatic download of attachments to a shared computer.

The post on [how to collect bank statements from clients](/blog/how-to-collect-bank-statements-from-clients) lays out the request wording, but the security rule is simple: fewer copies, in fewer places.

### Shared drives and download folders

A statement saved to "Downloads" stays there until someone deletes it. Over a year, that folder becomes an unmanaged archive of every client you have served. Set a weekly habit to clear it, and convert from a client folder you control instead.

Shared drives raise a different problem: link sharing. A link that lets "anyone with the link" view a folder will keep working after the job ends, and forwarding the link gives access to the whole folder. Share with named people only, and review the sharing list when an engagement ends.

### Messaging apps and phone photos

Clients also text photos of statements. A photo is a poor source for conversion, and it also sits in a phone's camera roll, often backed up to a personal cloud account. If a client insists on sending photos, treat the file as a temporary courtesy: move it into the client's folder, ask for the real PDF, and delete the chat copy.

## When should you not upload a statement at all?

Do not upload a statement when the client has not agreed to a third-party tool, when the file belongs to a client whose rules forbid outside processing, or when you cannot verify where the file will go. In those cases, process it by hand or on a machine you control.

### Cases that call for a pause

- **The engagement letter says nothing about software.** Tell the client you use an online converter, name it, and get a yes before the first upload. The post on [client confidentiality in bookkeeping](/blog/client-confidentiality-in-bookkeeping#confidentiality-terms-in-a-bookkeeping-engagement-letter) includes a clause for this.
- **The client is a regulated body or a government contractor** whose contract restricts where financial records may go. Read the contract first.
- **You do not know the vendor.** An unfamiliar site that appeared in a search, with no named company or contact, should not receive client files.
- **The statement is not yours to hold.** A file a client forwarded from a spouse's or a partner's account needs that person's permission before it goes anywhere.
- **The device is not yours.** Do not upload client files from a public computer or a shared machine where the browser keeps downloaded copies.

### A short test before each new client

Before you upload the first statement for a new client, answer three questions: did the client agree to online processing, do you know where the file will be stored and for how long, and will you be able to delete it when the engagement ends? If any answer is no, fix that first. The checks take a few minutes, and they cost far less than explaining a leaked statement to a client.

If you are comparing tools at the same time, the guide to [bank statement processing software](/blog/bank-statement-processing-software) shows how to weigh security answers alongside features and limits. [AutoBankConvert's site](/) answers questions 1, 2, 3, 5 and 10; put the others to it, as to any vendor, before you upload real client files.