Roles, users & security

Who can see what, who approved what, and how to prove it later.

The roles that ship

Eight on every plan, and three more that appear where the plan carries the modules they are for. All of them are a starting point — every one can be copied and changed.

Role	Intended for
Owner	The person who owns the business. Full access, including billing and deleting the account.
Admin	Day-to-day administration including user management.
Accountant	Full financial access — posting, reporting, reconciliation — without user administration.
Sales	Quotes, invoices, customers and the full sales CRM. No access to payroll or the ledger.
Viewer	Read-only across what they are given.
Payroll Manager	Employees, runs, payslips and leave. No access to sales or banking.
Tax Practitioner	Full SARS access, view and export on financials, can create reports.
External Auditor	Read and export, with no ability to change anything.
Buyer	Requisitions, purchase orders, suppliers and the three-way match. Manufacturing plans.
Production Planner	Bills of materials, material planning and production. Sees despatch, does not dispatch.
Fleet Controller	Trips, vehicles, drivers and proof of delivery. Manufacturing plans.

The last three are not added to businesses that already exist.

A new system role appearing in an established account is a permission change nobody asked for. If you upgraded into a plan that has them and want them, create them from the role builder — the definitions are there, they are simply not applied behind your back.

The permission matrix

Each role holds up to six permissions on each of the modules:

view — open the module and read its data
create — add new records
edit — change existing records
delete — remove or void records
approve — sign off items in a queue, such as expense claims or a payroll run
export — take the data out as PDF, Excel or CSV

The matrix view shows modules down the side and roles across the top, so you can see the whole policy at once. If none of the eight fit, build a custom role and tick the permissions yourself.

Approve is separate from edit on purpose.

Someone who can capture an expense should not automatically be able to approve it. Keeping the two apart is the cheapest internal control you have.

Inviting a user

Roles & Users → Invite user
Email address and role
They receive an invitation and set their own password. You never handle it.
Entity access
On multi-company accounts, choose which entities they can reach. Access is per entity, not all-or-nothing.
Check the seat count
Seats are limited by plan — 1 on Free, 3 on Starter, 10 on Business, 25 on Professional, and unlimited on Enterprise and Manufacturing. An invitation over the limit is blocked with an upgrade prompt.

Customers, employees, suppliers and drivers do not take a seat — they get a portal link instead of an account.

Sessions and policies

Sessions — every active session per user, with a revoke button for the laptop that walked
Policies — session timeout, password rules, lockout after failed attempts, and the seven-year POPIA retention setting

Revoking a session or changing a user's role takes effect on their next request, not at their next login.

Two-factor authentication

Adoption is shown as a ring, so you can see at a glance who has not switched it on. Ledgr supports any authenticator app — the six-digit code kind.

Recovery codes

Enrolling produces ten single-use recovery codes, displayed once. Ledgr keeps only a fingerprint of each, so there is no screen, no export and no support request that can ever show them to you again. Save them somewhere that is not the phone holding the authenticator.

A recovery code is entered in the same box as the six-digit code at sign-in — Ledgr tells them apart by their shape, so there is no second screen to find while you are locked out.

If somebody loses their phone

An owner or administrator can reset another person's two-factor from their user record. It needs the roles edit permission and an owner or admin role, and:

You cannot reset your own — that would make two-factor optional for whoever holds the permission.
If you have two-factor on yourself, you are asked for your own code first.
The affected person's sessions are revoked and they are emailed about it. Ledgr reports whether that email actually went, rather than assuming it did.
It is written to the audit log as a warning, because it is a security event and should be visible as one.

Why this exists.

Two-factor used to be a one-way door: every route asked for the user's own current code, login refused without one, and a password reset did not clear it. A lost phone locked somebody out of the business, not just out of a device, and only somebody with database access could undo it. Both ways back in — the codes and the reset — close that.

API keys

Roles & Users → API keys → Generate
Scope it
Grant only the permissions the integration needs — for example transactions:write for a billing feed.
Bind it to a contact if the integration bills
Required for the monthly billing ingestion endpoint, so the aggregate lands on the right customer.
Copy the key now
The plaintext is shown once and never again. Store it in your secret manager, not in a chat message. If it is lost, revoke it and generate another.

How to use a key is covered in the developer docs.

The audit log

Events are recorded with a severity — info, warning or error — and can be filtered by it. The log holds who did what and when, and is retained for seven years to satisfy POPIA. It is the first place to look when a figure changed and nobody remembers changing it.

POPIA also gives your data subjects rights you have to be able to action: access, correction and deletion. Contact records and their communication history are exportable and deletable from the contact itself.