Multi-Accounting for Accountants and Lawyers: Client Portals

GetAntik editorial team · October 4, 2026 · 11 min read

How accounting and law firms manage dozens of client logins, 2FA, and bank portals safely with isolated browser profiles instead of one shared browser.

Why this is even a problem

An outsourced accounting firm usually doesn't have one client — it has twenty or thirty. Each one has their own online banking portal, their own tax authority account, their own e-document exchange login, sometimes a separate portal for a regulatory filing system or a benefits agency. A law firm adds court system portals, registries, and notary services on top of that.

Formally, many of these systems have a built-in delegation mechanism: the client invites the accountant and grants rights, the bank accepts a power of attorney, the tax authority registers an authorized representative. This is the correct path, and where a service supports it, it should be the first choice — not something to route around with shared logins.

The problem is that this isn't available everywhere. Some banks don't let one login work with ten different business portals at the same time — the system is built for one browser per one user and keeps mixing up cookies and sessions when you switch context. Some services have no "accountant + client" role model at all, only the client's own username and password, which they handed over to a staff member directly. And then there are cases where the client has no digital signature or no ability to log in themselves and grant delegation — so it's simpler to log in with their credentials directly, with their consent.

The result: a staff member keeps 15 tabs open in one browser, a profile keeps asking to re-authenticate, a two-factor code lands in the wrong inbox, and the bank occasionally locks the session, suspecting that too many businesses are switching on one device. This isn't about bypassing rules — it's about organizing a workstation in a case where the platform's own rules permit representative access, but the tooling for it doesn't really exist.

What goes wrong with manual setups

Session mixing. One browser, one cookie jar — meaning logging into Client B's portal can silently end Client A's session. The accountant doesn't notice right away — only when Client A complains they can't log in.

Shared email and 2FA. If access to a client's portal depends on the client's own email, and two-factor codes land there too, two staff members can't work with the same client in parallel — only in turns, calling each other to check who's "in the system" right now.

Lost access when someone leaves. Passwords and codes sit in desktop notes, a personal Telegram chat, a spreadsheet on a shared drive. An accountant quits, and nobody is quite sure which portals they handled or how to get back in.

Device-fingerprint lockouts. Banking and some government systems fingerprint the device. The same browser but different client IP addresses (a client might have a business registered in another region) sometimes looks suspicious to the bank's antifraud system — it expects access from the client's usual location, not from the accountant's office in another city.

No audit trail. If something gets changed in a client's portal at the wrong time — say, a payment order gets submitted early — it can be hard for the firm's manager to quickly figure out which staff member was in that portal and when.

An approach built on isolated profiles

In this scenario, an antidetect browser solves a specific engineering problem: it gives each client a separate, isolated browser profile with its own cookies, its own history, and a managed fingerprint — instead of keeping all the access in one window of an ordinary browser.

The practical setup looks like this:

1. One profile per client. The bank, tax portal, and e-document system for that client are opened inside their profile. Sessions don't cross over between clients, even with twenty profiles open at once.
2. A proxy matching the client's location. If a client's business is registered in a particular region, the profile gets assigned a proxy with a matching exit IP — timezone and interface language are picked up automatically from the proxy instead of revealing that the login is coming from a different city. This cuts down on false positives from the bank's antifraud system, which reacts to unusual login geography.
3. 2FA storage inside the profile itself. If the client has handed over a secret key for one-time codes (not just a password), that key is stored tied to the profile rather than to a specific staff member's phone — the code gets generated in the same place where the portal is open.

1. Templates for new clients. When a new client comes on board, a profile is created from a template: the right bookmarks for the bank login, the tax portal, the e-document system, the registry. That saves five to ten minutes per new client and avoids a staff member digging through old messages for a link.

For more on how bookmarks, cookie warm-up, and profile templates work when onboarding a new account, see the piece on account warm-up and profile preparation — the logic carries over here, just with a client portal instead of an ad account.

Team workflows and client handoffs

In a firm with five to ten accountants, clients are almost always shifting between staff members: one is on leave, another moves to a different area, a third resigns. The key question is what happens to access at that moment.

A role model splitting owner, admin, and regular staff covers most of the risk:

• The owner sees the firm's entire pool of client profiles and can reassign any of them.
• An admin (say, a senior accountant) manages their team and the profile limits per person.
• A regular staff member only sees the client profiles assigned to them and can't export passwords or 2FA keys out of them.

Handing off a client to another staff member works as a profile handoff — the password and keys stay inside the profile, the new owner gets working access to the portal but not a bare password they could take with them if they leave. This is its own fairly sensitive topic, covered in more detail in the article on roles, limits, and profile handoff in a team, which also covers setting per-person limits so that one person doesn't end up carrying a critical mass of clients with no backup access.

A useful extra feature for training new staff and resolving disputed client situations is live view and remote control of a colleague's browser. A senior accountant can see exactly what a staff member is doing in a client's portal right now, without asking for a screenshot or having to take over the password.

Security and responsibility for other people's data

For a firm holding access to dozens of clients' banking and tax portals, security isn't a formality — it's direct legal liability. If data leaks because of a compromised workstation or a breach at a contractor's server, that's a hit to the entire firm's reputation and potential grounds for client claims.

The practical minimum for this setup:

• Encryption of profile data on the device, not only on the server. If profile data is encrypted with the account password on the device itself, and the server only stores an encrypted copy, a server-side breach or leak doesn't expose client passwords in readable form.
• An activity log — who worked in which profile and when. This isn't just about monitoring staff; it's about being able to quickly answer a client's question like "who logged into my portal on Thursday at 3pm."
• A separate password per profile for particularly sensitive portals — access to online banking with payment-signing rights is worth locking behind an extra password even within your own team, so a stray click doesn't result in the wrong staff member sending a payment.

A detailed breakdown of encryption, 2FA storage, and access recovery when a device is lost is in the article on profile security and data encryption. A general description of the mechanism is on the GetAntik security page.

Common mistakes firms make while building the process

Keeping client passwords in a shared spreadsheet on a drive. This works fine with three staff members and ten clients. At fifty clients, the spreadsheet becomes a liability: it gets shared more widely than it should, versions diverge, nobody remembers which one is current.

One shared login in the e-document system for the whole firm instead of individual staff accounts. If the system supports multiple accounts with different rights, it's better to set those up per staff member rather than split one login. A shared login makes it impossible to tell who actually sent a document if a client later disputes that it was sent.

Ignoring official delegation where it exists. If the tax authority or bank lets a client formally grant power of attorney to a representative through a built-in mechanism, that should be used instead of logging in directly with the client's credentials. It's formally more correct and removes some liability from the firm in case of a dispute.

Not tracking who currently handles which clients. Without an explicit "staff member — clients" list, a firm's manager only finds out about a gap when the client writes in that nobody has logged in for a month.

Giving a new hire every access "just in case." A per-person profile limit, expanded gradually as the person actually starts handling a client, reduces the risk if they resign suddenly — the scale of potential damage is smaller.

If a firm is running not ten but a couple hundred client profiles at once, it's worth thinking through group and tag structure early on, so the right portal can be found in seconds instead of scrolling the whole list — that's covered in a separate piece on organizing a large profile pool.

Comparing approaches

The topic of VMs and separate devices as an alternative is covered in more detail in the article comparing antidetect browsers, virtual machines, and separate devices — for a firm with dozens of clients, VMs almost always lose on maintenance cost.

How to estimate the number of profiles you need

For a small accounting firm, the math is simple: one profile per client business plus a couple of service profiles for the firm's own internal tools (accounting software, internal portal). A firm with 25 clients fits comfortably within a 100-profile plan with room for new clients and test environments; a firm with 150–200 clients usually moves up to a larger plan. Current limits and pricing are on the pricing page — you can start with the free 3-profile plan to try out the setup on a few clients before switching over fully.

FAQ

Is it legal to log into a client's portal using their own username and password? If the client handed over access themselves and agreed to this way of working — yes, this is normal outsourcing practice. But wherever the platform supports official delegation (power of attorney, representative invite), that's the better option: it removes liability questions and usually gives more reliable, less lockout-prone access.

Can a bank lock a client's portal if it sees a login coming from the accounting firm's IP instead of the client's region? This happens, especially with banks running strict antifraud checks. The fix is using a proxy with an exit point in the client's region for that profile, so the browser's timezone, language, and geolocation match what the bank expects. More on choosing the right proxy type for the job is in the article on proxies for multi-accounting.

What happens to access if a client switches to a different accountant within the firm? The client's profile is handed off to the new responsible staff member without ever exposing the bare password — the old staff member loses access to the profile, the new one gets it in working order. This removes the risk of a departing or reassigned employee taking client passwords with them.

Does a client need to consent to the use of an antidetect browser for managing their portal? There's usually no formal requirement, but transparency with clients is good practice: it's worth stating in the service agreement that access to their portals is handled through the firm's internal tools with security measures in place, rather than passed on to third parties.

multi-accountingaccounting firmsclient access management2faantidetect browser