Role based access control for finance teams: a practical setup

Role based access control (RBAC) means giving people permissions through roles, such as "billing clerk" or "finance manager", rather than configuring each user individually. For finance teams it's the practical way to make sure staff can do their jobs without any single login being able to create a customer, change their bank details, issue a refund and hide the evidence. Good RBAC combines least privilege, segregation of duties and regular access reviews.

This guide shows how to design roles for a typical South African finance or billing team, with a sample role matrix you can adapt.

Why finance systems need role based access control

Billing and payment platforms concentrate sensitive capabilities: refunds, credit notes, write-offs, changes to payout bank accounts, API keys and customer data exports. When everyone logs in as an administrator (or shares one login), three problems follow:

• Fraud risk. One person can both initiate and approve a payment-affecting change.
• Error risk. A junior staff member can accidentally void invoices or change gateway settings.
• No accountability. Shared logins make audit logs meaningless.

RBAC also supports your security obligations. POPIA section 19 expects appropriate technical and organisational measures to protect personal information, and limiting who can see and export customer data is one of the most visible of those measures. See our guide on POPIA and payment data.

The three principles

Least privilege

Each person gets the minimum access they need. A debtors clerk who chases overdue invoices needs to see invoices and send reminders, not change gateway credentials.

Segregation of duties

Split sensitive processes so that at least two people are involved. Classic pairs in billing:

• one person captures a refund or credit note; another approves it;
• one person updates a customer's bank details; another verifies the change with the customer through a known contact method;
• one person prepares a debit order batch; another approves submission.

Accountability

Every user has their own login, protected by two-factor authentication, and important actions are recorded in an audit log. Without individual logins, segregation of duties exists on paper only.

Designing roles: start from tasks, not job titles

List the recurring tasks in your finance operation, then group them into roles. A useful exercise is a simple task inventory:

1. Create and edit customers
2. Raise invoices and quotes
3. Record manual EFT and cash payments
4. Issue credit notes and refunds
5. Manage subscriptions and plans
6. Prepare and approve debit order batches
7. Reconcile bank statements
8. Run and export reports
9. Manage gateways, API keys and webhooks
10. Manage users and roles

A sample role matrix

This is an illustrative starting point for a small to mid-sized team; adjust it to your size and risk appetite.

Two points to note. First, keep the number of admins small; two is often enough, so there's cover for leave without spreading full access. Second, your admins shouldn't routinely do day-to-day billing under their admin accounts.

Small team? Compensate with controls

In a business with two or three people in finance, perfect segregation isn't always possible. Compensating controls help:

• the owner reviews a weekly report of refunds, credit notes and write-offs;
• any change to payout bank details triggers a notification to a second person;
• reconciliation exceptions are reviewed by someone other than the person who captured the payments;
• audit logs are checked monthly for unusual activity, such as exports at odd hours.

Joiners, movers and leavers

Most access problems come from change, not from the original design.

• Joiners. Assign a role, not individual permissions. Require 2FA before first use; see authenticator app 2FA.
• Movers. When someone changes job, remove the old role before adding the new one, so access doesn't accumulate.
• Leavers. Disable the account on their last day, rotate any API keys or shared credentials they had access to, and transfer ownership of scheduled reports.

Review access regularly

Schedule a quarterly access review:

1. Export the list of users and their roles.
2. Ask each manager to confirm their team members still need that access.
3. Remove unused accounts and downgrade unnecessary admin rights.
4. Check the audit log for sensitive actions during the quarter.
5. Record the review. It's useful evidence for auditors and for POPIA accountability.

Warning signs your access model needs work

• Several people share one login.
• More than a handful of users are admins.
• Former staff or agencies still have active accounts.
• Nobody can say who approved last month's refunds.
• Bank detail changes aren't logged or independently verified.

How CentraPoint helps

CentraPoint includes roles and permissions with built-in admin, staff and viewer roles, plus custom roles you define to match your own matrix. Each team member has their own login with authenticator-app (TOTP) 2FA and backup codes, audit logs record account activity, and debit order mandates and batches go through an approval step. Reports can be scheduled to email the right people automatically. The features page lists the full set.

Frequently asked questions

What is role based access control?

It's a way of managing permissions by assigning users to roles, each with a defined set of allowed actions, instead of setting permissions person by person.

What is segregation of duties in finance?

It means splitting sensitive tasks so no single person controls a whole process, for example one person captures a refund and another approves it.

How many admin users should a finance system have?

As few as practical, often two so there's cover during leave. Day-to-day work should be done under normal roles, not admin accounts.

How often should we review user access?

Quarterly is a common, manageable rhythm, plus an immediate review whenever someone joins, changes role or leaves.