What are users, roles, and permissions?
Published
Users, roles, and permissions is the structure defining who can do what inside your system: each person a distinct account, each account a role, each role a defined set of permissions. The governing principle - role-based permissions - grants the permission to the role, not the person, so when the person changes or leaves, the role remains and stays defined.
Rule one: one account per person
A shared login ("accounting," used by three) kills the audit trail before anything else: "who did it?" has no answer. And when one leaves, the password gets changed and the rest still know it - meaning the departed still has access. One account per person is what makes the audit trail page actually work.
Ready roles for a small business
| Role | Can | Cannot |
|---|---|---|
| Data entry | Create draft invoices and expenses | Approve, pay, edit closed periods |
| Accountant | Issue invoices, post entries, reconcile, close periods | Change roles, delete records |
| Payment approver | Approve payment vouchers above a set threshold | Edit the original invoice |
| Finance manager | Everything above + advanced reports + assigning roles | - |
| Owner | Highest permission, with a clear log of every action | - |
| View-only | See reports | Any edit |
These are starting suggestions to adapt - the governing principle is the minimum necessary: grant what the work requires, no more.
Critical segregation of duties
Some tasks are never combined in one hand:
Who records sales invoices ≠ Who receives cashWho records supplier bills ≠ Who approves paymentWho posts manual entries ≠ Who reconciles the bank
In a five-person business, complete separation may not be possible - it is compensated by periodic review by a third party (owner, external accountant) and a lower approval threshold.
Frequently asked questions
The freelance accountant who visits weekly - what role?
Their own personal account under the "accountant" role, with their activity clearly logged - never share an employee's login. When the engagement ends, the account is deactivated, not the password.
How high should the approval threshold be?
A practical measure: an amount covering daily operating payments without friction, halting anything above it for higher approval - built on your actual spending, not a borrowed figure.
We have disputes over "who did this"?
That's a signal of a shared account or a weak log - the fix is structural, not behavioural. Start with individual accounts and enable the activity log, and most disputes vanish on their own.