Designing a fee structure that survives concessions
Sibling discounts, staff wards, scholarships and part payments are not exceptions to your fee structure. They are the structure. Design for them first and the ledger reconciles itself.
Every fee system demonstrates beautifully. You enter a tuition amount, generate a demand, take a payment, print a receipt. Then the real year starts. A brother joins in class three. A teacher's daughter is admitted. A trustee approves half fees for a family whose father died in August. A parent pays in four instalments, two of them late, one by cheque that bounces.
By March the accountant keeps a private spreadsheet, because the system’s number and the true number stopped agreeing in September. That spreadsheet is not a discipline problem. It is a design problem, and it has a specific cause: the structure was built for the standard case and concessions were bolted on as adjustments.
Four layers, applied in a fixed order
A fee amount is not a number. It is the result of four layers evaluated in sequence, and the order has to be the same for every student in every branch, or two people computing the same fee will get different answers.
{{ l.d }}
{{ l.wrong }}
The rule that separates layer two from layer three
Every concession is either a rule or a decision. A rule fires from a fact the system already holds and needs no approval. A decision needs a person to take responsibility.
Second sibling pays 75 per cent of tuition. The system knows the guardian and the sibling, so it applies itself, every term, without anyone remembering. If a rule needs remembering, it is not configured.
Half fees for a bereaved family. No fact in the system implies it, so it needs a named approver, a stated reason, a category and an end date. Otherwise it becomes permanent by accident.
Could a clerk who has never met this family arrive at the same amount from the record alone? If yes, it is a rule and belongs in layer two. If no, it is a decision and belongs in layer three with a name against it. Concessions that sit in neither layer are the ones that end up in the private spreadsheet.
Seven cases to configure before go-live
These arrive in every institution’s first year. Decide each one on paper before the structure is built, because retrofitting any of them means recomputing a term already billed.
| Case | The question to settle | Layer |
|---|---|---|
| {{ c.k }} | {{ c.q }} | {{ c.layer }} |
Part payments break arrears, not fees
Part payment is where most fee systems quietly lose the ability to report. A family owes three instalments and pays a round amount that matches none of them. If that payment lands against the gross balance, the arrears report can no longer say which instalment is overdue or by how many days.
Settle payments against instalments in a fixed order, oldest first, and let the last one sit partly paid. The report then answers the only question a trustee asks: how much is overdue by more than thirty days, and from whom.
When a payment arrives, what does it clear first: the oldest instalment, the oldest head, the late fee, or the head the parent named on the challan? Every institution has an answer in practice and almost none has it written down. Write it down, then configure it, and the reconciliation stops being an argument.
Five numbers the structure must be able to produce
If the design cannot yield these without a spreadsheet, it is not finished, however well it demonstrates.
A fee structure is judged in its second year, when the sibling has joined, the scholarship has lapsed, the staff ward has changed section and the bereaved family’s concession is due for review. Design for that year and the first one takes care of itself.
Bring your fee policy and your concession list.
A consultant sorts your real concessions into rules and decisions, then shows the structure computing them.