01
Receipt numbers are allocated by the database, not the browser
The number is assigned when the payment is inserted, on the server, not counted up in whichever tab happened to be open.
An insert trigger on the payments table assigns the number.
Fee management
Fee collection your accountant cannot argue with.
Fee management is the strongest thing RaivatEdu does. Five tabs cover the whole cycle: what you charge, what a student owes, what has come in, and who you still need to chase. Underneath it, the rules that matter are enforced by the database rather than the screen.
What this covers
- 1The price list, per course and per batchFee structures per course
- 2Instalments and part paymentsInstalment plans with due dates
- 3Adjustments, recorded rather than overwrittenDiscounts
- 4Dues, ageing and the chase listAgeing buckets
In short
What does fee management do in RaivatEdu?
RaivatEdu handles institute fees across five connected tabs: an overview of collections and dues, fee structures per course with batch-level overrides, per-student fee plans, payments with receipts, and a collection cockpit for the chase list. Receipt numbers are allocated server-side and are unique per institute, a written receipt cannot be rewritten, and editing your price list never re-prices a student who already holds a quote.
- tabs, one workspace
- 5
- fee tables with tenant isolation
- 8
- receipt numbering
- Server-side
What fee management does today.
Every line here is a feature that exists in the product right now. Anything still being built is listed further down, on the same page.
01
The price list, per course and per batch
Build a fee structure for a course, then override it for a specific batch when the evening cohort is priced differently from the morning one. One structure is the default per course, and the override is explicit.
- Fee structures per course
- Batch-level overrides
- Line-item breakdown: tuition, material, exam, anything you charge for
- Import your existing structure from a spreadsheet
02
Instalments and part payments
Set an instalment plan with due dates, including recurring plans for programmes that bill every term. When a family pays part of what is owed, the money is allocated across instalments rather than dumped against a single total.
- Instalment plans with due dates
- Recurring plan types
- Part payments allocated across instalments
- Invoice due dates carried through
03
Adjustments, recorded rather than overwritten
A sibling discount, a scholarship or a correction is stored as an adjustment against the plan. The original breakdown stays visible, so a year later you can still see what was charged and what was given.
- Discounts
- Scholarships
- Corrections
- Full adjustment history on the plan
04
Dues, ageing and the chase list
The collection cockpit is the screen a front office actually works from. Outstanding amounts sit in ageing buckets, and each plan carries its own dues panel, so a counsellor knows who to call before the term ends.
- Ageing buckets
- Per-plan dues panel
- Collection workflow
- Assign a fee plan to many students at once
Enforced, not promised
Six rules the database keeps for you.
These are enforced where the data lives, not in the screen that shows it. An interface check protects the interface. A database rule protects the money.
- 02
Two receipts can never share a number
A browser-side counter was tried first and produced duplicates. It was replaced with a constraint that makes a duplicate impossible rather than unlikely.
A unique index on institute plus receipt number.
- 03
A written receipt cannot be rewritten
Once a payment is recorded, its receipt number and its amount are fixed. Nobody can quietly edit yesterday's collection to match today's cash drawer.
A trigger blocks any update that would change the number or the amount.
- 04
Editing your price list never re-prices an existing student
Raise your fees mid-year and the students who already hold a quote keep the breakdown they were quoted. Their plan is a frozen snapshot, not a live lookup into the current price list. Re-syncing a plan is something a person chooses to do.
Plan items are a stored snapshot with deliberately no link back to the live line items.
- 05
A student who has paid is frozen
You cannot re-apply a fee structure to a plan that already carries a payment, because the student is holding a receipt for the breakdown they were quoted.
The re-apply check refuses any plan with a non-voided payment.
- 06
One live fee plan per student, one default structure per course
The shapes that cause double-billing are prevented rather than detected later.
Partial unique indexes on the plan, the course default and the batch override.
Where this stops
What fee management does not do.
We would rather you read this before you buy than discover it in week two. If something here is a requirement for you, tell us and we’ll be straight about the timeline.
Ask us about a gap- Receipt numbers are issued and stored, but the receipt is not produced as a downloadable file today.
- Fees carry no tax column, so the fee breakdown is not split by tax head.
- Reminders to guardians are not something we claim: the delivery path is a known defect and is being fixed before it goes on this page.
FAQ
Fee Management, answered plainly.
Yes. A course carries a default fee structure and any batch can override it. Only one default per course and one override per batch are allowed, which is what stops two conflicting prices existing for the same batch.
Nothing. A student fee plan is a stored snapshot of the breakdown they were quoted, with no live link to your current price list. Raising the price list affects new plans only. Re-applying a structure to an existing plan is a deliberate action, and it is refused outright if that student has already paid anything.
No. The number is assigned by the database when the payment is inserted, and a unique index on institute plus receipt number makes a duplicate impossible. An earlier version counted receipt numbers in the browser and did produce duplicates, which is exactly why it was moved server-side.
The receipt number and the amount cannot be changed after the payment is recorded, and a trigger rejects any update that tries. Corrections are made as adjustments against the plan, which leaves both the original and the correction visible.
The payment is allocated across instalments rather than applied to one running total, so you can see which instalment is settled, which is partly paid and which is still open.
Yes. Fee structures and fee plans both import from a spreadsheet, and a plan can be assigned to many students in one action rather than one at a time.
No. A discount, scholarship or correction is stored as an adjustment against the plan, so the quoted breakdown and the concession are both on the record.
Next in the product
- Students & BatchesOne record per learner, documents attached, and batches with real seat limits.
- Enrolment & RenewalsEnrol onto a batch, then price it — plus renewal rules you set once.
- ReportsCollections, dues and education KPIs you can click through to the list.
Your next student is already looking for you.
Give your admissions team one place to capture, connect and convert every opportunity.
Rather talk it through? Request a callback or talk to sales.
- 30-minute walkthrough
- Your workflow, not a script
- No card required