A bookkeeper rarely needs to sign in to client bank accounts. Monthly statements and a view-only user cover almost every task. When access is truly needed, ask the client to create a named user with view rights only. Never accept the owner's own login, because nobody can then tell your actions from the owner's.
Should a bookkeeper have access to client bank accounts at all?
Most bookkeeping work needs the bank's records, not the bank's controls. Categorizing, reconciling and closing a month all run on statements and transaction history. A sign-in to the bank becomes useful only for checking a pending item mid-month or downloading a statement the client forgot to send.
It helps to list what you actually do with a client's bank data before you ask for any access. For a typical small business client the list looks like this:
- Read the month's statement and every transaction on it.
- Compare the closing balance with the books.
- Look up a check image or a deposit detail when a line is unclear.
- Occasionally pull an older statement for a catch-up month.
Not one of those tasks moves money. That matters, because the risk of bank access comes almost entirely from the ability to pay, transfer or change account details. If the work never moves money, the access should never allow it.
There is also a client-relationship reason to keep access narrow. When a payment goes wrong at a client's business, the first question is who could have sent it. A bookkeeper who could only read statements is out of that conversation in one sentence. A bookkeeper holding the owner's password is in it for weeks.
Four routes to client bank account access, ranked by risk
There are four common ways a bookkeeper reaches a client's bank data: the owner's own login, a separate user with full rights, a separate view-only user, and no login at all with statements forwarded each month. Risk falls as you move down that list, and so does the effort to set things up.
The table below compares them. The risk levels are a judgement for a typical small practice, not a formal rating.
| Route | What the bookkeeper sees | What the bookkeeper can do | Record of who acted | Risk |
|---|---|---|---|---|
| Owner's own login | Everything | Everything, including payments and payee changes | None: the bank sees one person | Highest |
| Separate user, full rights | Everything | Payments and transfers, subject to bank limits | Yes, under the bookkeeper's name | High |
| Separate user, view-only | Balances, history, statements | Download and read only | Yes, under the bookkeeper's name | Low |
| No login, statements forwarded | The statements the client sends | Nothing inside the bank | Not needed | Lowest |
Two columns decide most cases. "What the bookkeeper can do" sets how much damage a stolen password could cause. "Record of who acted" sets whether you can prove what you did not do. A route that scores badly on both, like the owner's own login, should be off the table even for a trusted, long-standing client.
The forwarding route has one cost: you depend on the client to send statements on time. The view-only route removes that dependency while keeping the money controls out of your hands, which is why many practices treat it as the default for clients who are slow to send files.
Why borrowing the owner's bank login backfires
Using the owner's username and password makes you indistinguishable from the owner. The bank's records show one person, so every transfer, payee edit and password reset looks like the owner did it. That leaves you with no way to prove you did not make a change.
The problems stack up quickly:
- Multi-factor prompts go to the owner's phone. Each sign-in then needs a text message relayed to you, which trains both of you to pass codes around. Passing codes is exactly what phishing relies on. The post on phishing scams aimed at bookkeepers and their clients shows how a fake "bank verification" request exploits that habit.
- Bank terms may forbid it. Read the client's online banking agreement: many tell customers to keep their credentials to themselves. If money is lost through a shared login, that clause can weaken the client's position with the bank.
- Your insurance may not respond cleanly. An insurer looking at a loss will ask whose credentials were used. The guide to what cyber insurance for bookkeepers covers explains why the facts around access shape a claim.
- Access never ends. The owner rarely changes the password after you leave, so a former bookkeeper keeps working credentials for years.
The same logic applies to the client's accounting software. QuickBooks Online, for example, has a separate route for this: a company admin can invite an accounting firm, and QuickBooks Online help on inviting accountant users notes that accountant users invited this way do not count toward the company's user limit. If the books have a named route for you, the bank account deserves one too.
Setting up a view-only bank user for the bookkeeper
A view-only bank user is a separate sign-in that the client creates for you inside their online banking, with rights limited to balances, history and statements. Many business banking services offer this, often under a name like "user management" or "sub-users". The client sets it up; you never handle their own credentials.
What to ask the client for
Send the client a short written request rather than explaining it on a call. Ask for:
- A user in your name, using your work email address, not a shared practice inbox.
- Rights to view balances, view transaction history and download statements.
- No rights to send payments, add payees, approve transfers or change contact details.
- Multi-factor sign-in set up on your own phone or authenticator app.
- Access to only the accounts you keep books for, if the bank lets them choose.
Check what you received
When the user is ready, sign in once and confirm the limits yourself. Try to open the payments screen. If it is visible and usable, tell the client straight away and ask them to remove the right. Write down the date the access began and which accounts it covers. That note goes in the client's file next to your engagement letter.
Protect the sign-in like client data
A view-only user still shows full account numbers, names and every transaction. Keep the password in your practice's password manager and turn on multi-factor sign-in. The FTC's guide to the Safeguards Rule asks covered businesses to require multi-factor authentication for anyone accessing customer information, and it is a sensible bar for any bookkeeping practice.
What if the client's bank has no bookkeeper role?
Some banks, especially those built for personal customers, offer no extra users or only full-rights users. In that case the safest answer is no login for the bookkeeper. Switch the client to sending statements each month, and use the bank's own statement download on the client's side.
A few situations come up often enough to plan for:
- The bank offers only full-rights users. Decline it unless your engagement covers paying bills. If it does, ask the client whether the bank can require a second approval for payments above a set amount, and keep that limit in writing.
- The client offers their password anyway. Thank them and explain, in one sentence, that you would then be unable to prove what you did not do. Most owners accept that at once.
- The account is a sole proprietor's personal account used for business. Personal banking almost never has a bookkeeper role. Forwarded statements are the only clean option, and you should agree which transactions are business before the first month.
- A card account sits with a different issuer. Treat each issuer separately. One client can have a view-only user at the bank and forwarded statements for the card.
Whatever you agree, write it down. A two-line note saying "Bank: view-only user for Jane Doe from 2026-03-01. Card: statements forwarded monthly" saves a long conversation later.
Statement forwarding in place of bank account access
Statement forwarding means the client sends each month's PDF statement to you, and you never sign in to the bank. It removes the bank login from your risk entirely. The trade-off is timing, since the month waits on the client, so the forwarding has to be easy enough that clients actually do it.
Make the route simple and consistent:
- Give each client one place to send statements, not your personal inbox.
- Ask for the bank's downloaded PDF rather than a phone photo of a paper statement.
- Agree a date each month, such as the fifth, and send one reminder if nothing has arrived.
Email attachments are not ideal for this, and the post on uploading client bank statements securely compares the safer channels. With AutoBankConvert, clients never need a login of their own: you upload their statements or forward them to your firm's inbox, and each file is matched to its client before conversion.
Forwarded files also need tidy handling once they land. Statements arrive with names like "eStatement (3).pdf", and the exports that come out of a batch need names that say which client and month they cover. The guide to naming exported files from a batch run gives a pattern that keeps a month of client files sorted.
Ending bookkeeper bank access when work or staff changes
Bank access should end the day the reason for it ends: when an engagement finishes, when a staff member leaves your practice, or when a client moves to statement forwarding. The common mistake is assuming the client will remove you. Most will not, so the bookkeeper has to ask.
Build the removal into your routine:
- Keep an access list. For each client, record who in your practice has a bank user, at which bank, with what rights and since when.
- Remove on departure. When a staff member leaves, email every affected client the same day asking them to delete that person's bank user. Confirm in writing when it is done.
- Remove on disengagement. Your closing letter to a departing client should ask them to delete every bank user belonging to your practice.
- Review once a year. Ask each client to look at their bank's user list and confirm only current, named people from your practice appear on it.
One edge case deserves care. If you ever did hold an owner's password in the past, ask the client to change it now, even if you never used it. You cannot remove yourself from a shared login, and an unchanged password is access you still technically have.
Keeping bank access narrow, named and short-lived costs little and protects both sides. If you would rather work from statements alone, AutoBankConvert converts and categorizes a client's forwarded PDFs in batches, so a bookkeeper can close the month without ever signing in to the client's bank.