Approval and posting controls

Approval controls decide who must authorise a sensitive action. Posting controls decide whether and how a Finance event can resolve into accounting accounts. Together they prevent uncontrolled operational and accounting changes.

Audience: finance control administrators, school leaders, bursars, accountants, implementers, approvers, auditors, and security reviewers
Learning time: 50 minutes
Navigation: Finance → Finance Controls → Finance Setup → Approval Matrix, Approvals, and Posting Controls
Boundary: the backend selects approval routes and posting accounts. The browser must not reproduce the resolver.

Learning outcomes

You will be able to:

• configure amount/currency/date/scope-based approval matrices;
• explain ordered steps and decision modes;
• simulate approval routing before activation;
• configure posting policy, mappings, and rule overrides;
• use maker-checker change requests;
• dry-run and apply Finance controls safely;
• identify stale approval evidence and posting exceptions;
• prove the P2 exit gate for a test school.

Approval matrix model

An approval matrix can route by:

• resource and action;
• tenant or school scope;
• currency;
• minimum/maximum amount;
• effective dates;
• required roles, permissions, or users;
• ordered steps;
• decision mode: any, all, or threshold count;
• digital signature;
• delegation and escalation policy;
• segregation-of-duties flag.

School-specific active routes take precedence over tenant defaults.

Source fingerprint

For controlled operational actions, the server fingerprints material source evidence such as status, amount, currency, version, and update time. Approval is not a reusable blank cheque. If the source changes, stale pending requests can be cancelled and prior approval is not reused.

Verified controlled actions include:

Resource/action	Operational boundary
expenditure:approve	supplier expenditure approval
reconciliation_batch:close	reconciliation close
cashbook_period:close	period close
ledger_export:certify	export sign-off
payroll_run:approve	payroll approval

Other actions require verification before they are documented as using the same runtime.

Approval matrix status and scope

A copied tenant matrix becomes a school draft. It is ineffective until reviewed and activated. Verify:

• resource/action spelling;
• school scope;
• amount bands without gaps/overlaps;
• currency;
• effective dates;
• step order;
• eligible approvers;
• segregation;
• signature and escalation;
• active status.

Posting-control model

Posting policy

Policy fields can control:

• approval for mappings and overrides;
• segregation of duties;
• blocking when a mapping is missing;
• school account overrides;
• manual-journal posting;
• maximum unapproved manual amount;
• close requirements for zero exceptions, reconciliation, and GL/cashbook parity;
• default currency;
• effective status/dates.

Mappings and overrides

Mappings connect event attributes to account codes. Rule overrides can replace debit, credit, description, or mandatory behaviour for a posting type and therefore require especially visible impact review.

Prerequisites

Requirement	Why it matters
Approved process map	matrices must govern real responsibilities
Separate maker/checker identities	prevents self-control
Exact role/permission inventory	route eligibility must be testable
Amount/currency bands	thresholds determine routing
Active GL accounts	mappings need valid account codes
Event inventory	posting types and keys must be known
Fiscal dates	effective dates and open periods matter
Exception ownership	unresolved posting failures need accountable resolution
Change-management policy	direct save versus request/apply must be defined

Roles and exact permissions

Approval matrices and requests

Action	Ability
List/create/update matrices	financial_approval_matrix:list, create, update
Activate matrix	financial_approval_matrix:activate
Simulate route	financial_approval_matrix:simulate
Create/read/list requests	financial_approval_request:create, read, list
Approve/reject	financial_approval_request:approve, financial_approval_request:reject

Posting controls

Action	Ability
Read/list	finance_control:read, finance_control:list
Direct create/update/delete	finance_control:create, update, delete
Manage policy	finance_control:manage_policy
Request change	finance_control:request_change
Approve/reject change	finance_control:approve
Apply approved change	finance_control:apply_change
Simulate/readiness	finance_control:simulate, finance_control:readiness
List/resolve exceptions	finance_posting_exception:list, finance_posting_exception:resolve
Dry-run/apply full setup	financial_process_setup:apply

No user should request, approve, and apply the same sensitive change when segregation is enabled.

Guided procedure: approval matrix

1. Define the controlled action

Record exact resource, action, school scope, currency, amount bands, and effective dates.

2. Design steps

For each step, define:

• order and name;
• any/all/threshold mode;
• required count;
• eligible roles/permissions/users;
• amount range if step-specific;
• digital signature;
• due time;
• escalation roles.

3. Create as draft

Open Finance Setup → Approval Matrix and create the route.

4. Simulate

Run simulations for:

• below, at, and above each threshold;
• each currency;
• tenant versus school scope;
• effective-date boundaries;
• eligible and ineligible actor;
• creator/self-approval case;
• no-route case.

5. Independently review and activate

An authorised control owner reviews the matrix and activates it.

6. Test with a controlled source

Use a sandbox source record. Confirm the operational endpoint creates/polls a request rather than deciding automatically. Approve with an eligible separate user and verify the source fingerprint remains unchanged.

Guided procedure: posting controls

1. Open Posting Controls → Policy and configure approved flags.
2. create mappings for the verified event inventory;
3. create overrides only where baseline mapping cannot express the approved rule;
4. simulate representative and failure contexts;
5. use change requests where policy requires;
6. approve/reject independently;
7. apply approved changes with separate authority;
8. rerun readiness;
9. inspect/resolve exceptions;
10. dry-run full Finance control application;
11. explicitly apply only when all gates pass.

P2 exit-gate proof

An implementer can claim the test school foundation is ready only when:

1. process profile is school-owned or intentionally inherited;
2. required books exist;
3. fiscal year/periods are active/open;
4. currency design is complete;
5. Chart of Accounts and mappings simulate;
6. fees/concessions are approved and effective;
7. bank/provider and receipt settings are complete;
8. approval routes simulate across thresholds;
9. posting policy is active;
10. no critical posting exception remains;
11. dry run passes;
12. explicit apply succeeds;
13. independent reviewer reproduces the result.

Worked scenario: Mupfure Learning Academy

The school configures expenditure approval:

• USD 0–999: one bursar reviewer;
• USD 1,000 and above: bursar then school head;
• school-specific route;
• segregation enabled;
• signed decisions;
• 24/48-hour due targets.

The implementer simulates USD 999, 1,000, and a different currency. The maker cannot approve their own request. A school-head approval is invalidated when the expenditure amount changes. Posting mappings are submitted separately and applied only after approval.

Failure modes

Symptom	Likely cause	Evidence to inspect	Safe action	Escalate when
Simulation selects wrong matrix	overlapping bands, scope precedence, currency/date	all active matrices and simulation	correct design; re-simulate	backend selection contradicts contract
No eligible approver	role/permission/user criteria too narrow	step criteria and IAM state	amend route through governance	business cannot maintain segregation
Approved request becomes stale	source amount/status/version changed	fingerprint and request history	create new request	stale evidence is reused
User can self-approve	segregation disabled/misconfigured	matrix and actor evidence	enable/correct and retest	backend allows prohibited self-approval
Mapping change cannot apply	account inactive, effective date, request stale	change request and simulation	correct/reapprove	valid approved change remains blocked
Readiness shows critical exception	real posting failure or unresolved configuration	exception details and source event	fix cause, then resolve	exception lacks actionable evidence
Dry run passes but transaction fails	provider/data/period/operational dependency outside setup	transaction evidence	investigate specific workflow	repeatable setup contradiction

Verification checklist

• Every matrix uses exact resource/action.
• Amount bands and currencies are complete and non-overlapping.
• School/tenant scope is intentional.
• Steps and eligible actors are tested.
• Segregation and signature rules are enforced.
• Source changes invalidate stale approvals.
• Posting policy is approved and effective.
• Mappings use active non-header accounts.
• Rule overrides have explicit reason and impact preview.
• Change-request maker/checker/applier identities differ where required.
• Simulations cover success and safe failure.
• Critical exceptions are cleared.
• Full dry run and explicit apply evidence exist.
• Independent reviewer can reproduce P2 readiness.

Practice and knowledge check

Guided practice: build and simulate a two-band expenditure matrix plus one controlled posting mapping in a test school.

Independent scenario: an approved mapping change references an account deactivated after approval. Explain why application must revalidate and what evidence should remain.

1. Why must the backend choose the approval route?
2. What is a source fingerprint?
3. Why is a copied matrix ineffective by default?
4. What is the difference between approval and application?
5. Why are rule overrides higher risk than ordinary mappings?
6. What is the purpose of posting simulation?
7. What proves the P2 exit gate?

Answer guide: central resolver is authoritative; fingerprint binds approval to exact source state; copies are draft; approval authorises while application changes effective configuration; overrides replace baseline logic; simulation proves backend resolution/failure; complete readiness, dry run, explicit apply, and independent reproduction prove P2.

Next lesson

Return to Finance or continue to the P3 billing curriculum when published.