Every receipt tied to the demand it settles
Heads and structures, concessions, demands generated rather than typed, and a counter that reconciles at the end of the day. What is outstanding is derived from what was billed and what was collected — never tracked as a separate number that can disagree.
The receipt book and the collection register
A carbon-copy receipt book and a hand-totalled collection register can both be correct and still disagree, because the outstanding figure is maintained separately from the two things that determine it. Here the demand and the payment are records, and the balance is computed from them every time it is read.
A carbon-copy receipt book
A daily collection register totalled by hand
A defaulters list rebuilt every month
A concession approved on a note in a file
Fees, screen by screen
Each of these is a screen or a service in the module rather than a heading on a roadmap.
Structures out of heads
Fee heads and categories, assembled into structures per class or group, with concessions applied as records rather than as a discount somebody remembers. Demands are generated against students from the structure instead of being entered one at a time.
Receipt numbers that cannot collide
Numbers run sequentially within a financial year — April to March — and the counter is incremented inside the same database transaction that writes the payment. Two cashiers taking money at the same moment cannot be issued the same number.
A double-click does not double-charge
Collection runs through a transaction with an idempotency lock, so a resubmitted form or a flaky connection cannot post the same payment twice and produce two receipts for one payment.
The counter opens and closes
A cashier session starts with an opening float and closes on a count: expected cash against actual cash, with the over-or-short recorded rather than absorbed. A day either reconciles or says by how much it does not.
Status derived, not stored
Paid, partly paid, overdue or waived is computed from the demand and its payments at read time. There is no status flag to drift out of step with the money.
The screens a fee desk actually needs
A per-student ledger, a siblings view so one family is one conversation, a dues queue, a defaulters list, a daily collection register and a reconciliation screen — all reading the same rows.
Online payment, if you connect a gateway
A school can configure its own payment gateway credentials; a student can then pay an invoice from the portal, the callback is verified server-side before anything is recorded, and the receipt lands in the same ledger as a cash payment. Where no gateway is configured, the portal says to pay at the office instead of failing quietly.
The same row, read from somewhere else
The point of an ERP is not that it has a lot of modules. It is that a fee concession, an attendance shortfall and a report card are all reading one record. These are the places Fees touches.
Students
Demands are raised against student records and their class, so a transfer or a status change is reflected in billing without a second edit.
Reports
Collections and defaulters are built-in report definitions reading live rows, so a figure quoted at noon includes the payment taken at eleven.
Hostel & events
Hostel and transport charges are fee heads on the same ledger, which is why a family gets one outstanding figure rather than three.
What Fees does not do
Stated here rather than discovered in week three. If something you need is on this list, ask before you buy — it is a better conversation than the one after.
Overdue is a status, not a charge. Nothing in this build adds a late fee to a demand — the late-fee amount on an installment is written as zero wherever one is created and updated nowhere, and the late-fee portion of a payment is fixed at zero. A school that fines late payment should settle that before go-live rather than after the first month’s demands.
Concessions and waivers are recorded with a reason and an actor. Approval routing — who may approve what size of waiver — is not modelled; it is a permission question, not a workflow.
Online payment depends entirely on the school’s own gateway account. Nothing is collected on the school’s behalf and no money moves through this product.
Receipts are PDFs to print or hand over. There is no SMS or WhatsApp receipt, because neither channel sends in this build.
There is a ledger repair tool for demands whose totals were written by older versions of the engine. It exists because that drift happened, and it is better to say so than to leave a tool in the product with no explanation.
Set your institution up on Elevate
Start on the free plan for up to 250 students. Paid plans begin at ₹1499 per month, billed to the institution.