Readiness and dependency order
Finance readiness is the evidence that a selected school has enough configuration, access, accounting structure, and operational capacity to perform a specific Finance activity safely. It is not a single switch and it is not proved by visiting every setup page.
Audience: implementers, school administrators, bursars, accountants, control owners, and support analysts
Learning time: 35 minutes
Availability: verified for the current Finance Setup and Controls workspaces
Configuration boundary: readiness is evaluated by the backend for the active tenant and school. Do not infer readiness from navigation visibility.
Learning outcomes
You will be able to:
- explain why Finance setup must follow a dependency order;
- distinguish tenant defaults from school-owned copies;
- identify the readiness areas and their common blockers;
- perform a safe dry run before applying controls;
- prove that a test school is ready without relying on a success toast;
- diagnose whether a failure belongs to setup, access, data, period, provider, mapping, or control coverage.
What readiness is—and is not
Readiness answers a narrow question: can this school perform this Finance responsibility with the required dependencies and controls?
It is not:
- evidence that every future transaction will succeed;
- proof that a payment provider is operational in every country;
- proof that the school’s Chart of Accounts is professionally designed;
- statutory or tax certification;
- permission to bypass approval or segregation rules;
- a substitute for transaction testing.
Makronexus evaluates separate readiness areas for:
| Area | Operational purpose | Typical blockers |
|---|---|---|
| Billing | Create fees and raise invoices | current academic year/term, billable students, approved active fees, open accounting period, posting mappings |
| Collections | Record payments and issue receipts | cash book, default published receipt template, open period, posting mappings |
| Accounting | Maintain ledger and controlled entries | process controls, required books, Chart of Accounts, posting policy, mappings, role capacity, critical exceptions |
| Expenditures | Approve purchases and settle suppliers | approval routes, settlement account, mappings, open period |
| Reconciliation | Match external bank activity | active bank account, bank settings, open period |
| Gateways | Accept online or mobile payments | active provider, settlement bank account, mappings |
| Reporting | Produce reliable financial statements | accounting controls, Chart of Accounts, opening-balance decision |
Dependency order
Use this sequence for a school that begins with no Finance configuration:
The order is intentionally conservative. A school can create some records earlier, but it should not treat Finance as operational until downstream dependencies have been checked.
Tenant defaults and school copies
Finance setup can contain tenant-level defaults and school-specific records.
| Scope | Meaning | Edit rule |
|---|---|---|
| Tenant Default | shared baseline with no school ID | treat as inherited reference unless authorised to manage tenant controls |
| School Override / School Copy | record owned by the selected school | editable according to exact permissions |
| Operational school record | transaction or configuration tied to one school | must match the active school context |
The current setup experience can copy a process profile, accounting books, and approval matrices from tenant defaults. Copies are independent records and preserve source provenance. Approval-matrix copies are created as draft and must be reviewed and activated before use.
Do not edit a tenant default when the implementation decision is to customise one school. Do not assume that a copied record is effective merely because it exists.
Prerequisites
| Requirement | Evidence | Safe response when missing |
|---|---|---|
| Active tenant | tenant indicator matches implementation workbook | stop and select the correct tenant |
| Active school | school indicator shows the intended school | stop; school-scoped configuration must not use an inferred school |
| Named configuration owner | implementation or governance record | assign ownership before mutation |
| Exact permissions | current user permission list | request authorised access; do not use a broader role assumption |
| Academic calendar | current academic year and term where billing needs them | configure in School Setup |
| Source decisions | currencies, fiscal dates, fee policy, bank details, approvers | obtain approved design decisions |
| Test identities | maker, reviewer, approver, read-only reviewer | provision separate users for control testing |
| Non-production test scope | sandbox/test school identified | do not learn configuration in live Finance |
Roles and exact permissions
| Action | Typical responsibility | Exact ability |
|---|---|---|
| View process setup | implementer, bursar, reviewer | financial_process_setup:read |
| Update process setup | authorised setup owner | financial_process_setup:update |
| View readiness | setup owner, control reviewer | financial_process_setup:readiness |
| Dry-run/apply controls | authorised control owner | financial_process_setup:apply |
| List/create/update books | accountant or setup owner | financial_accounting_book:list, financial_accounting_book:create, financial_accounting_book:update |
| List/create/update matrices | control administrator | financial_approval_matrix:list, financial_approval_matrix:create, financial_approval_matrix:update |
| Activate matrices | independent control owner | financial_approval_matrix:activate |
| Simulate approval routing | implementer or reviewer | financial_approval_matrix:simulate |
| View posting readiness | accounting/control reviewer | finance_control:readiness |
| Simulate posting | implementer or accountant | finance_control:simulate |
Role labels such as bursar or finance officer are not evidence of these abilities. The backend is authoritative.
Guided procedure
1. Select the implementation scope
Open the school application and confirm the tenant and school indicators. Record the IDs or visible names in the configuration workbook.
Expected result: every subsequent school-scoped request uses the intended school.
Control: do not continue if the page silently falls back to tenant scope.
2. Open Finance Setup
Navigate to Finance → Finance Controls → Finance Setup (finance/setup). Review available tenant defaults and school copies.
Expected result: the page distinguishes inherited defaults from school-owned records.
Control: read-only tenant defaults must not be treated as school configuration.
3. Create the school control foundation
Create or copy the financial process profile, required books, and approval matrices according to the approved design. Review every copied field rather than accepting defaults blindly.
Expected result: school-owned records exist with school scope and provenance.
Control: copied approval matrices remain draft.
4. Complete configuration chapters
Follow the remaining P2 lessons in order. Capture identifiers, status, owner, effective dates, currency, and evidence for each record.
5. Review readiness
Open Finance → Finance Controls → Controls Readiness (finance/controls/readiness).
For each failed requirement, record:
- readiness area;
- requirement code or visible title;
- current evidence;
- responsible owner;
- corrective route;
- completion date.
6. Simulate before applying
Use approval-route simulation and posting simulation for representative combinations of:
- resource and action;
- school;
- currency;
- amount threshold;
- effective date;
- fee type or payment method where relevant.
The frontend must display the backend simulation result. Do not calculate the “expected” route or accounts locally and treat that as proof.
7. Dry-run application
Run the control-application action in dry-run mode first.
8. Apply controls explicitly
Only after the dry run passes, perform the explicit apply action with the required ability. Record the application result and actor.
9. Prove operational readiness
Use controlled test cases rather than production data:
- create or identify one approved fee;
- confirm an open accounting period;
- simulate the billing posting;
- confirm a collection bank/cash path;
- confirm a published default receipt template;
- simulate the payment posting;
- simulate an approval route at low and high thresholds;
- verify no critical posting exceptions remain.
P3–P6 provide the transaction procedures. P2 proves the foundation, not full production operation.
Worked scenario: Mupfure Learning Academy
Mupfure Education Group has tenant defaults for a process profile, four accounting books, and expenditure approval matrices. The Harare school needs a different bank account and a two-step approval route.
The implementer:
- selects Mupfure Learning Academy — Harare;
- copies the process profile and required books;
- copies the approval matrix as draft;
- changes the school route and amount bands;
- creates the fiscal year and periods;
- configures USD and the approved local currency;
- creates school bank accounts and receipt settings;
- configures posting mappings;
- simulates approval and posting;
- clears readiness failures;
- runs a dry run;
- applies controls.
The implementation record stores the school-owned IDs and the tenant source IDs. The team can therefore prove what was inherited and what was changed.
Failure modes
| Symptom | Likely cause | Evidence to inspect | Safe action | Escalate when |
|---|---|---|---|---|
| A setup page is read-only | tenant default selected or missing mutation ability | scope badge and permissions | select school or request access | scope is correct but backend returns 403 |
| Readiness remains blocked after save | stale query, wrong school, inactive/draft record, missing related record | active school, status, readiness code | refresh and inspect the exact failed requirement | requirement contradicts saved backend state |
| Apply creates a pending outcome | approval runtime requires a decision | approval request and source fingerprint | complete through Approvals | no eligible approver exists |
| A copied matrix is ignored | copy is draft or outside effective dates/amount/currency | matrix status, scope, thresholds | review, simulate, activate | active route still does not resolve |
| Posting simulation has no account | missing or inactive mapping/account | simulation result, mapping, GL account | correct mapping or account | resolver contradicts active configuration |
| Gateway readiness fails | provider inactive or no settlement account | bank settings and provider status | complete provider and account setup | credentials or external certification fail |
| Reporting readiness fails | incomplete Chart of Accounts or opening-balance decision | account list, readiness result | complete structure and document opening balance | statements remain incomplete after verified posting |
Verification checklist
- Tenant and school scope are visibly correct.
- School-owned profile, books, and matrices exist where required.
- Copied records retain provenance.
- Fiscal year is active and periods are generated.
- Required current period is open.
- Primary and supported currencies are documented.
- Chart of Accounts contains active posting accounts.
- Fees and concessions have valid status/effective dates.
- Bank accounts, providers, settlement defaults, and receipt template are configured.
- Approval routes simulate for representative thresholds.
- Posting simulations resolve active non-header accounts.
- Critical exceptions are cleared.
- Dry run passes.
- Explicit apply evidence is recorded.
- Independent reviewer can reproduce the readiness result.
Practice and knowledge check
Guided practice: build a readiness register for one test school and assign every failed requirement to an owner.
Independent scenario: a school has approved fees and a bank account, but billing and collections remain blocked. Identify at least four possible missing dependencies without changing production data.
- Why is navigation visibility not proof of readiness?
- What is the difference between a tenant default and a school copy?
- Why must a copied approval matrix be reviewed?
- What must happen before an explicit control application?
- Which evidence proves that routing is correct?
- Which evidence proves that posting account resolution is correct?
- Why is a successful dry run still not a full production test?
Answer guide: readiness is backend-evaluated; school copies are independent scoped records; copies may be draft or unsuitable; dry run must pass before apply; approval simulation proves routing; posting simulation proves account resolution; transaction testing remains required.
Next lesson
Continue to Fiscal calendar and accounting periods.