ObraLedger

Type to search.

Users, roles and companies

One login, as many companies as you work with, and an independent set of permissions in each - which is what an accountant needs and most systems refuse.

On this page

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 a colleague by email, with the permissions they should have.
  • Start people from a role preset - administrator, accountant, employee, invoice only, read only - and adjust from there.
  • Set permissions per area and per action, so viewing the ledger and posting to it are separate rights.
  • Invite your accountant’s firm, or approve one that asks to take you on.
  • Choose what that firm may do in your books, whichever side asked first.
  • Change your mind later without evicting the firm and starting again.
  • See which people at the firm can open your company.
  • Revoke a firm’s access from your own settings, at any time.
  • As a firm, keep a roster of client companies and decide which of your staff works on each.

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 as a firm. Everything you do after that - every list, every report, every document - belongs to the company you’re acting as.

Invite the people you work with (Settings → Users). 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.

Grant permissions from a preset, then adjust. The presets are starting points for the roles most companies actually have. From there the grid is per area and per action - create, view, modify, delete - so “can raise an invoice but not delete one” is an ordinary setup rather than a compromise.

Bring your accountant in (Settings → Accountants). The page has three lists: firms that have access today, firms waiting for you to approve them, and invitations you’ve sent that haven’t been answered. Either side can speak first. You can invite a firm using the code they give you, or a firm that has your code can ask, and you approve or decline.

You decide what they can do, in both directions. The permission grid is on your side of the relationship, whether you’re approving a firm that asked or inviting one yourself. It opens on the accountant preset rather than an empty grid, and the page says so above it, so approving straight through grants a sensible set instead of nothing at all.

Working for clients is the other screen (Settings → My Practice). Your client companies, the invitations waiting for you to accept, and your own staff list. Assign the colleagues who should work on each client, and those are the only people who can open it. A client you take on appears in your company switcher.

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”.
  • There’s nothing to set up to become a firm. A firm is just a company, like any other. You become one the first time a client approves your access, and your staff are the people already in your own Users list.
  • Narrowing a firm’s access reaches the people already inside it. Changing the grid isn’t only a rule for the next person to walk in. Everyone from that firm who has already opened your company moves to the new permissions.
  • A firm names its own people; you name what they can do. You don’t know their staff, so you don’t pick them. What you get instead is the list of who can currently open your books, on the Accountants page.
  • The company you’re working in decides what you can see. One company’s records are kept away from another’s by the system itself, every time anything is read, rather than by somebody remembering to filter a list - 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.
  • 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.

Something here wrong or missing? Tell us - the guide is maintained alongside the product.