EduBold · School management software
Everything a school runs on, on one set of records.
EduBold is a student management system for schools and trusts. Most schools that come to us already have one, with the same module names on it. What they are looking for is the part underneath: the fee that only some children pay, and only in some years. The teacher who takes four sections, where none of them may clash. The year end where the accounts are already written, so the auditor is not waiting on anybody. Built in India, for one school of a few hundred students or a trust running several branches and tens of thousands.
Every system claims the same list.
The list is never the difference. Admissions, attendance, the timetable, exams, the library, fees, payroll, accounts and more. A hundred products will tell you they have all of it, and most of them genuinely do. What separates them is how far each part actually goes, and whether they are one system underneath or several wearing the same badge. Some of the places that shows:
What follows is one school day, from the timetable before the bell to the ledger at close. Every part of it runs live in your browser, so you can judge the depth rather than take our word for it.
Every child here is a name, a roll number, an attendance mark and a fee rule. Somebody has to keep all four straight, every day, for all of them.
07:40 · Before the bell
The timetable solves itself.
The timetable module. It builds the weekly schedule for every class and every teacher from the constraints you set, and finds its own clashes instead of leaving you to spot them.
The rules are listed beside the grid, and it is placing thirty lessons against all of them at once. Watch it work, and every time a lesson will not go where it tried, it names the rule that stopped it.
This is not a video. The solver runs in your browser, on real constraints, every time you press it.
10-A, 10-B and 10-C are already timetabled. This is 10-D, fitting around them. Every teacher below is shared with those three sections, so most slots are already spoken for.
- 5 days, 6 periods: thirty lessons, no free periods
- 4 sections, 10-A to 10-D, timetabled against each other
- 8 teachers, shared: none in two sections at once
- No subject twice in one day
Press solve, and it will say what it is doing.
08:05 · The gate
Every arrival, counted once.
The attendance module. It records who is present, students and staff, whether the mark came from a biometric device, a teacher or an import, and passes the result straight to payroll.
Every punch on the biometric device lands here, keeping its source, so you can tell a device reading from a teacher’s mark from an import. A device that stops reporting shows as a failed sync the same day, not as a payroll problem at month end.
The roll on the right is eighteen hundred children. Nothing about it changes at a few hundred, or at tens of thousands across several branches. The roll simply has more marks in it.
10:15 · A parent on the phone
One child. One screen.
The student record. Everything known about one child in one place: admission, class, attendance, fees, exam results, library books, health, siblings and who to ring.
A parent asks a question. Nobody has to check six places and hope the six agree, because there is one record and six screens looking at it. The parent is still on the phone when you have the answer.
Aarav Sharma
GIS/2026/014Roll 1410-A Active
All on the same record
12:30 · The fee run
The rule decides.
The fee module. It calculates what each child owes from rules you set once, bills it every month, and keeps the list of what has not arrived.
No fee is typed twice. A rule reads what is true about a child and bills accordingly, including the awkward one every school has.
AND class ≥ 9
THEN add registration_fee once every second year
15:20 · The clerk writes a receipt
And the ledger already knows.
The accounts module. Real double-entry books, posted as the school operates, so the year-end statements come out of the ledger rather than out of a spreadsheet.
Real double-entry, posted as the school operates rather than assembled afterwards. The receipt is named on the entry it created, so at year end nothing has to be reconstructed from an export.
The entry names the receipt it came from, so at year end nothing has to be reconstructed. Demonstration data.
Every branch keeps its own records.
The platform underneath. One installation carries a whole trust. Each school in it, and each branch of a school, is kept apart from the others. The separation is held by the database itself, rather than by the software remembering to ask.
Every record carries the school and the branch it belongs to, and every question put to the database carries that with it. So a branch office sees its own students, its own fees and its own staff. It sees nothing from the branch down the road, whether or not anyone remembered to ask for it that way.
This is the part a trust asks about first, so it is measured rather than asserted. Counted against the live system on 18 August 2026.
What schools ask before they move.
Is the solver on this page the real one?
It is the same problem, running the same way, at a smaller size. This one places one section around three others on two constraints. The product’s version works across every section in the school, and holds rooms, lab availability, teacher preferences and workload limits as well. When it cannot place a lesson it says which rule stopped it, rather than handing you an incomplete grid.
Our fee rules are strange. Will they fit?
Probably, and this is the thing worth testing first. Fees are not a list of amounts here, they are rules that read what is true about a child: when they were admitted, which class, which siblings, which concession. Send us the rule your current system cannot express, and we will tell you in the call whether it fits.
Can we see it on our own data before we decide?
Yes, and it is how most schools decide. Send a sample of your student data and the fee rules you actually apply, and we configure them and show you your own students billed correctly before you have paid anything.
What actually happens in the half hour?
You bring the thing your current system cannot do, and we try it in front of you. Not a slide deck and not a feature tour. If we cannot do it either, we say so in the call rather than after an invoice.
We are mid-session. Is that a problem?
No, but it changes the work. Starting at the top of a session is mostly checking imported master data. Moving mid-session means carrying opening balances and the fee history already collected, which can be backfilled so the year still closes properly.
Who is behind this software?
Indivar Software Solutions Pvt. Ltd., in Mohali, Punjab. The company was incorporated in February 2009, and has been building school software since 2012. Every year since then has gone into this one thing, across schools of many kinds and sizes.
Indian company, Indian team, built against Indian statutory practice rather than adapted to it. You can ring the office on +91 7508 400 400.
16:00 · Last bell
Bring the thing your system cannot do.
Half an hour on the problems your school actually has. Send us your fee rules and a sample of your data, and we will show you your own students billed correctly before you commit to anything. If we cannot do it either, we will say so in the call.