Chart of Accounts and posting mappings

The Chart of Accounts defines the accounting categories available to the school. Posting mappings connect a Finance event or attribute to the GL account codes the backend should resolve. Accounts and mappings are related configuration, but they are not the same record.

Audience: accountants, finance implementers, bursars, posting-control owners, and auditors
Learning time: 45 minutes
Navigation: Finance → Accounting → General Ledger and Finance → Finance Controls → Posting Controls
Boundary: exact account codes and operational debit/credit mappings are school design decisions. Examples in this lesson are illustrative unless simulation proves the configured result.

Learning outcomes

You will be able to:

• distinguish account master data from event mappings;
• create a coherent hierarchy of account types and headers;
• explain tenant-default and school-specific account resolution;
• configure mappings without using inactive or header accounts;
• use backend simulation before activation;
• recognise when a school override is appropriate;
• prove posting readiness with account, mapping, policy, and exception evidence.

Account types and normal balances

Account type	Plain-language purpose	Normal balance
Asset	resources such as cash and receivables	debit
Liability	obligations and deferred amounts	credit
Equity	accumulated ownership/fund balance	credit
Revenue	earned income	credit
Expense	consumed costs	debit

A normal balance is an accounting convention. It does not stop an account from temporarily carrying an unusual sign.

Header and posting accounts

A header account organises the hierarchy and cannot receive a journal debit or credit. A posting account can be used by journals and mappings if it is active.

Before any account is used in a mapping, verify that it:

• exists in the correct tenant/school scope;
• has the intended account type;
• is active;
• is not a header;
• has valid parentage;
• has an appropriate currency context;
• has a stable account code.

Tenant-default and school-specific resolution

For a school-scoped posting, account-code lookup follows:

Cross-school parentage is rejected. A tenant-level posting without school context uses tenant-default accounts only.

Use school overrides deliberately. Copying every tenant account into every school increases maintenance and can hide which defaults remain effective.

Account master versus mapping

Configuration	Stores	Example
GL account	code, name, type, hierarchy, active/header flags, currency	1110 Main USD bank
Posting policy	global control flags and close requirements	block missing mapping
Account mapping	event attribute/key to account code and side	bank transfer → 1110 debit
Rule override	stronger replacement for a posting type	special debit/credit for one event
Approval/change request	maker-checker evidence for control mutation	mapping change pending
Simulation	backend-resolved result for a sample context	resolved debit/credit and reason
Posting exception	evidence that a real event could not post safely	missing mapping

The frontend must not calculate final debit and credit accounts. Use the posting-controls simulation endpoint.

Mapping dimensions

A mapping can use dimensions such as:

• scope: tenant default or selected school;
• mapping type;
• mapping key, such as fee type, payment method, category, or provider;
• posting type, such as a verified payment or approved invoice;
• account code, debit account code, or credit account code;
• side;
• currency;
• priority;
• status;
• effective dates;
• reason.

At least one account-code field is required by the mapping contract. Lower priority numbers may have higher precedence according to the active resolver convention; verify this with simulation instead of relying on memory.

Prerequisites

Requirement	Why it matters
Approved accounting design	codes and hierarchy affect all statements
Tenant/school scope decision	determines inheritance and overrides
Fiscal year and open period	enables representative posting tests
Currency design	accounts and mappings may be currency-specific
Required accounting books	readiness checks expect the accounting foundation
Posting policy	defines missing-mapping and manual-journal controls
Named account owner	prevents uncontrolled code changes
Mapping scenarios	fee types, payment methods, providers, and actions must be enumerated
Independent reviewer	mapping changes can redirect financial reporting

Roles and exact permissions

GL accounts

Action	Ability
List accounts	gl_account:list
Read account	gl_account:read
Create account	gl_account:create
Update account	gl_account:update
Delete/soft-delete account	gl_account:delete

Posting controls

Action	Ability
View policies	finance_control:read
List mappings/rules	finance_control:list
Create/update/delete directly	finance_control:create, finance_control:update, finance_control:delete
Manage policy	finance_control:manage_policy
Request controlled change	finance_control:request_change
Approve/reject change	finance_control:approve
Apply approved change	finance_control:apply_change
Simulate	finance_control:simulate
View readiness	finance_control:readiness
View/resolve exceptions	finance_posting_exception:list, finance_posting_exception:resolve

Guided procedure

1. Design the minimum account structure

Start with reporting needs and control accounts, not with a large copied catalogue. Define:

• assets, liabilities, equity, revenue, and expenses;
• header hierarchy;
• bank and cash accounts;
• student receivable control;
• supplier payable control where used;
• revenue accounts by approved reporting need;
• discount/scholarship/adjustment accounts where policy requires;
• suspense or exception treatment only when approved.

2. Create tenant defaults or school accounts

Navigate to Finance → Accounting → General Ledger (finance/general-ledger).

Create header accounts first, then child posting accounts. Use school scope only for accounts that truly differ.

Expected result: account selectors display code, name, type, and scope.
Control: never create a posting account under a parent from another school.

3. Review account readiness

Search/filter the list and confirm every required account is active and non-header. Test school-specific lookup where overrides exist.

4. Configure posting policy

Open Finance → Finance Controls → Posting Controls → Policy (finance/posting-controls/policy).

Review flags for:

• approval of mappings/rule overrides;
• segregation of duties;
• blocking on missing mapping;
• school account overrides;
• manual journals;
• close prerequisites;
• default currency.

5. Create mappings

Open Posting Controls → Mappings (finance/posting-controls/mappings).

For each approved scenario:

1. choose scope;
2. choose mapping type and key;
3. choose posting type;
4. select active posting accounts;
5. set side/account codes;
6. set currency and effective dates;
7. set status and priority;
8. record reason.

6. Simulate before saving or activating

Test at least:

• tenant-default account path;
• school override path;
• fee/invoice event;
• payment method/provider event;
• currency-specific event;
• missing mapping;
• inactive account;
• effective-date boundary.

7. Use change requests where policy requires

When direct save is not permitted or maker-checker is enabled:

1. submit a change request;
2. independent approver reviews impact and simulation;
3. approver approves or rejects;
4. authorised applier applies an approved request;
5. rerun readiness and simulation.

8. Clear exceptions

Open Posting Controls → Exceptions and resolve the underlying configuration. Do not mark an exception resolved without correcting or documenting the cause.

Illustrative posting examples

Illustrative only

These entries teach the relationship between events and accounts. Your configured simulation is the source of truth.

Event	Illustrative debit	Illustrative credit
Approved tuition invoice	Student receivable	Tuition revenue
Verified bank payment	Bank account	Student receivable
Approved credit note	Revenue/adjustment account	Student receivable
Supplier invoice	Expense/asset	Supplier payable
Supplier settlement	Supplier payable	Bank account

Worked scenario: Mupfure Learning Academy

Mupfure Education Group provides tenant-default accounts for tuition revenue and student receivables. The Harare school needs a school-specific USD bank account.

The implementer:

• leaves shared revenue/receivable accounts as tenant defaults;
• creates school account 1110-HRE for the Harare USD bank;
• links the school bank account to that GL account;
• creates a school mapping for verified bank-transfer payments;
• simulates the event;
• confirms debit resolves to the school bank and credit resolves to the tenant-default receivable;
• submits the mapping through maker-checker;
• applies it after approval;
• verifies readiness and no critical exception.

Failure modes

Symptom	Likely cause	Evidence to inspect	Safe action	Escalate when
Account cannot be selected	header, inactive, wrong school, or missing permission	account flags/scope	select/create eligible account	eligible account remains hidden
Simulation returns missing mapping	no active effective mapping for context	posting type, key, currency, dates	create/correct mapping	resolver ignores matching active mapping
Wrong school account resolves	override scope/code conflict	account list and simulation evidence	correct school override/design	backend violates documented precedence
Mapping save creates request	policy requires maker-checker	change request status	complete approval flow	no eligible approver/applier exists
Statement classification is wrong	account type or mapping is wrong	journal source and resolved accounts	use controlled correction; update future config	posted history requires complex remediation
Delete is blocked	account referenced or protected	API error and dependencies	retire/deactivate according to policy	no safe retirement path exists

Verification checklist

• Account hierarchy is approved.
• Header and posting flags are correct.
• Tenant defaults and school overrides are intentional.
• All mapped accounts are active and non-header.
• Currency and effective dates are explicit.
• Posting policy reflects the control design.
• Representative simulations resolve correctly.
• Missing-mapping simulation fails safely.
• Maker-checker evidence exists where required.
• Critical exceptions are resolved.
• Trial balance/statement tests use posted sample journals.

Practice and knowledge check

Guided practice: create one tenant-default revenue account, one school-specific bank account, and a simulated payment mapping in a test school.

Independent scenario: an active mapping points to an inactive account after a Chart of Accounts cleanup. Explain the safe recovery.

1. What is the difference between an account and a mapping?
2. Why can a header account not be used for posting?
3. What is the school-account lookup order?
4. Why must the backend simulate the final posting?
5. When should a school override be created?
6. What evidence should an approver inspect for a mapping change?
7. Why does resolving an exception require more than changing its status?

Answer guide: accounts classify balances and mappings resolve events; headers group only; school override precedes tenant default; backend owns resolver logic; overrides are for real school differences; inspect scope, effective dates, accounts, simulation, and reason; the underlying cause must be corrected.

Next lesson

Continue to Fee catalogue and structures.