JEduManage
Fee management

The fee module a school office actually trusts.

JEduManage's fee management handles per-class structures, per-student discounts, opt-in bus fees, payment recording across every common method, DLT-compliant SMS reminders, and a parent breakdown that ends the 'how much do we still owe?' phone calls — all backed by an immutable audit trail.

Fees are the most politically sensitive workflow in a school. A wrong number on a parent's invoice is not just an accounting mistake — it becomes a phone call to the principal, a hallway conversation, and sometimes a withdrawal. JEduManage's fee module is built around two unglamorous virtues: every number is traceable to who set it, and every change is recorded with a reason. The result is a system the office can defend in front of anyone — a parent, an auditor, a board chair — without having to reconstruct anything from memory.

Fee structures live per (class, academic year)

Every fee structure in JEduManage is tied to exactly one class and one academic year. Class VI 2025-26 is a different structure from Class VI 2026-27 and from Class VII 2025-26. The structure carries the three components a school office actually negotiates with the management each year:

  • Tuition fee — the headline annual figure for the class
  • Exam fee — board exam fees, internal assessment fees, mock test fees as applicable
  • Miscellaneous — lab, library, sports, activity, ID card, and any other line item the school bills uniformly to the class

Bus fee is deliberately not in this list. Transport is a separate per-tenant catalogue (see below) because students who don't use the school bus must not be billed for it, and the route fee can vary enormously between a 3 km stop and a 22 km stop. Bundling transport into the class fee structure was the single most common mistake we saw in the legacy systems schools migrated from, and JEduManage corrects it at the model level.

A class with five sections doesn't need five fee structures — the structure attaches to the class, and every section inherits it. Promotion to the next academic year creates a new structure for the same class with the updated numbers; the previous year's structure stays archived and continues to back the bills of students who were enrolled then.

Bus routes: a separate per-tenant catalogue

The Bus Routes page is the school's transport catalogue. Each route has a name, a code, a route description, an annual fee, and a list of stops. Routes belong to the tenant, not to any single class — a Class VI student and a Class XI student can ride the same route at the same fee. Transport assignment happens during admission (or later, when a family opts in) and is independent of the class fee structure. Students who walk, cycle, or arrange their own transport are simply not assigned to a route and are never billed for it.

Snapshot at assignment — the structure is a template, the bill is frozen

When a fee structure is assigned to a student, the total — tuition plus exam plus miscellaneous — is computed and written to the student's record as totalFee. That number is frozen. If the school later edits the structure (a board meeting revises miscellaneous mid-year, for example), the structure changes for future assignments but already-billed students see no change to their bills. The same rule applies to bus routes: when a student is assigned to a route, the route's current annual fee is snapshotted onto the student's record. A later route fee edit affects new assignments only.

This is the single most important design decision in the module. It means a parent who paid an invoice in May based on a published figure will never open the portal in October to discover the figure has silently moved. If the school genuinely needs to re-price an existing student — a fuel surcharge, an annual revision — that's an explicit FeeAdjustment with a reason, not a silent edit. The history is always honest.

Per-student adjustments — discounts, concessions, ad-hoc changes

Real schools rarely bill every student the strict class rate. Sibling concessions, staff-child discounts, scholarships, hardship waivers, mid-year prorations, and ad-hoc adjustments (the parent paid an excursion separately and wants it removed from the bill) all show up routinely. The FeeAdjustment model handles them as audited rows against the student's record:

  • Type — discount, scholarship, waiver, concession, refund, or ad-hoc adjustment
  • Amount — the rupee value, positive or negative
  • Reason — free-text justification ("Sibling concession — second child of registered family"; "Hardship waiver — board-approved")
  • Actor — the staff user who applied the adjustment, with timestamp
  • Audit row — written immutably to the audit log alongside the adjustment record itself

The student's pending amount reflects every adjustment automatically. There is no separate "issue a corrected invoice" step — the running balance is the truth, and the parent's portal updates the next time they open it. If a principal later wants to know why a particular student is billed Rs. 18,400 instead of the published Rs. 22,000, the answer is on the adjustment history, with the reason, the actor, and the date.

Payment recording across every common method

The Payment model records each payment with the amount, the date, a method, and an optional reference number (UPI transaction ID, cheque number, DD number, card terminal reference). The supported methods are:

  • Cash — the office collects and records
  • UPI — usually with the upstream transaction reference attached
  • Card — for schools that operate a POS at the office
  • Net banking — bank transfer with reference number
  • Cheque — number, bank, and date recorded
  • Demand draft — DD number and issuing bank recorded
  • Wallet — any digital wallet payment captured manually

Payments are written against the student's StudentFee record and the pending amount recomputes immediately. The full payment history is visible to the office and (filtered to that family) to the parent on the parent portal — payment date, amount, method, reference, and receipt download. Reconciling at month-end becomes a single export rather than a manual ledger walk.

Waivers and refunds — edge cases that always come up

Waivers and refunds are the edge cases every fee system needs to handle gracefully. A hardship waiver reduces the pending amount with a board-approved reason; a refund reverses a previously recorded payment because the cheque bounced or because a student withdrew within the refund window. Both are FeeAdjustment rows with their own type — they're not pretend-payments or pretend- fees, which means downstream reports (collected vs. billed, waiver totals for the year, refund totals for the year) come out honest without any post-processing.

The audit log captures both. A principal asked at the next board meeting "how much did we waive last year and why?" answers from the audit panel with the totals broken out by reason. There is no end-of-year tidying ritual; the data is already in shape.

SMS reminders: DLT-compliant, MSG91-backed, category-logged

Fee-due and fee-pending reminders are sent through MSG91 using DLT-compliant templates registered with the carrier. The admin builds the recipient list from the StudentFee table — filterable by class, by amount-due threshold, by overdue days — and the system shows a preview screen with the recipient count and the rendered template before anything actually leaves. Bulk-send mistakes (the wrong template, the wrong class) become hard rather than easy.

Every SMS is logged under the FEE_DUE category in the tenant's SMS log, with the recipient, the rendered message, the MSG91 request ID, and the eventual delivery outcome. When a parent calls saying they didn't receive a reminder, the office answers from the log within seconds. The same MSG91 channel powers absentee SMS (covered on the attendance management page), so the school operates one DLT setup, not several.

What the parent sees

The parent portal shows a single fee summary per child with a clean per-category breakdown:

  • Tuition — annual tuition charge from the assigned class structure
  • Bus — annual bus fee from the assigned route (or zero if not assigned)
  • Exam — exam fee component from the structure
  • Miscellaneous — lab, library, activity, and any other line items
  • Total — sum of the above, frozen at the time of assignment
  • Paid — running total of recorded payments
  • Pending — total minus paid minus adjustments

Below the summary, the parent sees the full payment history with method, date, reference, and receipt download. Adjustments are visible with their type and date (the internal reason text is available to the office only). The result is a view the parent can answer their own questions from — which removes most of the "how much do we still owe?" phone calls the school office would otherwise field, and gives the parent the same confidence in the number that the office has. The student information system covers the rest of the student record that backs this view.

The audit log is the safety net

Every fee-related action is recorded as an immutable audit row. That includes structure assignment, route assignment, route change, FeeAdjustment creation, waiver, refund, payment recording, and SMS reminder send. Each row carries the actor, the timestamp, the affected student, the before value, and the after value. Investigations that used to take an afternoon of interviews now take a filter on the audit panel.

For schools operating under board-level scrutiny — and most schools above a certain size do — the audit log is the single biggest reason the fee module earns trust. The principal can answer "who changed this student's fee from 22,000 to 18,400 and when?" with a query, not a recollection.

How the fee module fits the rest of JEduManage

The fee module is one chapter of the larger product. The class and section the student belongs to come from the SIS; the parent identity that signs into the portal is the same one provisioned at admission; the SMS channel that delivers the reminders is the same MSG91 pipeline that delivers absentee notifications and OTP logins; the audit log that records fee adjustments is the same audit log that records role changes and student transfers. Read the features page for the per-module breakdown, or start a conversation and we'll spin up a tenant with your school's class list and a sample fee structure so you can see the parent and office views side by side, usually the same day.

Related reading

Fee Management

Fee Management Software for Schools

Fee collection is where school admin gets painful. Fee management software brings structures, discounts, online payments, receipts and reminders into one reconciled ledger.

Read moreSchool ERP

Top Benefits of School ERP Software

School ERP software replaces a dozen disconnected registers and spreadsheets with one system. Here are the benefits that actually move the needle for schools.

Read moreSchool Administration

Best School Management Software in India (2026 Guide)

A practical buyer’s guide to choosing school management software in India: the modules that actually matter, an evaluation checklist, pricing realities, and a calm rollout plan.

Read more
FAQ

Fee management — common questions

How are fee structures organised?
Fee structures are defined per (class, academic year). A single structure carries the tuition, exam, and miscellaneous components for one class in one year — for example, Class VI fee structure for 2025-26. When a student is admitted into that class, the structure is assigned to them and the total is snapshotted onto their record. The structure itself stays a template; the student's bill is a frozen copy. Bus fee is deliberately not part of the structure — transport is a separate per-tenant catalogue that's opt-in per student.
Can fees vary per student — discounts, scholarships, sibling concessions?
Yes. Per-student adjustments are first-class. The office can record a discount, a scholarship credit, a sibling concession, or any ad-hoc adjustment against an individual student with a free-text reason. Each adjustment is an audited row — actor, amount, reason, timestamp — so the principal can reconstruct the negotiation history at any time. The student's running balance reflects every adjustment automatically, and the parent's portal view shows the updated total without anybody having to re-issue an invoice.
How does the bus fee work?
Bus routes are a per-tenant catalogue with their own annual fee. They are not bundled into the class fee structure. When a student is assigned to a route, the route's current annual fee is snapshotted onto the student's record — the same way the class structure was. If the school later edits the route fee (a fuel-price revision, a route extension), already-assigned students keep the price they were billed; only new assignments pick up the new amount. This avoids the embarrassing situation where a parent's bill silently changes mid-year.
Can parents pay online?
The fee module records payments against students with method, amount, date, and reference number. Supported methods are cash, UPI, card, net banking, cheque, demand draft, and wallet — entered by the office when a payment is received. Each recorded payment appears in the parent's portal history with the receipt details. Direct online payment by parents (a gateway integration that lets the parent pay from the portal) is the next phase of the module; reach out via contact if your school needs that path live before its general release.
What if a student joins mid-year?
The fee structure for the class and academic year is assigned at admission, and that total is the starting bill — there is no automatic proration in the base flow. For schools that admit mid-year and want to bill only a partial year, the recommended path is a FeeAdjustment with reason 'Mid-year admission proration' for the unbilled months. This keeps the structure's total faithful to the canonical class rate while the per-student record reflects the negotiated number, and the audit log makes the calculation legible to anyone reviewing it later.
How are SMS reminders triggered?
The admin can send fee-due and fee-pending reminders to parents of students with outstanding balances. The recipient list is generated from the StudentFee table — filtered by class, by amount-due threshold, or by overdue days — and previewed before any message leaves. Messages use a DLT-compliant template registered with MSG91 and are logged under the FEE_DUE category in the SMS log, with the recipient, rendered text, MSG91 request ID, and delivery outcome. The admin can pull a delivery report from the SMS log at any time to see who received what.
What about waivers and refunds?
Waivers and refunds are recorded as audited fee adjustments against the student's record — a waiver reduces the pending amount with a reason like 'Hardship waiver — board-approved'; a refund reverses a previously recorded payment with a reason like 'Cheque bounced — refund issued'. Both write immutable rows into the audit log with the actor, timestamp, and free-text justification. The parent's portal view reflects the change automatically, and the office can produce the full adjustment history for any student during an inspection.

Move every school operation onto one calm surface.

See JEduManage in your environment. We'll spin up a working tenant with your school's branding, classes, and a sample student cohort — usually within the same day you reach out.