Ask a school ERP vendor in India what their software costs and you will usually get the same answer: fill in this form and we will get back to you. Sit through a demo, wait three days, and a quote arrives with no way to tell whether it is reasonable.
This guide explains how these products are actually priced, which costs tend to sit outside the headline number, and the questions worth asking before you commit your school to a multi-year contract.
The three pricing models
Almost every school ERP sold in India uses one of three models. Knowing which one you are being quoted matters more than the number itself, because they behave very differently as your school grows.
1. Per-student, per-year
You pay a set amount for every enrolled student, billed annually.
It is the most common model, and the most misunderstood. The per-student figure always sounds small in a demo. The number that matters is that figure multiplied by your entire roll, every year — and it rises every time you admit a student. A strong admissions year becomes a larger invoice.
2. Per-module, or tiered packages
You buy a base package covering core functions, then pay separately for each additional module — transport, library, hostel, payroll, and often the parent app.
The difficulty with this model is that the modules a school actually needs daily are frequently outside the base tier, so the working price is only clear after you have listed every module you will use.
3. Flat annual fee
One price for the institution, regardless of how many students are enrolled or how many modules you switch on. Budgeting is predictable and admissions growth does not change the bill.
This is the model we use, and the reasoning is in the section below.
The costs that rarely appear in the headline quote
The licence fee is usually only part of what a school pays in year one. Before comparing two quotes, confirm in writing whether each of these is included:
- Implementation and onboarding — configuration, and the vendor's time during setup
- Data migration — moving existing student, staff and fee records across
- The parent mobile app — very often licensed separately from the web platform
- Training — for teachers, the accounts team and administrators
- SMS and WhatsApp credits — normally billed per message on top of the licence
- Annual maintenance or support — sometimes a percentage of the licence each year
- Customisation — report formats, certificate templates, board-specific layouts
- Payment gateway charges — who absorbs the transaction fee on online fee collection
- Contract length and exit terms — how long you are locked in, and how you get your data out
That last point deserves particular attention. A long lock-in combined with an unclear export path is the most expensive item on this list, because it removes your ability to leave if the product disappoints. Ask for the exit terms in writing, and ask specifically what format your data comes back in.
What we charge, and why we publish it
Amitrix EMS is ₹12,000 per year for the whole institution. Unlimited students, every module, the parent mobile app, and data migration included. No per-student charge and no setup fee.
We publish it for a simple reason: a school evaluating software should be able to compare options without sitting through three sales calls first. Hiding the number only helps the vendor.
We can price this way because of how the platform is built, not because we are running a discount. Amitrix EMS is a single system serving every institution on it — adding a school is a record in a database, not a separate installation on a separate server that has to be upgraded, backed up and supported on its own. And nothing in the system meters students: a school of 2,000 costs us no more to run than a school of 200, so charging by student would be billing you for something that does not actually cost more to provide. Migration is included for the same reason — your records come in through a spreadsheet template built for the job, not a week of somebody's consulting time.
What we have learned migrating schools
The import itself is rarely the hard part. Moving a few thousand student records takes minutes. What takes the time is everything the old records quietly assume, and it is the same handful of things almost every time.
Guardian contact details are the messiest field, not fees. Most school records hold a student's name, class, roll number and a parent's phone number — and little else. There is frequently no email address and no login of any kind, because the old system never needed one. Plan for records that arrive with one reachable phone number per family and nothing more, and make sure whatever you move to can generate the rest rather than demanding it up front.
Siblings share a parent. Two children in the same school usually list the same parent phone. If the import treats every row as a separate family, one parent ends up with two logins and sees half their children in each. It is an obvious problem in hindsight and a genuinely awkward one to unpick after go-live, so ask any vendor directly how their import links siblings to a single guardian.
Be careful what you back-date. A school switching mid-session usually wants some history loaded — previous terms' fees, past attendance. Generating fee invoices for months that have already passed is the step to slow down on: it is easy to raise a full month of invoices for every student with one click, and far slower to work out afterwards which ones were intentional. Load history deliberately, one period at a time, and check the first batch before running the rest.
Mid-year joiners should not inherit the year. A student admitted in September should not appear as owing homework set in July, or show an attendance percentage calculated from a term they were not enrolled for. Ask how the system decides what a student is responsible for — if the answer is "everything assigned to their class", expect to spend your first week explaining alarming numbers to parents.
None of this is difficult, but it is the difference between going live in a day and spending a fortnight on corrections.
Questions to ask before you sign
Take these to any vendor demo:
- Is the price per student, per module, or flat — and what happens when our roll grows 20%?
- What is the total year-one cost including setup, migration, training and the parent app?
- Is the parent mobile app included, and is it a real app or a mobile web page?
- Who owns our data, and in what format can we export it if we leave?
- How long is the contract, and what is the notice period?
- Are SMS and WhatsApp messages billed separately? At what rate?
- Will you migrate our existing records, and is that quoted separately?
- What does support cost after year one, and what is the response time commitment?
- Which boards do the report card and certificate templates already support?
- Can we see the system running on a sample of our own data before deciding?
That last question is the most revealing. A vendor confident in their product will agree to it.
In short
Work out the total year-one cost, not the headline licence fee. Ask which model you are on and what happens when enrolment grows. Get the inclusions in writing.
If you want to see what a flat-fee platform looks like running on your own records, book a 30-minute demo — we will load a sample of your data before the call. Full pricing is on the pricing page.