Posting review and approval
Posting review determines whether the proposed accounting treatment is complete, authorised, correctly scoped, and safe to apply. Approval authorises a governed change or transaction; it does not replace technical validation, balancing, period eligibility, or source evidence.
Audience: finance-control makers, approvers, accountants, school heads, auditors, and implementers
Learning time: 50 minutes
Navigation: Finance → Accounting → Posting Controls → Policy, Mappings, Rule Overrides, Changes, Simulate, Exceptions
Control boundary: direct create/update permissions and maker-checker permissions are separate paths. Use the path defined by effective policy.
Learning outcomes
You will be able to:
- explain tenant defaults, school overrides, policy, mappings, rule overrides, and exceptions;
- choose between direct mutation and a change request;
- run backend simulation before changing posting resolution;
- apply maker-checker segregation to control changes and manual journals;
- verify approval, rejection, application, and effective-date evidence;
- prevent self-approval and stale-fingerprint application;
- resolve posting exceptions without suppressing unresolved accounting defects.
Control objects
A policy defines high-level behaviour such as approval requirements, segregation, blocking on missing mappings, school account overrides, manual-journal allowance, amount thresholds, and close prerequisites.
An account mapping resolves a posting type and mapping key to account codes and sides. A rule override narrows resolution for a school or entity scope. A change request packages a proposed mutation for approval. Simulation asks the backend resolver what would post under current effective controls. A posting exception records a blocked or failed accounting event requiring investigation.
Prerequisites
| Requirement | Why it matters |
|---|---|
| Explicit tenant/school scope | avoids editing the wrong inheritance layer |
| Active GL accounts | mappings must use valid posting accounts |
| Effective policy | determines approval and direct-management route |
| Posting type and mapping key | change must solve a specific resolution need |
| Before-state evidence | reviewer must know what will change |
| Simulation case | demonstrates the proposed accounting effect |
| Maker and approver identities | supports segregation |
| Effective dates | prevent uncontrolled retroactive behaviour |
| Rollback/correction plan | rejected or harmful changes must be recoverable |
Roles and exact permissions
| Action | Exact ability |
|---|---|
| View policies | finance_control:read |
| List mappings and rule overrides | finance_control:list |
| Create directly | finance_control:create |
| Update directly | finance_control:update |
| Retire directly | finance_control:delete |
| Manage policy | finance_control:manage_policy |
| Submit change request | finance_control:request_change |
| Approve or reject request | finance_control:approve |
| Apply approved request | finance_control:apply_change |
| Simulate resolution | finance_control:simulate |
| View readiness | finance_control:readiness |
| List exceptions | finance_posting_exception:list |
| Resolve or ignore exception | finance_posting_exception:resolve |
| Create manual journal | gl_journal_entry:create |
| Reverse journal | gl_journal_entry:reverse |
A user with direct create/update permission can technically bypass maker-checker if policy and product configuration permit it. Organisations requiring segregation should remove direct mutation from makers and use request/approve/apply abilities.
Change-request lifecycle
The exact stored labels can vary by control object. Preserve the current API response rather than normalising every state to one generic workflow. A request should identify the target resource, operation, before-state, proposed after-state, reason, scope, effective date, and request fingerprint.
Guided control-change procedure
- Select the school and confirm whether the current row is a tenant default or school-owned override.