Setting roles and permissions in the firm
How a firm decides what each role may do in Achekam, finds out why a person can or cannot act, and keeps payroll changes with the right people.
By Achekam · · 5 min read · For Accountants & audit firms in South Africa, Nigeria, Kenya
A first-year trainee who can delete a client's engagement letter is not a training problem. It is a permissions problem, and it usually starts in the first busy week on a new system, when everyone is made an administrator "for now" and nobody goes back.
The opposite failure costs just as much: a manager who cannot approve timesheets on the Friday they are due, so a partner gets phoned at home to press one button. Both come from roles that were never designed, only accumulated.
This article sets out a way to decide what each role in your firm may do, how Achekam lets you allow or deny each action, and how to find out quickly why a particular person can or cannot act before you start widening anyone's access.
Least access, decided per role
Begin with the work, not the software. List the roles your firm actually has, then write down the few things each one must be able to do to get through a normal week. Everything else stays off until someone can say why it is needed.
A simple starting point many firms adapt:
| Role | Needs to | Should not be able to |
|---|---|---|
| Trainee or clerk | Prepare work, record time, upload client documents | Approve their own time, change permissions |
| Senior or supervisor | Review a junior's papers and raise review notes | Sign statements, change payroll |
| Manager | Approve timesheets, carry out manager review | Give partner sign-off |
| Partner | Partner review, signing, approving write-offs | Prepare and approve the same item |
| Firm administrator | Invite, suspend and remove people, set permissions | Do client work under an administrator login |
The table is a design aid, not Achekam's defaults. Its value is that it forces the question of who should do each thing before a person asks for it.
Roles are handed out at the door. A firm administrator invites colleagues by an e-mailed link and gives each one a role at that moment, and can later suspend, reactivate or remove them under TEAM > People. The subscription's seat limit is checked on every addition. Decide the new person's role before the invitation goes, not after they have spent a week with too much access.
Allow and deny, one action at a time
Under SETTINGS > Permissions & RBAC a firm can allow or deny what each role may do. Treat every change there as a decision you could defend to a reviewer: which role, which action, allowed or denied, and the reason. Keep that short list in your quality manual so the design survives a change of administrator.
Some separations sit underneath any setting you choose, and no permission can loosen them:
- Only a user with a partner role can sign a set of financial statements, and the person recorded as its preparer or reviewer cannot issue it.
- On a working paper, the preparer cannot also review it, and Achekam refuses any sign-off made by an AI.
- Opening a review from the Supervision, Manager or Partner desk does not by itself give sign-off authority.
Knowing these fixed rules saves time. If a manager cannot sign statements, that is the design working, not a permission to add.
The idea behind all of it is old and simple. AccountingTools gives a short definition of segregation of duties: the steps in a process are given to different people so that no one person can both commit an error or theft and hide it.
Finding out why someone can or cannot act
When a colleague says "it won't let me", the tempting fix is to give their whole role more power. Achekam lets an administrator check why a member may or may not perform an action, so look before you change anything.
A short routine:
- Confirm the person's status under TEAM > People. A suspended member cannot act, whatever their role.
- Run the permission check for that person and that action to see whether their role allows or denies it.
- Check whether the client or engagement is restricted. Partners and administrators can limit a client, or one engagement, to named people with a reason, and someone outside that list will be stopped even if their role would allow the action.
- Only then decide: change the role for everyone in it, grant the right to one person, or leave things as they are.
Restrictions behave differently from permissions. A restriction is lifted rather than deleted, and who did what and when is recorded. The client's account manager and the engagement's partner and manager can always open a restricted client, so a restriction never locks out the people responsible for the work. Restricting a client to named people covers when to use one.
Named time and collaboration permissions
Some permissions for time and collaboration are named ones that can be granted per role or per person. The per-person route is the right home for exceptions: a senior who runs a small team, or an office manager who needs one specific right without becoming an administrator.
Keep exceptions visible. A firm where half the staff hold personal grants has, in practice, stopped having roles. Review personal grants whenever someone is promoted or moves teams, and remove the ones that belonged to the old job.
Firms with a Nigeria or Kenya pack meet one permission that is deliberately personal. The permission to record a filing with the NRS or KRA is given to no role by default, not even Partner; a firm grants it to named people only. Before a filing deadline, confirm that the grant can actually be made in your workspace, because the research behind these articles found no screen that grants it, which may leave recording a filing unreachable.
Who may change payroll
South African payroll has the tightest rules in the system. Only the Partner, Admin, Payroll, PayrollAdmin and FinanceManager roles can change payroll. The person who prepared a pay run cannot approve it, nobody can approve a run that pays themselves, and a change to an employee's bank account must be verified by a second person. Unverified bank accounts are listed at approval and left off the bank file.
Three practical consequences follow:
- You need at least two people in payroll roles, or nothing gets approved.
- Approving the firm's own staff run needs someone who is not paid in that run, so settle in advance who that is.
- Putting every partner into a payroll role weakens the control rather than strengthening it. Choose the few who need it.
If your firm runs payroll for clients as well as for itself, setting up payroll clients as employers explains how each employer is kept separate.
A yearly look at who can do what
Once a year, and whenever a person changes job, compare your written role design with what Settings shows, check the personal grants and remove what nobody can justify. Start with the people who can change payroll and the people who can manage permissions, because those two lists protect everything else.
General guidance only, not advice on your own circumstances. Tax and payroll rules change: check the current position with the authority or your adviser.
