Most business software assumes one person belongs to one company. Real working life doesn’t work like that. A bookkeeper looks after nine businesses. A director sits on two boards. A contractor invoices through their own company while doing the books for a client.
Here, who you are and which company you’re acting for are two separate things. You sign in once, and your permissions are whatever that particular company granted you.
What you can do
- Use one login for every company you’re involved with, and switch between them.
- Hold a different role in each: an administrator in one, a read-only viewer in another.
- Invite someone to your company by email, with the permissions they should have.
- Let someone ask for access, and approve or decline it.
- Share a join code rather than explaining which company you mean.
- Start people from a role preset - administrator, accountant, employee, invoice only, read only - and adjust from there.
- Set permissions per module and per action, so viewing the ledger and posting to it are separate rights.
- As an accounting practice, keep a roster of client companies and work across them.
- Revoke access, including a practice’s access, from the company’s own settings.
How it works in practice
Switch company from the header. The switcher lists the companies you’re a member of, plus any client companies you reach through a practice. Everything you do after that - every list, every report, every document - belongs to the company you’re acting as.
Invite the people you know (Settings → Company access). Enter their email, set the permissions they should have, and they get a link that adds them to your company when they accept. If they don’t have an account yet, accepting creates one.
Let people ask, when you don’t know their address. Share your join code and they can request access instead. The owner gets emailed, approving creates the membership, declining is a click, and requests expire on their own.
Grant permissions from a preset, then adjust. The presets are starting points for the roles most companies actually have. From there the matrix is per module and per action - create, view, modify, delete - so “can raise an invoice but not delete one” is an ordinary setup rather than a compromise.
If you’re an accounting practice, add clients to a roster. With the client’s join code you add their company to your practice, and from then on it appears in your switcher alongside your own. The client can see which practices have access from their own settings, and can revoke one without affecting another.
The owner keeps the keys. Whoever’s company it is always has full access and can’t be locked out by a permission change, which matters the day somebody edits the role they were using.
Good to know
- Permissions are denied unless granted. Every action needs a specific permission, and a new role starts with nothing rather than everything. That’s the safe direction, but it does mean a newly invited colleague will hit refusals until their role is right, so set it up together on their first day.
- Roles are per company, not per person. Being an administrator of your own company grants you nothing in a client’s, and the other way round. There’s no global “power user”.
- The company you’re acting as decides what you can see. Data is separated at the point every query is made, not by remembering to filter, so asking for another company’s records simply returns nothing of theirs.
- Hiding a button isn’t security, and isn’t treated as such here. The interface hides what your role can’t do as a convenience. The refusal that matters happens on the server regardless.
- A practice’s access is visible to the client and revocable by them. If you’re the practice, expect that. If you’re the client, check that screen occasionally.
- Removing someone doesn’t remove their work. Documents, journals and timesheets they created stay exactly where they are, which is what an audit trail means.