Sibling 10%. Staff ward 50%. Applied automatically, every invoice.
One Discount Types catalog plus three preset auto-rule engines — Sibling Discounts (by child position), Staff Ward Discounts (by parent's staff category), and Early Payment Discounts (by days-before-due-date). 15 built-in categories from Sibling and Staff Ward to EWS, RTE, Defense, Single Parent, Alumni and Loyalty. Set the rule once at session start, every invoice the school office issues honours it automatically — with stack priority, approval thresholds, and a per-discount audit trail.
How most Indian schools apply fee discounts today
It is the second day of admission week in a CBSE day school in Indore. The admissions desk has just admitted Aarav in Class 3 — his elder sister Anaya is already in Class 7. The accounts officer opens the fee receipt template, manually subtracts 10% from Aarav's Tuition line, writes 'Sibling Discount — second child' in the remarks column, signs, and hands the receipt over. By Friday the same accountant has done this thirty-eight times — thirty-eight manual discount calculations, thirty-eight remarks lines, thirty-eight chances to type ₹1,800 instead of ₹180. By April end, two parents have already called to argue: 'Last year my discount was 12%, why is it 10% this year?' Nobody can find the original 2024-25 policy document; the 2025-26 policy lives in the principal's WhatsApp.
The staff-ward case is worse. The school promises 50% off Tuition for children of teaching staff, 25% for non-teaching, 30% for the head clerk's son (a one-off arrangement made three years ago by a previous principal). The current accountant has all of this in a personal notebook — in pencil, with two erasures and a note that the driver's son's discount was 'temporarily suspended in October but now reinstated'. When the head clerk retires in March, the discount continues for one more month because nobody updates the notebook. When a CBSE inspector asks 'show me the staff discount policy with audit trail,' the principal has nothing to show.
Early payment discounts — the kind every smart Indian school wants to offer parents who pay full annual fees in April — don't exist at all in this office, because the staff cannot reliably compute 'paid 7 days before due date' on top of all the manual sibling and staff-ward maths. So the school loses cash flow advantage. Parents who would happily pay early get no incentive to do so. The school instead chases late payments with WhatsApp reminders and informal late fees — the exact opposite of what a healthy fee policy looks like.
The root problem isn't the discount math — it's that the discount policy lives in a notebook and applies one student at a time. Every month the office burns hours re-applying the same rules. Every audit and renewal finds inconsistencies. Every parent suspects favouritism. We built Inkwelly's discount system to fix exactly this.
How Inkwelly Discounts work — one catalog, three auto-rule engines
Inkwelly splits the discount system into a master catalog and three specialised auto-rule engines, all reachable from /student-fee/config. Discount Types (/discount-types) is the master catalog — every discount your school ever offers gets a row here, with its category, value, applicability, stacking and approval policy fully encoded. The three preset engines are simplified configurators that schools turn on with one form each: Sibling Discount Rules (/sibling-discounts) defines the discount by child position (2nd child, 3rd child, etc.); Staff Ward Discount Rules (/staff-ward-discounts) defines the discount by parent's staff category (TEACHING, NON_TEACHING, ADMIN, DRIVER); and Early Payment Discount Rules (/early-payment-discounts) defines the discount by days-before-due-date when payment is made.
Each of the three preset engines internally creates a Discount Type row with the appropriate category (SIBLING, STAFF_WARD or EARLY_PAYMENT) and isAutoApplied = true. So your school can run them all from the simplified screens, while everything still lives in the unified Discount Types catalog — making audits, reports and CBSE/State Board renewals trivial. Or you skip the preset engines entirely and configure every discount as a Discount Type manually — useful for unusual schemes (one-off Defense bursaries, named scholarships, alumni offers).
Discounts apply at the Fee Group level: every fee group on a fee structure has its own discount stack. So the 'Class 1 Sibling Discount' fee group carries the Sibling Discount Type; new admissions to that fee group inherit the discount automatically; their invoices show the discount line, with a discount-stack audit trail per receipt. RTE / EWS waivers, scholarship sanctions, individual approvals — all flow through the same catalog, so the school office runs one chart of discounts, not five separate workflows.
What you configure across these four screens
- 15 built-in discount categories — SIBLING, STAFF_WARD, MERIT, NEED_BASED, EARLY_PAYMENT, EWS, MINORITY, SINGLE_PARENT, ORPHAN, DEFENSE, GOVERNMENT_EMPLOYEE, ALUMNI, PROMOTIONAL, LOYALTY, CUSTOM. Reports and exports key off these enums; pick the right one and the right CBSE / RTE register populates automatically.
- Percentage or fixed amount — every discount is either a PERCENTAGE (0-100, validated server-side) or a FIXED_AMOUNT (any positive ₹ value). The form switches between a
%and a₹prefix on the value input so there is no ambiguity at save time. - Four applicability scopes — ALL_FEE_HEADS (apply across every head in the structure), TUITION_ONLY (only Tuition is reduced — typical for sibling and staff-ward discounts), SPECIFIC_FEE_HEADS (multi-select after creation), EXCLUDE_SPECIFIC (apply to all except listed). Stops the office from accidentally discounting Annual or Identity Card.
- Auto-applied vs manual — toggle
isAutoApplied = trueand the discount lands automatically based on its eligibility rule (sibling position, staff category, days-before-due, or RTE flag). Leave it off and the discount appears in a dropdown for manual selection at admission — useful for case-by-case awards. - Approval workflow with thresholds — turn
requiresApprovalON and the discount cannot be applied without a designated admin's tick. OptionalapprovalThreshold(₹) lets small discounts auto-pass while flagging big ones for review (e.g., approval needed only above ₹5,000). - Stacking with priority — most schools allow discounts to stack (sibling + early payment), but want a deterministic order.
isStackabledecides eligibility;stackPriority(lower number applied first) decides order. Inkwelly's stacking calculator respectsmaxStackableDiscountPercentfrom Fee Settings to cap absurd combinations. - Validity windows — every discount can carry a
validFromandvalidTodate. Useful for promotional offers (early-bird admission discount valid 1–30 April only), board-year-bound merit awards, or RTE quota years. - Sibling Rule by child position (2-10) — set the percentage per ordinal position. 2nd child 10%, 3rd child 15%, 4th child 20%. The form rejects child position 1 (the first child does not get a sibling discount) and blocks duplicate positions with
RESOURCE_ALREADY_EXISTS. - Staff Ward Rule by category — free-text staff category (2-100 chars: TEACHING, NON_TEACHING, ADMIN, SUPPORT, DRIVER, or your own labels). Different percentages per category — 50% for TEACHING, 25% for NON_TEACHING, etc. One rule per category, server-side enforced.
- Early Payment Rule by days-before-due — set the days-before-due-date threshold (1-365) and the percentage off. 30 days before due = 5% off, 7 days before due = 2% off. Multiple rules form a tiered curve. The system auto-detects qualifying receipts at payment time.
Walkthrough — four screens, end to end
Discount Types — the master catalog
The Discount Types screen at /student-fee/config/discount-types is your school's full discount policy on one screen. Every discount lives here — whether it's a routine sibling discount, an EWS waiver under the Right to Education Act 2009, a defence-personnel award, or a one-off promotional 'first 50 admissions get 5% off' campaign. Each row carries its category (15 built-in options), its value (percentage 0-100 or fixed ₹ amount), its applicability scope (all heads, tuition-only, or specific), and a full stack of policy switches — auto-applied, requires-approval, stackable, valid-from / valid-to dates, stack priority, and active flag.
The form is comprehensive but quick. Name (3-100 chars). Pick the category from the dropdown. Choose Percentage or Fixed Amount. Type the value — the input shows % or ₹ based on your choice, with server-side validation that percentage cannot exceed 100. Pick applicability — most sibling and staff-ward discounts use TUITION_ONLY (Indian parents expect non-tuition heads like Annual Picnic and Identity Card to stay full-priced). Set the validity window if it's a promotional offer. Toggle the four switches as needed. Save.
15 categories built for the Indian school reality
The category dropdown is not generic. It maps to the actual discount schemes Indian schools run. SIBLING — the routine 10/15/20% per second/third/fourth child. STAFF_WARD — children of teaching, non-teaching, admin, driver, security staff. MERIT — board-rank scholars, NTSE qualifiers, Class 10 toppers. NEED_BASED — income-criteria-based aid, often paired with a means-test process. EARLY_PAYMENT — incentive for paying full annual fees in April or paying X days before each installment due date. EWS — the 25% RTE quota academic-heads waiver under the Right to Education Act 2009. MINORITY — minority-institution-specific waivers under Article 30 of the Constitution. SINGLE_PARENT — partial waivers for single-parent families (typically 25-50% of Tuition).
ORPHAN — full or near-full waiver for orphan students, sometimes paired with a registered NGO partner. DEFENSE — children of defence personnel, especially relevant for schools near cantonment areas (Pune, Wellington, Mhow). GOVERNMENT_EMPLOYEE — children of central / state government employees, common in Tier-2 city day schools. ALUMNI — children or grandchildren of alumni — the loyalty discount that elite schools use to retain multi-generational families. PROMOTIONAL — first-50-admissions offers, board-affiliation-renewal celebrations, anniversary-year specials. LOYALTY — awarded after a student completes X years in the school. CUSTOM — any school-specific scheme that doesn't fit the above 14 — stored cleanly without forcing it into the wrong category.
Stacking, priority, approval thresholds — the policy controls real schools need
Indian schools rarely apply just one discount per student. A second-sibling Class 6 student whose mother is a teaching staff member — that is two discounts on the same Tuition: 10% sibling + 50% staff ward. Most school accountants either pick one (losing the parent's trust) or stack manually with no audit trail (losing the inspector's). Inkwelly handles stacking explicitly: every discount type carries isStackable and stackPriority fields. Stack priority is a number — lower applied first. So Sibling at priority 10, Staff Ward at priority 5, Early Payment at priority 20 means Staff Ward applies first, then Sibling, then Early Payment — all on the residual amount, in deterministic order, every time.
The school's Fee Settings carries maxStackableDiscountPercent — a sane upper cap (typically 75%) so the system can never silently produce a 100%-discounted invoice. Approval thresholds add a second guard. Set requiresApproval = true and the discount cannot be applied without a designated admin user clicking through. Set approvalThreshold = ₹5,000 and approval is needed only when the discount value exceeds ₹5,000 — small awards auto-pass, big ones get reviewed. Every approval, every rejection, every override is logged with user, timestamp and the discount stack snapshot at that moment — a defensible audit trail for the principal, the auditor and the parent committee.
Sibling Discount Rules — by child position, applied automatically
The Sibling Discount Rules screen at /student-fee/config/sibling-discounts is the simplest possible expression of a complex policy. One row per child position, ordinal 2 to 10. Position 2 = the second child enrolled from the same family; position 3 = the third; and so on. Each row carries the discount percentage (0-100) and an optional description. The form blocks position 1 with a clean error — 'Child position must be at least 2 (1st child doesn't get sibling discount)' — and blocks duplicate positions with RESOURCE_ALREADY_EXISTS.
Under the hood, the system uses the Student Information module's family graph to detect siblings. When a parent record is shared between two students (same father / mother / guardian), the system orders them by enrollment date, assigns ordinal positions, and matches against the Sibling Discount Rules table. If a rule exists for the matched ordinal, the corresponding Discount Type (auto-created with category=SIBLING, isAutoApplied=true) attaches to the student's Fee Group invoice. New admissions inherit the discount on day one. The first child stays at full price (no rule for position 1 by design). Existing students get re-evaluated on every fee structure change so a sibling-related move never silently drops a discount.
Staff Ward Discount Rules — by parent's staff category
The Staff Ward Discount Rules screen at /student-fee/config/staff-ward-discounts lets the school encode 'children of TEACHING staff get 50% off Tuition; NON_TEACHING get 25%; ADMIN get 30%; DRIVER get 20%' as four simple rows. The form takes a free-text staff category (2-100 chars), a discount percentage (0-100), and an optional description. Any duplicate category is blocked. The category strings are intentionally not enum-locked — different schools call their staff categories different things (some use HEAD_OFFICE / FIELD; some use ACADEMIC / NON_ACADEMIC) and the form respects that.
The matching engine reads from the Employee Information module. When a student's parent record links to an active employee record, the employee's department / category field is matched (case-insensitive, trim-tolerant) against your Staff Ward rules. A match attaches the corresponding Discount Type to the student's Fee Group, applied to TUITION_ONLY by default (overridable per discount type). When a parent leaves the school's employment, the discount auto-revokes from the next invoice cycle — a one-line, dated record in the audit log explaining why. No more 'driver's son's discount continued for one month after retirement' notebook problems.
Early Payment Discount Rules — by days-before-due-date
The Early Payment Discount Rules screen at /student-fee/config/early-payment-discounts lets the school turn early payments into a real cash flow advantage. One row per tier: 30 days before due = 5% off, 15 days before due = 3% off, 7 days before due = 2% off. The form takes the days-before-due-date threshold (1-365, validated server-side) and the discount percentage (0-100). Each tier is unique by days; the more tiers you create, the smoother the discount curve.
At payment time, when the office processes a Razorpay, UPI or cheque payment, the system computes the days remaining until the installment's due date and matches against the Early Payment Rules table. The biggest qualifying tier wins (paying 30 days early gets the 30-day rate, not the 7-day rate). The receipt shows the discount line transparently, the corresponding Discount Type entry is recorded with EARLY_PAYMENT category and isAutoApplied=true, and the audit log carries the exact daysBeforeDue count and the rule that triggered. Schools that turn this on typically see April collections jump 20-35% as parents respond to the visible incentive.
“Pehle har sibling, har staff ward discount manually receipt pe likhna padta tha. April mein 38 admissions — 38 baar manual maths, 4-5 typing mistakes, do parents shikayat le ke aate the. Ab Inkwelly mein hum Sibling Rules aur Staff Ward Rules ek baar set kiya April ke pehle hafte mein. Pehle din se 100% admissions ka discount automatic. Inspector ne CBSE renewal ke time poora discount register print kara liya audit trail ke saath — 5 minute mein clean. Saala Saturday wapas hamara hai.”
Real-world setup playbooks for Indian schools
Five worked examples drawn from real Indian school migrations to Inkwelly:
1. CBSE day school (Class 1-12, ~600 students), Indore. Discount Types: 9 entries — Sibling (3 ordinals), Staff Ward (3 categories), Early Payment (3 tiers), Merit (Class 10 board top 3), EWS (RTE quota), Defense (cantonment-area students), Single Parent. All sibling and staff-ward applied to TUITION_ONLY. Stacking ON with priorities Staff Ward (5) > Sibling (10) > Early Payment (20). maxStackableDiscountPercent capped at 70% in Fee Settings. Setup time: 90 minutes including a CA review of the merit and EWS rules.
2. ICSE residential school (Class 6-12, ~250 boarders), Dehradun. Discount Types: 7 entries — Sibling (2 ordinals at 5% and 10%, lower than CBSE day schools because base fees are 5x higher), Staff Ward (TEACHING 40%, NON_TEACHING 20%, ADMIN 25%, only for day-scholar children of staff — boarding charges separate), Need Based (means-tested, requiresApproval=true with a ₹50,000 threshold). Alumni (10% for grandchildren of alumni, validated against legacy registry). Setup time: 4 hours including the bursar's review.
3. State Board low-fee private school (Class 1-8, ~400 students), Bahraich, UP. Discount Types: 4 entries — Sibling (2 ordinals), Staff Ward (one rule for all staff at 30%), EWS / RTE Quota (full academic-heads waiver), Single Parent (50% Tuition). No early payment scheme — parents pay quarterly on time. Setup time: 35 minutes.
4. International school (Pre-K to Grade 12, ~700 students, IB + Cambridge IGCSE), Bangalore. Discount Types: 14 entries — Sibling (4 ordinals at 5/10/15/20%), Staff Ward (4 categories), Early Payment (4 tiers up to 7% for full-year-paid-in-April), Merit (IB-DP top scorers, IGCSE 8A* students), Defense, Government Employee, NRI Loyalty (3-year retention), Alumni, Promotional ('5% off first 50 admissions of academic year 2026-27'). Heavy use of validity windows. Setup time: 6 hours over 2 sittings with the school CFO.
5. Madrasa / minority institution (Class 1-10, ~180 students), Hyderabad. Discount Types: 5 entries — Sibling (2 ordinals), Staff Ward (single category at 40%), MINORITY (full waiver of Religious Studies Fund for orphans), ORPHAN (full Tuition waiver under wakf board scheme), CUSTOM (annual Ramadan stipend). Setup time: 25 minutes.
Common operations across the four discount screens
- Set up an entire session's discount policy in 90 minutes — Discount Types catalog + Sibling Rules + Staff Ward Rules + Early Payment Rules — once at session start, every invoice for the next 12 months honours it.
- Bulk-apply a sibling discount to every existing family with multiple students — a one-click backfill scans the Student Information family graph, assigns ordinal positions, and creates discount records for each match.
- Audit the school's full discount policy before a CBSE renewal, ICSE inspection, or RTE state-government reimbursement filing — print the Discount Types catalog as a one-page register with category, value, applicability, stack priority and validity dates.
- Run RTE 25% quota discounts through the EWS category with TUITION_ONLY applicability and validity dates aligned to the academic session — every RTE-tagged student in the RTE register is auto-discounted and the state-reimbursement claim file generates from the same data.
- Promote an early-bird discount for the first 30 days of admission window — create a PROMOTIONAL discount type with validFrom = April 1, validTo = April 30, isAutoApplied = true, applicability = TUITION_ONLY — all April admissions get the discount, May admissions don't.
- Approve high-value discounts via workflow — set
requiresApproval = trueandapprovalThreshold = ₹5,000on Need Based / Defense discounts — small grants auto-pass, big ones go to a designated admin's approval queue with a clean log. - Switch off a stale promotional discount mid-session — set
isActive = falseon the row, and from that moment new admissions don't get it; existing students who already received it keep their snapshot — receipts are immutable. - Detect employed-parent change — when a staff member exits via Employee Trash or marks inactive, the auto-rule revokes the matching staff-ward discount on the next invoice cycle, with an audit-log entry naming the cause.
- Configure Class 11/12 stream-specific merit awards — create separate Discount Types for 'Class 12 Science Top 3' vs 'Class 12 Commerce Top 3' with SPECIFIC_FEE_HEADS applicability targeting Practical Fee or Stream Fee.
- Roll-over discounts to the new academic session — active discount types remain as configured; only the validity windows need refreshing if your scheme is session-bound. The Sibling, Staff Ward and Early Payment rules transfer 1-to-1 with no reconfiguration.
See your discount policy run automatically, in 30 minutes
Bring your existing notebook / Excel of sibling, staff ward, EWS, merit and early-payment rules. We'll model your full discount policy inside Inkwelly during the demo — Discount Types catalog plus the three preset auto-rules — and run a sample admission live to show every rule firing on the right student.
Limits, safety and the small print
Stacking is bounded by Fee Settings. The school's maxStackableDiscountPercent (set in Fee Settings, default 75%) is the hard ceiling for combined discounts on any single fee head. Inkwelly's stacking calculator runs the discounts in stack-priority order on the residual amount, then checks the cap. If the combined effective discount would exceed the cap, the smallest-priority discount truncates to fit — with a clear log entry on the receipt. No silent zero-rupee invoices, ever.
Auto-applied discounts revoke automatically when eligibility changes. When a sibling withdraws, the second child returns to position 1 and the sibling discount auto-revokes from the next invoice. When a staff member exits, their child's staff-ward discount auto-revokes. When a validity window closes, promotional discounts stop applying to new admissions. Every revoke has an audit log entry naming the cause — 'Sibling rule no longer matches: family graph changed on 2026-09-12'.
Past receipts are immutable. Editing or revoking a discount today does not change historical receipts. The receipt issued in April that included a 10% sibling discount stays exactly as printed, even if the sibling rule is later edited to 12%. The audit log carries the full snapshot. This is by design — receipts are legal financial records, not editable rows.
Approval-required discounts cannot bypass. When requiresApproval = true, the discount appears as 'pending' on the student's invoice and does not reduce the amount due until a designated admin approves. The pending state is visible to the parent on their portal so there is no confusion. Rejected discounts emit a separate audit log entry with the rejection reason. No discount can ever apply silently without explicit policy + role-based authorisation.
Server-side validation matches the form. Percentage 0-100, fixed amount positive, child position 2-10, days-before-due 1-365, staff category 2-100 chars. Duplicate categories, duplicate child positions, duplicate days-before-due all return clean RESOURCE_ALREADY_EXISTS errors. Discount type names are unique per school (3-100 chars). The frontend dialog and the backend API both validate — no malformed discount slips through.
Multi-tenant isolation. Each school in a multi-school trust runs an independent discount catalog. School A's 'Sibling Discount 10%' is invisible to School B even within the same parent organisation. Discount-type templates can be cloned across schools (the API supports a clone-discount-type action) but live discount records stay scoped to their school. Trust-level dashboards roll up by school for revenue analysis.
DPDP Act 2023 alignment. Discount Types and the three rule engines themselves contain no personally identifiable parent or student data — only policy metadata. PII appears only when the rules match a specific Student Fee Profile and a discount line emits on an invoice. All Inkwelly data is hosted on Mumbai region servers, encrypted at rest with AES-256, and accessible only via role-based permissions configured in Identity & Access Management. Audit log entries record every discount creation, edit, application, approval, rejection and revocation — with user, timestamp and the discount stack at that moment — keeping the discount trail defensible during CBSE / ICSE / Income Tax / RTE / Labour Department inspections.
Belongs to
1 moduleFrequently asked
10 questionsWe use a notebook for sibling and staff ward discounts. Why move to Inkwelly's system?
Three reasons. First, **automation** — set the rule once at session start, every admission for the next 12 months has the right discount applied automatically, without manual re-application on each receipt. Second, **audit trail** — every discount creation, edit, application and revocation is logged with user, timestamp and the full discount stack, defensible during a CBSE renewal, RTE state-reimbursement filing, or parent-committee dispute. Third, **stacking** — when a second-sibling student is also a staff member's child, the system stacks both discounts in deterministic priority order, capped by your school's stack ceiling — not by whoever is on the fee counter that day. Schools that move from notebook to Inkwelly typically save 10-15 hours/month for the accounts office and resolve 90% of parent discount disputes in seconds, not days.
How does the sibling discount rule actually detect siblings?
Through the [Student Information module's family graph](/modules/student-information). When a parent record (father, mother, or guardian) is shared between two or more student records, those students are siblings of the same family. Inkwelly orders them by their enrollment date, assigns ordinal positions (1st, 2nd, 3rd, etc.), and matches against your Sibling Discount Rules table. Position 1 (the first / oldest enrolled child) never gets a sibling discount by design — the system blocks position 1 in the form. Positions 2-10 each carry their configured percentage. The match runs on every admission, every fee structure recalculation, and every family-graph change — so a sibling-related move never silently drops a discount.
Can we set different discounts for different staff categories?
Yes — that is the entire design of the Staff Ward Discount Rules screen. Each row is one staff category (free-text, 2-100 chars: TEACHING, NON_TEACHING, ADMIN, SUPPORT, DRIVER, or whatever labels your school uses) plus its discount percentage. So you can encode 'TEACHING 50%, NON_TEACHING 25%, ADMIN 30%, DRIVER 20%' as four rows. The matching engine reads the parent's employee record from [Employee Information](/modules/employee-information) and applies the rule for the matched category. One staff member, one student, one rule — deterministic, audit-logged.
What happens when a staff member leaves the school? Does their child's discount continue?
No — the auto-rule revokes the staff-ward discount on the next invoice cycle when the parent's employee record is marked inactive (via [Employee Trash](/features/employee-trash-restore) or the active toggle in Employee Information). The audit log records the revocation with the cause: 'Staff Ward rule no longer matches: parent employment ended on 2026-09-30'. The student's invoice from October onwards reflects full Tuition. Past receipts that included the discount are immutable — they stay exactly as issued. The school office never has to manually find-and-remove the discount, and parents see the change clearly with a notice line on the new invoice.
Can we offer multiple early-payment discount tiers — say, 5% if paid 30 days early and 2% if paid 7 days early?
Yes — that's the standard configuration. The Early Payment Discount Rules screen accepts one row per `daysBeforeDue` threshold (1-365). Add as many tiers as the school wants — 30 days = 5%, 21 days = 4%, 14 days = 3%, 7 days = 2%, 1 day = 1%. At payment time, the system computes the actual days-remaining-until-due, matches against your rules table, and the **biggest qualifying tier wins** — paying 30 days early gets the 30-day rate, not the 7-day rate. The receipt shows the qualifying tier transparently. Most schools that turn this on see April-month collections jump 20-35% because parents respond to the visible incentive of paying the full annual fee in the first month.
How does discount stacking work when one student qualifies for sibling AND staff-ward AND early-payment?
All three apply, in deterministic stack-priority order. Each discount type has a `stackPriority` field (an integer; lower applies first). The system sorts the eligible discounts by priority, applies them sequentially on the residual amount, and respects your school's `maxStackableDiscountPercent` cap from [Fee Settings](/modules/student-fee) (default 75%). So a Class 6 student who is the 2nd sibling AND the daughter of a TEACHING staff member AND pays 30 days early might get: Staff Ward 50% (priority 5, applied first — reduces ₹20,000 Tuition to ₹10,000) + Sibling 10% (priority 10, applied next — reduces ₹10,000 to ₹9,000) + Early Payment 5% (priority 20, applied last — reduces ₹9,000 to ₹8,550). The receipt shows all three lines clearly. If combined would have exceeded the 75% cap, the smallest-priority discount truncates to fit — with a transparent log entry.
How do we handle RTE 25% reservation and EWS waivers through this system?
Use the EWS category with TUITION_ONLY or SPECIFIC_FEE_HEADS applicability (matching the academic-heads waiver mandated under the [Right to Education Act 2009](https://en.wikipedia.org/wiki/Right_of_Children_to_Free_and_Compulsory_Education_Act,_2009)). Set the validity window to align with the academic session. Mark `isAutoApplied = true`. RTE-tagged students from the [Student Information module](/modules/student-information) are matched against the discount type and the waiver line emits on every invoice. The [RTE register](/school/dps/delhi/2026-27/student-fee/rte) auto-pulls all RTE-tagged students with their waiver amounts and the audit-stamped discount lines — ready for state-government reimbursement filings without re-keying anything.
Can we require admin approval for big discounts before they apply?
Yes — set `requiresApproval = true` on the relevant Discount Type. Optionally set `approvalThreshold` (₹ amount above which approval is needed) so small awards auto-pass while big ones go to review. When the rule matches a student, the discount appears as 'pending' on their invoice — visible to the parent on their portal but not yet reducing the amount due. A designated admin (with the right [IAM role](/modules/identity-access-management)) reviews the queue and approves or rejects. Every action is audit-logged. Common configuration: routine sibling and staff-ward discounts auto-apply (no approval); Need Based, Defense, Single Parent and one-off CUSTOM discounts require approval over ₹5,000.
What happens to a student's discount when they move to a different fee group?
Auto-applied discounts re-evaluate against the new fee group automatically. So when a Class 5 sibling student gets promoted to Class 6 in April, their fee group changes from 'Class 5 Sibling Discount' to 'Class 6 Sibling Discount', and the matching Sibling Discount Rule re-applies on the new fee structure's amounts. The audit log records the move with timestamp and the resulting discount-stack snapshot. Manual / approval-required discounts stay attached to the student until explicitly removed — they don't auto-transfer based on fee group change, by design, since they typically reflect case-specific awards.
Who in our school office should configure the discount catalog and rules?
The accounts officer or finance manager, in consultation with the principal who signs off on the year's discount policy. CBSE / State Board / ICSE day schools (8-12 discount types) typically complete setup in one Saturday morning. International / IB / Cambridge schools (12-20 discount types with multiple tiers) take 2-4 hours, often with the CFO involved. Daily users — admission desk, fee counter, class teacher — never see the configuration screens unless adding a new one-off discount. [Identity & Access Management](/modules/identity-access-management) restricts edit rights to accounts and admin roles only; the approval workflow can be delegated to a separate role for separation-of-duties.
You might also like
2 readsSee Inkwelly on your school
30-minute demo. We open your current ERP with you and load your data into Inkwelly on the call. Dated go-live plan by the end of it.