Roles, permissions, approvals and segregation
Makronexus access is permission-based. A role such as school_bursar, bursar, finance_clerk or finance_officer is an assignment label; the effective resource:action abilities determine what the user can see or do.
Audience: Finance users, administrators, reviewers, implementers and auditors
Learning time: 40 minutes
Learning outcomes
You will be able to:
- distinguish roles from effective permissions;
- name exact permissions for common Finance actions;
- explain maker-checker and independent certification;
- design a minimum-access responsibility split;
- diagnose a denied or missing workspace safely.
Access model
The backend is authoritative. The browser does not decide whether a permission combination is toxic.
Roles are not permissions
Current role labels include:
school_bursarandbursar;finance_clerk;finance_officer;- school/tenant administrators;
- principals and school heads;
- other staff, parent and student roles.
Do not write “only administrators can…” unless an exact product rule proves that statement.
Use:
The action requires
financial_payment:refund.
Not:
Ask an administrator.
Permission syntax
Current product code accepts ability forms such as:
resource:action;resource.action;- wildcard forms such as
resource:*or*.
Finance documentation uses the canonical resource:action form.
Action aliases can support read/list/view and edit/update behaviour in parts of the frontend. The endpoint’s named permission remains the authoritative requirement.
Domain-entry permissions
A user can enter the Finance domain when they hold at least one relevant Finance ability. Current domain access checks include:
financial_fee:view;financial_invoice:view;financial_payment:view;financial_receipt:view;financial_receipt_template:list;student_payment_profile:list;student_financial_summary:view;fee_discount_program:list;fee_discount:read;school_bank_setting:view;- scholarship view abilities;
- process setup, accounting-book and approval-matrix read/list/readiness abilities;
- approval-request read/list abilities.
Entry into the domain does not grant every Finance page or action.
Core billing permissions
| Action | Exact permission |
|---|---|
| Create school fee | financial_fee:create |
| List school fees | financial_fee:list |
| Update school fee | financial_fee:update |
| Archive school fee | financial_fee:delete |
| Create payment plan | financial_payment_plan:create |
| List payment plans | financial_payment_plan:list |
| Update payment plan | financial_payment_plan:update |
| Archive payment plan | financial_payment_plan:delete |
| Create invoice | financial_invoice:create |
| List invoice | financial_invoice:list |
| Read invoice | financial_invoice:read |
| Update invoice | financial_invoice:update |
| Archive invoice | financial_invoice:delete |
| Send invoice | financial_invoice:send |
| Approve invoice | financial_invoice:approve |
| Reject invoice | financial_invoice:reject |
| Create credit note | financial_credit_note:create |
| Read/list credit notes | financial_credit_note:read / list |
| Update/archive credit note | financial_credit_note:update / delete |
| Approve/reject credit note | financial_credit_note:approve / reject |
| Apply credit note | financial_credit_note:apply |
Invoice cancellation currently uses the invoice update permission in the API route catalogue.
Payment permissions
| Action | Exact permission |
|---|---|
| Capture payment | financial_payment:create |
| List payment | financial_payment:list |
| Read payment | financial_payment:read |
| Update payment | financial_payment:update |
| Verify payment | financial_payment:verify |
| Allocate payment | financial_payment:allocate |
| Reconcile payment | financial_payment:reconcile |
| View statistics | financial_payment:statistics |
| Search payment | financial_payment:search |
| Refund payment | financial_payment:refund |
| Delete eligible payment | financial_payment:delete |
A navigation page may use financial_payment:view; the backend mutation uses the exact action above.
Receipt permissions
| Action | Exact permission |
|---|---|
| Issue receipt | financial_receipt:create |
| List/read receipt | financial_receipt:list / read |
| View receipt statistics | financial_receipt:statistics |
| Create duplicate | financial_receipt:duplicate |
| Resend receipt | financial_receipt:resend |
| Cancel receipt | financial_receipt:cancel |
| Read/update receipt settings | financial_receipt_settings:read / update |
| Maintain receipt templates | the applicable financial_receipt_template:* action |
Read access to receipts does not grant cancellation or reissue authority.
General Ledger permissions
| Action | Exact permission |
|---|---|
| Create GL account | gl_account:create |
| List/read GL account | gl_account:list / read |
| Update GL account | gl_account:update |
| Soft-delete eligible GL account | gl_account:delete |
| Create journal | gl_journal_entry:create |
| List/read journal | gl_journal_entry:list / read |
| Reverse journal | gl_journal_entry:reverse |
| Read GL statements | gl:statements |
Setup and control permissions
| Area | Current abilities |
|---|---|
| Process setup | financial_process_setup:read, list, readiness |
| Accounting books | financial_accounting_book:read, list and mutation abilities where configured |
| Approval matrix | financial_approval_matrix:read, list, simulate and configured mutations |
| Approval requests | financial_approval_request:read, list and decision permissions in the approval workflow |
| Posting controls | finance_control:read, list, request_change, approve, readiness, manage_policy |
| Posting exceptions | finance_posting_exception:list and applicable resolution action |
| FX control | financial_fx:manage |
| Finance access certification | finance_access_control:read, scan, certify |
The exact toxic permission rules are loaded from the backend. Documentation must not reproduce or guess the catalogue.
Approval is an action, not a role
An approver must have:
- the exact decision permission;
- the correct tenant and school scope;
- an eligible request/object state;
- independence required by the workflow;
- supporting evidence and, where required, a comment or reason.
An approver should not approve merely because the button is visible.
Maker-checker pattern
The same person can perform multiple duties only when policy, effective access and transaction-specific controls permit it. The safer default for sensitive work is separation.
Segregation model
| Duty | Creates or changes | Should be independently checked by |
|---|---|---|
| Fee maker | pricing configuration | fee approver/Finance manager |
| Billing operator | billing run or invoice | billing reviewer/approver |
| Cashier | payment and receipt | verifier and cash-up reviewer |
| Allocator | invoice allocations | collections reviewer for exceptions |
| Refund requester | refund request/evidence | authorised refund approver |
| Journal maker | draft/manual journal | journal reviewer/poster |
| Poster | accounting effect | close/reconciliation reviewer |
| Reconciler | matches external/internal evidence | close or assurance reviewer |
| Access administrator | roles and grants | access-control scanner/certifier |
| Scan creator | access scan | independent certifier |
Access-control certification boundaries
The current Finance access-control workspace enforces:
- the browser does not calculate toxic pairs;
- a scan with violations cannot be certified;
- a stale clean scan cannot be certified;
- missing current-user identity fails closed;
- the scan creator cannot certify their own run;
- the backend rechecks certification boundaries;
- IAM mutations invalidate the exact certification state;
- role, grant, scan and certification mutations require a live server result.
This control addresses standing access. Transaction-specific maker-checker can add further restrictions.
Minimum-access examples
Cashier
Likely needs only the exact assigned collection abilities, for example:
- payment create/read as required;
- receipt create/read as required;
- student summary view;
- no refund, reconciliation, GL reversal, approval-matrix or access-certification ability unless explicitly assigned.
Bursar
May need broader billing and collection review abilities, but approval and refund powers should still be considered separately.
Accountant
May need GL account/journal/statement and reconciliation abilities without payment capture or receipt cancellation.
Administrator
May maintain users, roles and setup access without being the transaction approver or certifier.
These are design patterns, not product default role mappings.
Permission request template
Request:
| Field | Example |
|---|---|
| User | Tariro Moyo |
| School scope | Mupfure Learning Academy |
| Business responsibility | verify captured payments |
| Exact ability | financial_payment:verify |
| Duration | permanent or time-bound |
| Data scope | school-wide |
| Approver | Finance manager |
| Separation conflict checked | payment creator must not self-verify |
| Review date | 30 September 2026 |
Avoid requests for *, finance:* or “full access” unless a documented emergency procedure and approval justify them.
Diagnosing denied access
Control anti-patterns
| Anti-pattern | Risk | Better control |
|---|---|---|
| Give administrator to solve one missing page | excessive standing access | grant exact ability |
| Creator approves own request | error or fraud remains unchecked | independent checker |
| Cashier also reconciles all own collections | false matches or concealed shortage | independent reconciliation |
| Access admin certifies own scan | self-review | independent certifier |
| Share one Finance login | no actor traceability | individual accounts |
| Use wildcard permanently | uncontrolled future access | scoped abilities and review |
| Remove evidence to “clean up” | audit destruction | append-only correction |
Mupfure scenario
A finance clerk records a USD 300 payment. The school’s design separates:
- clerk:
financial_payment:create; - bursar:
financial_payment:verify; - accountant:
financial_payment:reconcile; - receipt officer or clerk:
financial_receipt:create; - reviewer: read-only audit evidence;
- administrator: role/grant maintenance;
- independent security reviewer:
finance_access_control:certify.
The exact assignment can differ, but each ability and conflict must be deliberate.
Verification checklist
- User identity is individual.
- Tenant and school scope are correct.
- Exact
resource:actionability is named. - Role label is not used as proof.
- Object state permits the action.
- Required approver is independent.
- Creator cannot certify the same exact state.
- Wildcard access is avoided.
- Time-bound or exceptional access has an expiry/review.
- Denied-state evidence is captured before escalation.
Knowledge check
- Does
school_bursarprove invoice approval access? - Which permission captures a payment?
- Which permission reverses a GL journal?
- Can a clean access scan be certified by its creator?
- Why can a user see Payments but fail to refund?
Answer guide
- No; inspect effective permissions.
financial_payment:create.gl_journal_entry:reverse.- No.
- Read/view and refund are separate abilities.