Do you support multiple academic years and year-end promotion?

Yes. Academic year is a first-class field on every enrollment, fee structure, exam, and attendance row. Year-end promotion is a bulk section-level action that creates new enrollment rows for the next year without disturbing prior-year history. Repeating students are handled individually. Fee structures attached to the next academic year apply automatically as soon as the promotion is committed.

Do you support biometric attendance devices?

JEduManage's attendance flow today is class-teacher marking from the section roster — designed for the way most Indian schools actually run their morning routine. Biometric and RFID integrations are scoped on a per-deployment basis; the underlying attendance model already records timestamp, marker identity, and audit metadata, so a device integration writes into the same table the teacher portal does. Talk to us if a specific device is a hard requirement for your school.

Do parents and teachers each get their own login?

Yes. Parents sign in by phone number; staff (admins, teachers, accountants) sign in by email. Routing the two identity spaces separately means the same phone number can legitimately belong to a teacher AND a parent without portal ambiguity — a common case in schools where staff children study in the same school. Each role only sees what their permission set allows: parents see their own children, teachers see their assigned classes, admins see the whole tenant.

Can I customise SMS templates and grade bands per school?

Yes. SMS templates for OTP, admission welcome, holiday, fee due, absentee, and principal welcome are configured per tenant against the school's DLT-registered entity, then sent through MSG91. Grade bands (the score ranges that map to grades like A+, A, B and the corresponding grade points) are also per-tenant — your school's grading philosophy is honoured in the report card without code changes.

How does the system handle students who use the school bus?

Bus routes are a per-tenant catalogue separate from the class-wise fee structure. At admission time the form has a 'uses school transport' checkbox; ticking it lets the admin pick a route, and the route's current fee is snapshotted onto the student. The parent fee breakdown shows the transport line distinctly from tuition, so families always see what they're paying for. Students not using the bus aren't billed for it.

Is everything an admin does recorded somewhere?

Yes. Every administrative write — admission, transfer, withdrawal, fee adjustment, fee structure change, route assignment, role change, user creation, user delete, branding upload — produces an immutable audit row with the actor, timestamp, old value, and new value. The audit log is queryable by date, module, and student, which means an investigation can be answered from the panel instead of by asking everyone what happened.

All Features | JEduManage School Management Software

This page is the index. Every feature JEduManage ships with is described below, grouped by the school workflow it lives inside. If a capability isn't listed here, it isn't in the product yet — we'd rather be specific than make promises. Each section also links to the deeper solution page for that area, so you can drill into the parts that matter most to your evaluation.

A note on how to read this page. The product is organised around school workflows, not around generic ERP primitives, so the sections below mirror the conversations that actually happen in a principal's office: how do we admit a student, how do we mark attendance, how do we run an exam, how do we collect fees, how do we talk to parents. Within each section the prose explains the design intent; the bullet list under it enumerates the concrete capabilities you'd otherwise have to discover by clicking around a demo tenant.

Student information

The student record is the foundation everything else builds on. Admissions create an immutable admission number, link a parent user by phone, and set the student's initial enrollment in one dialog — the parent account is provisioned in the same transaction so there's no follow-up "create login" step. Enrollment evolves across the year through transfers and at year-end through bulk promotion, and prior-year rows are preserved for archival reads. The full deep dive lives on the student information system page; the capability list:

Admission flow with admission number, identity fields, class + section + roll, parent linkage, optional fee structure and bus route — one dialog, one transaction
Sibling-aware parent linkage — an existing parent record is reused when a second child is admitted under the same phone number
Parent-student relation (father, mother, guardian) and primary-parent flag stored per link
Mid-year transfer between sections or classes without orphaning attendance, fee, or exam history
Soft-delete withdrawal that preserves the record for reporting and audit, with single-action re-admission
Year-end bulk promotion at the section level, with per-student repeat handling
CSV bulk import with per-row validation and per-row error reporting — partial imports never write inconsistent state
Per-tenant uniqueness enforcement on admission numbers so the same admission ID cannot be reused inside a school

Daily attendance

Attendance is the single most repeated administrative action in a school. The flow is built to be fast: the class teacher opens today's section roster, taps through Present / Absent / Late, and the parents of absent students get an SMS automatically. The calendar is holiday-aware so weekends and declared holidays don't pollute the absentee count. The attendance management page covers the daily rhythm in more depth; the feature list:

Section-based marking — the teacher sees only the students enrolled in their section for the current date
Per-student status: Present, Absent, Late, with optional remark
Holiday-aware calendar — declared holidays and weekends are excluded from absentee triggers and percentage calculations
Absentee SMS delivered the same morning, with each parent receiving a templated message naming their child specifically
Audited mark and re-mark — every change records who edited what and when, so disputes are resolved from the log
Parent-visible attendance calendar showing each day for each child
Section-level and student-level attendance percentage rollups for report cards

Exams and grading

Exam workflows in JEduManage cover the path from "we are planning a unit test" to "the parent has downloaded the report card." Exams are scheduled per class with subject-wise components. Subject teachers see their grading sheets scoped to their assignments. The grade band table is per tenant — your school's A+ might be 91 and above while another school's is 95 and above, and the report card respects whichever you've configured.

Report card generation is a PDF render with the school logo and name in the header, the student's identity, the subject-wise marks and grades, the calculated aggregate, and the attendance percentage pulled from the same daily attendance table the class teacher fills in. There is no separate report-card data entry — the inputs already exist as a by-product of the regular term's work.

Exam scheduling per class with subject-wise components and maximum marks
Subject-wise grading sheets that the assigned teacher fills in for only their subject and section
Configurable grade bands per tenant — score ranges, grade letters, and grade points are school-specific
Automatic grade calculation from raw marks using the configured bands
Per-student report card generation as a downloadable PDF, with the school logo and name in the header
Parent-side report card download from the parent portal once results are published
Aggregate views for the admin and class teacher to spot subject-wide outliers before publication

Fee management

Fees are where most school software gets sloppy. JEduManage treats fees as a per (class + academic year) structure with named line items, then layers per-student adjustments on top for discounts, scholarships, and waivers. Transport is deliberately separate so students who don't use the bus aren't billed for it. Payments are recorded as they come in — cash at the counter, bank transfer, or online — with the receipt surfaced to parents. The fee management page goes into the model in depth; the capability list:

A subtle but important property of the fee model: the parent's breakdown is literally the same query the admin's breakdown uses, with a tenant- and student-scoped filter. There is no parallel "parent view" of fees that can drift from the office's view. When the accountant records a payment, the parent's outstanding balance reflects it on next page load — no nightly sync, no manual receipt photograph.

Per (class + academic year) fee structures with named line items (tuition, exam, lab, etc.)
Bulk-assign a structure to every student in a class, then override per student where needed
Per-student adjustments — discount, waiver, ad-hoc charge — stored alongside the base structure for a clean audit
Bus route fee snapshot per student — the route is opt-in and shown as a separate line in the breakdown
Payment recording for cash, transfer, and online channels with mode-tagged receipt numbers
Parent fee breakdown showing structure lines, adjustments, transport, payments, and balance — the same numbers the admin sees
Fee-due SMS reminders via MSG91 with the parent's specific outstanding amount
Tenant-level fee collection reports filtered by class, date range, and mode

Bus route management

School transport is its own administrative surface — routes, stops, drivers, fees — and JEduManage models it as a per-tenant catalogue rather than bolting it onto the fee structure. Admins maintain the route list once; at admission time a tick on "uses school transport" reveals the route picker, and the route's current fee is snapshotted onto the student. If the route fee is later revised, existing students keep their original snapshot until you choose to re-snapshot them.

Per-tenant route catalogue with route name, description, and current monthly fee
CRUD page in the admin portal scoped to administrators
"Uses school transport" checkbox on the admission and edit dialogs that reveals the route picker
Fee snapshot per student so historical billing stays stable even when the catalogue fee is updated
Transport line surfaces distinctly in both the admin fee breakdown and the parent fee breakdown
Audit trail on route creation, fee revision, and per-student route assignment changes

Communications and SMS

Schools talk to parents constantly, and most of that talk in India happens over SMS. JEduManage integrates with MSG91 to deliver DLT-compliant transactional and informational SMS, with templates registered against your school's DLT entity. Every outbound message is recorded in a per-school SMS log tagged by category, so a complaint about a duplicate or missing message is resolved by opening the log instead of chasing logs at the provider.

DLT compliance matters in India. JEduManage's SMS pipeline is built around it: each template you use has an entity ID and a template ID registered against your school's DLT account, the sender ID is yours rather than a shared pool, and the per-school log makes regulator queries answerable from the same screen the office uses for routine investigations.

DLT-compliant integration with MSG91 — your school's templates and sender ID, not a shared one
OTP delivery for login flows where applicable
Admission welcome SMS sent automatically when a new student is admitted
Principal / admin welcome SMS when a new staff user is created
Holiday announcement SMS with a preview-and-confirm step before any messages leave
Fee-due reminders parameterised with the parent's outstanding amount and the student's name
Absentee SMS triggered from the attendance flow, naming the child and the date
Per-school SMS log with category, recipient, rendered template, MSG91 request ID, and delivery outcome
Bulk SMS dry-run preview showing recipient count and the exact template before send

Parent portal

The parent portal is intentionally narrow. Parents see their own children — listed together if there are multiple — and for each child they get the academic and financial views they actually need. No marketing surface, no extra modules, no features that don't apply to a parent's day-to-day. Phone number is the login identity, so families don't need to remember a new credential.

Children list showing every linked child with class, section, and current standing
Attendance calendar per child with daily status and month-level percentage
Fee breakdown per child showing structure lines, transport, adjustments, payments, and balance
Receipt visibility for any payment recorded by the school office
Report card download once results are published for an exam
Phone-number sign-in scoped to the parent identity space, separate from staff sign-in

Teacher portal

Teachers see only their classes. The class teacher of Grade 5-B sees the 5-B roster for attendance; the subject teacher who teaches Mathematics to Grade 7-A sees the 7-A mathematics grading sheet. Scope is enforced server-side so the same controls that protect tenant boundaries also protect intra-tenant role boundaries. The result is a portal that feels small in the right way — a teacher signs in and sees today's work, not a configuration screen.

Class roster view for every section the teacher class-teaches
Attendance marking scoped to the teacher's class-teacher assignments
Subject-wise grading sheets scoped to the teacher's subject assignments
No visibility into other teachers' classes, other students, or admin-only screens
Email-based sign-in scoped to the staff identity space
Server-side enforcement of section scope — URL tampering doesn't reveal other sections

Platform and branding

Every school running on JEduManage is its own tenant, with its own data, users, fee structures, SMS templates, audit log, and branding. The school's logo and display name appear in every portal sidebar — admin, teacher, parent — replacing the JEduManage wordmark the moment the admin uploads them. For trusts running multiple schools, the super-admin role sits above the tenants with a cross-tenant dashboard for onboarding and platform-wide monitoring, but it never punches a hole in the per-tenant data isolation. The school ERP page covers the multi-tenant ERP angle in more depth.

Multi-tenant isolation enforced at the database query layer — every read and write injects the school's account_id automatically
Per-school logo + display name shown in every portal sidebar; falls back to JEduManage branding if not uploaded
Onboarding flow that captures logo and school name in a single step
Super-admin role with a cross-tenant dashboard for tenant creation, SMS usage monitoring, and platform-wide audit
Tenant-scoped configuration for SMS templates, grade bands, fee line items, and bus route catalogue
No cross-tenant data access from any school-level role, regardless of URL manipulation

Security and audit

Security isn't a sales bullet — it's the reason a school can hand a system to a class teacher without losing sleep. JEduManage uses argon2id for password storage, JWT access tokens with role-encoded permissions for authorisation, and tenant-scoped queries for data isolation. Parent and staff identity spaces are kept separate so role-specific login works correctly even when the same phone or email appears in both. The audit log is immutable and complete enough that most operational disputes are resolved from it directly. The school management software page explains how this fits into day-to-day operations.

JWT access tokens with role-encoded permissions for stateless authorisation
argon2id password hashing for every staff and parent account
Role-specific login lookup — staff sign in by email, parents by phone, with separate identity spaces
Per-tenant phone uniqueness on staff so a teacher and a parent can share a phone number without portal ambiguity
Immutable audit log of every administrative action with actor, timestamp, old value, and new value
Audit log queryable by date, module, and entity (student, fee, route, user)
RBAC matrix mapping each role to read/write/trigger permissions on each module
Server-side enforcement of every permission — UI hides what the user can't do, but the server independently rejects it as well

Where to go next

This page is the breadth view. Two narrower paths typically give an evaluator everything else they need: the solution pages (school management software, school ERP,student information system, attendance management, fee management) for module-by-module depth, and the pricing page for commercial details. If you'd rather skip the reading and see the product in your own context, book a demo — we'll spin up a tenant with your branding and a sample student cohort, usually the same day you reach out.

Everything inside JEduManage, organised by what schools actually do.