A school in Punjab
Almost no two groups of students paid the same way.
Roughly a thousand students, and almost no two groups of them paying the same way. One of their rules charged a fee every second year, counting from the year each individual student was admitted.
Several school management systems had been evaluated. Each of them could bill a fee. None of them could bill this school.
Their principal sent us a sample of their data. We configured the rules and showed him his own students billed correctly. That covered about 95% of what he needed.
He paid us nothing for that. We did the work first, and he paid only after he had seen his own students billed correctly. The school has run on EduBold since early 2026.
The evaluation
- Students
- ~1,000
- Rules at evaluation
- 10
- Rules in production now
- 40
- Met on their own data
- 95%
In production since early 2026.
The problem
The school did not have one fee structure. It had many at the same time.
A thousand students is not a large school. The number of students was never the problem.
The students fell into a great many different groups, and each group was charged differently. These were not a few exceptions to one standard structure. They were separate fee structures, running side by side, in the same school, in the same month.
Four of their rules, in ascending order of how much trouble they caused.
Students admitted under the RTE quota
Charged differently, as the Act requires. Every system can handle a category.
Children of staff
A concession tied to a parent’s employment. Again, ordinary.
Siblings, by position in the family
The first child pays the full fee. The second and every later child pays half.
This is where it starts to cause trouble. The discount does not attach to a student. It attaches to their rank within a family. So the system has to know which children belong together, and which one of them is first. A flat sibling discount is a different rule and gives a different answer.
A registration fee due every second year, counting from the year each student joined
This is the one that ended the evaluation. Some students owe a registration fee every two years, and the years it falls due depend on when that student was admitted.
Two children sitting in the same class, in the same year. One owes the fee and one does not, and which is which depends on something that happened years ago.
This cannot be modelled as a group, because the membership of that group changes every year and differs per student. It cannot be modelled as a fee frequency either.
| Cohort | Pays in |
|---|---|
| Admitted 2020 | 2020, 2022, 2024, 2026 |
| Admitted 2021 | 2021, 2023, 2025, 2027 |
The whole structure runs on about ten rules. Not a hundred. Ten. A school that several products could not bill at all is described, completely, in about ten rules.
What made the difference
There is no “every two years” fee in EduBold.
That is worth stating plainly, because it is the point.
The fee frequencies in this product are monthly, quarterly, half-yearly, yearly, term and one-time. Nobody ever built an option for a fee that repeats every second year, because nobody anticipated the requirement.
What exists instead is a rule engine. Its conditions read the student’s own attributes, including the date they were admitted, and chain together with AND and OR. When a rule matches it does one of four things. It applies a percentage discount, or a fixed discount. It waives the charge. Or it adds a component.
That is the entire mechanism. It is small, and it is why the fourth rule was expressible.
The school did not need a product that had already thought of their situation. They needed one that could be told about it.
Module or engine
This is invisible during a demo unless somebody tests it.
A fee module holds structures. You pick the one that fits, and where none fits you keep a spreadsheet and a person who remembers. Every product they evaluated could hold a fee structure. Several could hold a great many.
A fee engine holds conditions. The number of different ways your students pay stops being a constraint, because each one is a rule rather than a structure somebody has to maintain.
How they found out
They did not take our word for it. They sent us their data.
The principal approached us with the problem rather than the other way round, having already been through the alternatives.
He sent a sample of their real student data. We configured the rules against it and ran the billing. Then we showed him the result: his own students, his own groups, billed the way his school actually charges.
It came out at about 95% of what he needed.
We publish that number rather than rounding it up. A vendor claiming to have met every requirement in a first pass is describing a demo, not an evaluation.
Since then
Around eight months in production. The office uses it daily.
That covers a full billing cycle, including the months when fees fall due and a fee system that does not quite fit becomes impossible to ignore.
No significant issues reported.
What it establishes
The fee engine was tested against the alternatives, and it won.
This school's structure is as awkward as fee structures get, and it was the exact test that separated EduBold from the products they looked at first.
The hard part of a school ERP is the fee rules, because that is the part nobody can change once the year has started. Test us on yours.
The same offer
This is an offer, not an anecdote.
If your fee structure is the reason you have not moved systems, send us a sample of your data and the rules you actually apply. We will configure them and show you your own students billed correctly. It costs you nothing, and you decide whether to buy after you have seen it.