← Gurukul

Gurukul Platform — School Operations

What It Takes to Run a School

Six features that handle fees, payroll, and infrastructure spending inside Gurukul — what each of the four roles can actually do in each one, exactly how the flow runs, and what's still manual or switched off.

Across these six features, Admin is the only role with full reach today. Teachers see one slice — their own class's fee status. Students and parents can see, but currently can't act on, their own fee bill. Pick a role above to see exactly what's theirs.

Fees

Fee Structure Setup & Bill Generation

Admin Teacher Student Parent

Define what students in a class owe — categories like tuition or transport, bundled into a per-section fee structure — then generate every student's individual bill in one tap.

  1. Create fee categories once per school (Tuition, Transport, Lab, etc.).
  2. Build a fee structure for one class-section and academic year: a bundle of categories, each with an amount.
  3. Tap Generate Assessments to create a bill for every currently active student in that section.
  4. Students admitted later are billed automatically the moment they're placed in a section that already has a structure — no need to re-run generation.
What happens if you generate twice

Nothing breaks — re-running generation never duplicates a student's bill or changes an existing one. But it also means editing a fee amount after bills already exist won't reach any student who was already billed; only new students get the new number.

Worth knowing: nothing at the server currently restricts who can create categories, build structures, or trigger bulk billing for a whole class — this relies entirely on only Admin having these screens in the app. Structures also can't be edited or deleted once created, so a wrong amount means setting up a fresh structure rather than correcting the old one.

Recording Fee Payments

Admin Teacher Student Parent

Every fee payment on the books today is entered by staff after the money has already changed hands. A self-service online option was built for students and parents — it's just not switched on.

Live today

  1. Staff collects payment in person — cash, cheque, or a bank/UPI transfer completed outside the app.
  2. Staff enters the amount against the student's bill.
  3. The bill's paid amount and status update immediately, and a receipt number is generated.
On hold

Built, not switched on

  1. Student or parent would tap Pay Fees.
  2. The app would open their UPI app with the amount pre-filled.
  3. They pay (or cancel) outside the app, then return and confirm what happened.
  4. The app takes their word for it — there's no independent confirmation from a payment gateway.
Why it's paused

The online path is a direct link into a UPI app rather than a connection to a real payment gateway, so the only signal that a payment succeeded is the payer's own self-reported answer to "did it work?" That wasn't reliable enough to trust with real money, so the button was switched off in favor of the staff-recorded flow above. The screens and backend logic for it are still fully built and sitting in the codebase, ready to be reconnected once a proper payment gateway is in place.

Worth knowing: there's no way to void or correct a payment once it's recorded, and no refund flow for either path.

Fees Overview & My Class Fees

Admin Teacher Student Parent

Two windows onto the same bills: Admin sees every student's fee status school-wide; a homeroom teacher sees only their own section.

Admin — whole school

  • Dashboard → Fees → Fee Assessments
  • Every student in the school, with search and status filters (Unpaid / Partial / Overdue / Paid)
  • A summary card totals unpaid students and unpaid amount

Teacher — own section only

  • Dashboard → "My Class Fees" tile (only appears for a homeroom teacher)
  • Just that one section's students — asking for another section is refused
  • A simpler summary: how many are paid up, how much is still owed

Worth knowing: a bill only flips to "Overdue" once a payment has been made against it. A bill that's never been paid at all stays marked "Unpaid" even long after its due date has passed, even though the amount owed shown is always current.

Payroll

Salary Structures & Payroll Runs

Admin Teacher Student Parent

Set each employee's pay components once, then run payroll for a month in three steps: create the run, process it, pay it.

Draft Run created for one month — nothing calculated yet
Processed Pay calculated for every active employee from their current salary structure
Paid Money recorded as sent; payslips issued
How pay is actually calculated

Each employee has a salary structure: a basic amount, allowances, and a deductions amount. Processing a run adds basic + allowances for gross pay, then subtracts deductions for net pay — for whichever salary structure was effective as of that month, for every active employee.

Worth knowing: "deductions" is a single number entered manually per employee — there's no built-in provident fund, ESI, professional tax, or income-tax withholding calculation. A school that owes any of those still has to work out the number itself and enter it as one lump deduction.

Payroll Overview

Admin Teacher Student Parent

A school-wide dashboard of how much payroll has gone out and how much is still pending, rolled up across every pay run.

Example: two runs

  • January run — status Paid → every employee in it counts as paid
  • February run — status Processed → every employee in it counts as pending, even the ones already individually paid

What the overview adds up

  • Employees paid, and the total amount, from every run marked Paid
  • Employees pending, and the total amount, from every run not yet marked Paid

Worth knowing: the paid/pending split is counted per pay run, not per employee. The moment a run is marked Paid, everyone in it counts as paid in this overview — there's no in-between state where some employees in the same run show paid and others don't.

Infrastructure

Infrastructure Expenses

Admin Teacher Student Parent

A four-stage paper trail for school infrastructure spending: request it, approve or reject it, record what was actually bought, then pay the vendor.

Draft Request written up with a category and estimated cost
Submitted Sent for a decision
Approved Cleared to buy
Purchased Vendor and invoice recorded, with the real amount spent
Paid Vendor paid; posted to the school ledger
If it's rejected

A rejected request can be edited and resubmitted, restarting from Submitted — it isn't a dead end. There's no separate "cancel" action, though, and no way to revise the estimate without going through resubmission.

Worth knowing: every step here — requesting, approving, rejecting, recording a purchase, paying a vendor — is currently open to any logged-in user, not just admins; the app only steers admins toward these screens. The "who approved this" record is also just a typed name today, not tied to a verified login.

One ledger underneath

Fees collected, salaries paid, and vendors paid all land in the same underlying financial ledger — giving the school one unified transaction record across all three domains, even though each one is set up and approved through its own workflow above.