Every school fee receipt should be explainable without opening the database.

A fee system is reliable when office staff can answer who paid, what was due, what changed, who authorized an exception and how the receipt reconciles to the school's collection records.

Build fee plans before collecting money

Define fee heads, installment names, due dates and expected amounts before daily collection begins. If different classes or categories use different structures, record those rules explicitly. Avoid changing the meaning of a fee head midway through the year because historical reports may then become difficult to interpret.

Keep calculation and collection separate

The system may calculate an expected amount from the assigned plan, but a payment event should still record the amount actually collected, authorized discount, late fee and reference used. This distinction makes partial payments and legitimate exceptions easier to understand later.

Require authority for discounts and corrections

Not every cashier should be able to rewrite a discount or delete a receipt. Decide which roles may collect, adjust, reverse or approve exceptional transactions. Sensitive actions should leave an audit event and a reason rather than silently replacing old values.

Use stable receipt references

A receipt number is part of the school's financial trail. Duplicate protection should prevent the same reference from being accepted twice. If a receipt must be cancelled or corrected, prefer an explicit reversal/correction workflow that preserves the original history over deleting the evidence.

Handle partial payments deliberately

If the school accepts partial payment, the remaining due should be derived from the plan and recorded transactions rather than manually typed into a balance field. Staff should be able to see previous payments and the remaining amount before accepting the next collection.

Separate provider verification from button clicks

For online payments, a browser returning to a success page is not enough by itself. The server should verify the provider response, expected amount/currency and transaction identity before marking a school receipt or entitlement as paid. Provider references should be idempotent so a retry does not create a second credit.

Reconcile every day or collection cycle

Compare recorded receipts with the actual payment channels used by the school: cash, bank transfer, cheque or approved online provider. Differences should be investigated while the transaction is still recent. A small daily reconciliation habit prevents unexplained balances from accumulating across the term.

Protect reports from hidden edits

Reports should calculate from the transaction history and approved adjustments. A direct database balance edit can make the dashboard look correct while destroying the evidence needed to explain how it became correct. Use controlled operations instead.

Month-end review checklist

• duplicate receipt references: none unresolved;
• discounts and manual adjustments: reviewed by authorized person;
• online provider transactions: matched to verified references;
• cash/bank totals: reconciled to the school's records;
• reversed/cancelled receipts: reason and actor visible;
• unusual outstanding balances: checked against plan and transaction history;
• backup/report export: stored according to school policy.

What to test before go-live

Create a synthetic student and run a normal payment, partial payment, discount, duplicate reference attempt and correction. Confirm unauthorized users cannot perform restricted actions. Then verify the receipt history from a separate authorized account. A short controlled test is better evidence than assuming the feature works because the form saves successfully.