Fee catalogue and structures

A school fee defines what may be charged, to whom, for which period, in what currency, and under which billing and approval rules. A fee is pricing configuration; it is not an invoice and it does not by itself create a student debt.

Audience: bursars, billing administrators, implementers, school leaders, and reviewers
Learning time: 45 minutes
Navigation: Finance → Billing → Pricing & Billing Rules → Fee Structures (finance/fees)
Boundary: P2 configures the catalogue and payment-plan foundations. P3 documents assignment, billing runs, invoices, and student-account outcomes.

Learning outcomes

You will be able to:

• distinguish a fee, payment plan, installment option, and invoice;
• configure fee identity, scope, amount, dates, and controls;
• explain approval and active/effective status;
• identify exact fee and payment-plan permissions;
• verify that a fee is eligible for readiness and later billing;
• avoid ambiguous or overlapping fee definitions;
• document configuration-dependent tax, statutory, and accounting mappings.

Core objects

Object	Purpose	Does it create debt?
School fee	reusable charge definition	No
Payment plan	reusable schedule and installment rules	No
Fee adjustment configuration	controlled fee-level change metadata	No
Billing run	executes billing for eligible students	Later, in P3
Invoice	records the student obligation	Yes
Invoice line	priced component on an invoice	Yes

Fee field groups

Identity and scope

Field	Meaning	Control
Fee name	visible charge description	clear and non-duplicative
Fee code	optional stable identifier	use naming convention
Fee type/category	reporting and rule classification	use approved vocabulary
School	owning school	verify active scope
Academic year/term	billing context	must match approved calendar
Applies to	audience rule	grade, class, student type, or approved criteria
Mandatory	whether eligible students must be billed	governance decision
Effective from/until	configuration window	no accidental overlap

Pricing and timing

Field	Meaning
Amount	positive configured value
Currency	three-letter currency context
Payment frequency/billing cycle	recurring timing description
Due date/payment deadline	expected settlement dates
Grace period	configured delay before consequences
Late-fee settings	optional policy fields; do not assume statutory validity
Deposit/installment options	optional staged-payment configuration

Concessions and policy

A fee can carry discount, scholarship, subsidy, refund, tax, approval, compliance, and supporting metadata. The presence of these fields does not replace the dedicated discount and scholarship programs documented in the next lesson.

Accounting and evidence

Fee records can include GL account code, cost centre, revenue stream, approval history, export status, board/ministry references, notes, tags, and metadata. Exact posting still depends on posting policy and mappings.

Status boundaries

Fee contracts include:

• approval_status, commonly draft/pending/approved/rejected-like workflow values;
• is_active;
• effective_from and effective_until;
• soft archive/deletion rather than destructive loss of evidence.

A fee should be treated as billable only when its approval, active flag, scope, and effective dates all support use.

The exact UI action that submits a fee for approval must be verified against the active screen. Do not invent a transition not shown by the product.

Payment plans

A payment plan defines a reusable schedule, not a payment transaction.

Field	Meaning
Name/code	plan identity
Payment frequency	monthly, termly, or approved schedule
Total installments	positive count
Deposit/grace rules	optional starting and tolerance values
Schedule rules	structured installment logic
Applicable fee IDs/student types	scope
Default flag	preferred plan where applicable
Status/approval	lifecycle
Accounting metadata	optional GL/cost/revenue references

Installment rules should total the intended obligation and use dates aligned with the academic and fiscal design.

Prerequisites

Requirement	Why it matters
Active academic year and term	fee scope and billing readiness
Approved fee policy	amount, audience, dates, concessions
Currency design	prevents mixed-currency ambiguity
Student classifications	eligibility depends on reliable grade/class/boarding status
Chart of Accounts/mapping design	supports later posting
Approval owner	pricing changes affect obligations
Tax/statutory review	fields do not guarantee compliance
Communication decision	invoice/receipt wording must align later

Roles and exact permissions

Action	Ability
Create fee	financial_fee:create
List fee	financial_fee:list
Read/view fee	financial_fee:read or navigation alias financial_fee:view where used
Update fee	financial_fee:update
Archive fee	financial_fee:delete
Create/list/update/archive payment plans	financial_payment_plan:create, financial_payment_plan:list, financial_payment_plan:update, financial_payment_plan:delete
Manage plan installments	financial_payment_plan_installment:create, financial_payment_plan_installment:list, financial_payment_plan_installment:update, financial_payment_plan_installment:delete
Create/list/update/delete fee adjustments	financial_fee_adjustment:create, financial_fee_adjustment:list, financial_fee_adjustment:update, financial_fee_adjustment:delete

The navigation can use view aliases while endpoints use list/read. The backend endpoint ability is authoritative.

Guided procedure

1. Build the fee catalogue workbook

For each planned charge record:

• unique name/code;
• fee type/category;
• school;
• academic year/term;
• eligible grade/class/student types;
• mandatory/elective;
• amount/currency;
• frequency and due dates;
• late/deposit/installment policy;
• scholarship/discount eligibility;
• accounting references;
• approval owner;
• effective dates;
• external policy evidence.

2. Open Fee Structures

Navigate to Finance → Billing → Pricing & Billing Rules → Fee Structures.

Expected result: fee list is scoped to the selected school and uses current filters.

3. Create a test fee

Enter every required field. Amount must be positive. Use the school’s approved currency code and calendar scope.

Control: do not create two active fees with overlapping scope unless the design explicitly requires separate charges.

4. Configure eligibility

Choose the exact audience. Do not infer grade or boarding eligibility from the fee name. If using IDs, verify the referenced grades/classes belong to the school and current structure.

5. Configure due and payment rules

Align due date, payment deadline, grace, deposit, and installment options. Avoid contradictory dates.

6. Configure accounting metadata

Record fee type/category and approved GL/cost/revenue references. Then test the actual posting mapping in Posting Controls → Simulate.

7. Complete approval and activation

Follow the visible fee approval workflow. Record approver, timestamp, notes, and effective window. Confirm is_active.

8. Configure a payment plan if required

Create the schedule, applicable fees/student types, installment count, and approval status. Validate that schedule rules are complete.

9. Verify billing readiness

Open Controls Readiness and confirm the Approve a fee requirement passes for the selected school.

Worked scenario: Mupfure Learning Academy

The school configures:

• TUIT-T1-G7 — Grade 7 Term 1 tuition, USD 500, mandatory;
• TRANS-T1-HRE — Harare transport, USD 120, elective;
• a three-installment tuition plan with 40%, 30%, and 30% due dates.

The implementer confirms:

• both fees belong to the current academic year/term;
• transport applies only to selected transport users;
• the tuition fee is scholarship eligible;
• the installment schedule totals 100%;
• posting simulation resolves tuition revenue and student receivable accounts;
• the fees are approved, active, and effective;
• readiness detects at least one approved current fee.

No student is billed during P2. P3 performs assignment and billing.

Failure modes

Symptom	Likely cause	Evidence to inspect	Safe action	Escalate when
Fee is absent from readiness	not approved, inactive, wrong school/year/term, outside dates	fee status and scope	correct configuration	valid fee remains excluded
Billing would duplicate charge	overlapping active fees or unclear eligibility	catalogue workbook and fee filters	retire/correct before billing	existing invoices already affected
Amount/currency is wrong	copied record or design error	approval history and source policy	correct before billing; reapprove	posted/billed history exists
Installment plan does not reconcile	percentages/amounts/dates incomplete	plan rules	correct plan	engine result contradicts schedule
Fee update resets approval	controlled financial fields changed	approval history	submit/review again	status transition is inconsistent
GL mapping is unresolved	fee type/category not mapped	posting simulation	configure mapping	active matching mapping ignored

Verification checklist

• Fee identity/code is unique and clear.
• School, academic year, and term are correct.
• Eligibility is explicit.
• Amount is positive and currency is approved.
• Due, deadline, grace, deposit, and installment rules are coherent.
• Discount/scholarship eligibility is intentional.
• Accounting references and posting simulation are verified.
• Approval and active/effective status support use.
• Readiness recognises the fee.
• No student debt was created during configuration testing.

Practice and knowledge check

Guided practice: configure one mandatory tuition fee and one elective service fee in a test school.

Independent scenario: two current tuition fees both apply to Grade 7. Determine whether this is intentional without running billing.

1. Why is a fee not an invoice?
2. Which dimensions decide whether a fee is usable?
3. Why should eligibility not be inferred from a name?
4. What must an installment schedule prove?
5. Why is a GL code field not enough to prove posting?
6. What does the readiness check need from a fee?
7. What happens when a controlled field changes after approval?

Answer guide: fees are reusable configuration; approval/active/scope/effective dates matter; structured fields are authoritative; schedules must reconcile; posting resolver must be simulated; at least one approved active current fee is needed; reapproval may be required.

Next lesson

Continue to Discounts, scholarships, and sponsorships.