Fee administration

Defining what to charge before anyone pays: fee types, structures, the installment schedule, bulk generation, and the checks that stop a wrong structure becoming thousands of wrong invoices.

Fees & finance guide for day and boarding schools.

Last updated August 29, 2026

What this is for, and when you do it

This is the annual configuration job. Once the academic year exists, the calendar is synced and classes have students in them, an administrator decides what the school charges, how much per class, and on which dates it falls due. Then generation turns that configuration into per-student invoices. Everything downstream - the counter, the parent portal, the defaulters list, the collection forecast - reads those invoices, so the quality of this half hour of work decides whether the rest of the year is quiet.

Do it before the first day of the term you are billing for, and do it in order. The order is not a style preference: a fee structure cannot exist without a fee type, an installment schedule is only meaningful once structures carry an installment count, and generation freezes the amount and due date onto each instance. Generating first and configuring afterwards leaves a set of invoices that no longer agrees with the fee circular, and correcting those is manual work on live records that families can already see.

The order, and the reason for it

Create fee types at /fees/fee-types. Name and code each charge - tuition, admission, lab, activity - and create TRN now if the school runs buses, because transport reads that exact code.
Build fee structures at /fees/fee-structures. One per fee type per year, priced for a specific class or for a whole grade, with the installment count, the first due date, and the grace days.
Check the installment schedule at /fees/fee-schedule. The grid shows types against grades for the selected year and is where a missing or duplicated structure is obvious; /fees/fee-schedule-view is the read-only version for operators.
Configure late fees at /fees/settings/late-fees, tax at /fees/settings/gst or /fees/settings/vat, and the reminder ladder at /fees/settings/dunning. Do these before generation so the first cycle behaves like every later one.
Bulk generate at /fees/bulk-generate, or per class from /fees/setup. Generation is per student and only fills gaps, so re-running it later to pick up new admissions is safe.
Review /fees/class-summary against the published fee circular before you let anyone take payment. This is the last cheap moment to find a wrong number.

What breaks when the order slips

Skipped or done late	Symptom	Cost of the fix
No fee type with the code TRN	Transport assignments create no fee lines and say nothing about it	Low if caught early: create TRN, then re-assign the affected riders
Structure priced wrongly, then generated	Families see and can pay an incorrect invoice	High: edit or delete instances one by one, and paid ones need a refund
Installment count changed after generation	Old instances keep the old split; new ones use the new one	Medium: the year has two shapes of invoice until the old ones are cleared
Dunning and late-fee settings left until later	The first overdue cycle is chased differently from every later one	Low, but families notice the inconsistency
Generation never run	Empty /fees/me, empty defaulters list, forecast of zero	Low: run /fees/bulk-generate, it only fills gaps

What arrives from elsewhere

Three other modules create fee instances without anyone opening the fees screens. Enrolling an accepted admission offer provisions the student fee lines after the parent portal user is created, and records the fee step separately so a failure can be retried from the Enrollment recovery panel on /admissions/enrollments; a missing structure does not block the enrolment, it just leaves the student with no fee lines. Assigning a transport rider to a stop with a monthly fee creates monthly TRN instances. An overdue library book posts a LIB_FINE instance due in fourteen days, creating that fee type the first time it is needed. All three land as ordinary invoices and are collected at the same counter.

Who does what

Configuration and generation - Platform Admin, Principal, Vice Principal, Support Staff - Finance, or Admin. The same five roles as collection, so a finance officer can both define and bill.
The read-only schedule at /fees/fee-schedule-view is for staff who need to quote a fee without being able to change one.
Families never see configuration. They see the resulting instances on /fees/me, and only for themselves or a linked child.

Limits

No discount rules engine. There is no sibling rule, no staff-ward rule and no automatic concession; the categories are labels on a hand-entered waiver.
An installment split is even. Multi-installment structures divide the amount equally and space the due dates evenly across the year from the structure due date.
A structure belongs to one academic year. Year rollover can copy active structures into the new year, but instances are never copied - you generate them again for the new year.
Fee structures carry no school id, so on a deployment with more than one school the catalogue is shared.

Common questions

Quick answers in plain language.

Bulk generate reported no fee structures found for a class. What is wrong?+

Generation matches on the class the student is actively enrolled in first, and only falls back to grade and section when there is no active ClassStudent row. So this appears when the structure was created for a grade while students are enrolled in a specific class, when the structure is inactive, or when it belongs to a different academic year. Check the year selector and the class column at /fees/fee-structures.

How are due dates decided for a four-installment fee?+

The first installment takes the due date on the structure, or the academic year start date when the structure has none. Later installments are spaced evenly - twelve months divided by the installment count - so four installments fall three months apart. Each instance stores its own date, so adjusting a single family later is an edit on that instance.

Can I delete fee instances created by a wrong bulk generation?+

Unpaid ones, yes, one at a time from the fee instance record. Paid ones cannot simply be removed: the payment has to be refunded through /fees/refunds first, which needs a second approver. This is the reason to generate a single class, verify it on /fees/class-summary, and only then generate the rest.

Do sibling and staff-ward discounts apply automatically?+

No. Those categories exist only as labels on a waiver at /fees/waivers, and the amount is typed in by a person and approved by a second one. Nothing in the product looks at family relationships or staff status to reduce a fee, so a school with a published concession policy applies it case by case.