Single-school vs multi-school ERP: how to tell which one you are actually buying multi-school

A trust in Lucknow runs three campuses. All three bought the same well-known ERP, so the office assumed they were "on one system". In June the director asked for one number — how many students are on roll across all three campuses today — and got back three spreadsheets, two of them still counting last year's leavers. Nobody was careless. The software had been built for one school and sold three times, so there was no place inside it where "the trust" existed. Three campuses, three separate stores of data, three versions of the truth. The word multi-school had been on the brochure the whole time.

Here is the distinction almost no brochure makes. Some systems treat a school as a copy of the software. Others treat a school as an address inside one organisation. Everything you care about follows from that single choice — whether a group view is instant or an Excel job, whether a student can move between campuses, whether one login opens all three campuses or your director carries three sets of credentials. You cannot see it on a feature list. You can see it in ten minutes of a demo, if you know what to ask.

The three architectures sold as "multi-school"

When a vendor says they support multiple schools, they mean one of three very different things.

One: separate installations. Each campus gets its own copy of the system, its own login, its own data. This is multi-school by sales contract, not by software. It is by far the most common thing sold as multi-branch in India, and it is the one that produces the three-spreadsheet problem.

Two: one system, flat data. Every campus shares one store of data, separated by a filter that somebody has to remember to apply on every screen and every report. Group totals are possible. So, occasionally, are leaks between campuses — a class list or a fee ledger surfacing where it should not.

Three: organisation-first. The organisation is the root of the system and each school sits inside it. The campus is part of the address of every single thing in the system, so it can never be forgotten, and the group view costs nothing to produce because the data was never split up in the first place. This is the only one of the three where a chairman's question has a same-second answer.

What a genuine multi-school platform has to do

The difference is not that a group needs more features. It is that a group needs a layer that single-school software has no concept of. These are the capabilities that only exist when the organisation is the root.

The India bar: where the claim breaks

The Indian group school has two conditions that break most multi-school claims immediately. The first is the academic calendar. Campuses in the same trust genuinely do run on different sessions — a new campus opening mid-year, a senior wing on a board calendar, an acquired school still finishing its year. Software that assumes one shared calendar for the whole organisation reports zeros for every campus that is out of step, which is worse than reporting nothing.

The second is the student who moves between your own campuses. In most systems this is handled as an exit and a fresh admission, because the software has no idea the two campuses belong to the same trust. The family gets a transfer certificate they should never have needed, the fee history breaks in two, and the child appears in your headcount twice. Every group in India hits both of these in the first year. Almost no demo covers either.

How to choose: the six-point demo test

Do not accept a feature list. Make the vendor prove the organisation layer, live, on data with more than one campus in it.

1. Ask for every campus on one screen. Students on roll, today's attendance and fee collection, campus by campus. If the answer is "log into each campus separately", you have single-school software with a multi-branch price.
2. Ask two campuses to sit on different academic sessions. Have them set Campus A to a closed session and Campus B to a live one, then reopen the group view. If numbers go to zero or the screen errors, the group layer assumes one calendar and will not survive your second campus.
3. Move a student from one campus to another. Watch closely for whether the admission history, fee ledger and marks travel with the child, or whether they are re-admitted as new. This is the single sharpest test in the whole evaluation, and it takes ninety seconds.
4. Build two people in front of you. A principal who can see only their own campus, and a trust head who can see all. Then have the principal try to open another campus. If they can, access is decoration.
5. Log in once and switch campus. Confirm one person can move between campuses without logging out. Four sets of credentials is the tell that these are four systems wearing one name.
6. Ask for one contract and one invoice. Confirm the group is priced as a group, that the organisation view is included rather than sold as a premium tier, and ask plainly who pays the online payment gateway charge.

The names you will run into

The Indian market has genuine multi-campus platforms and it has single-school products with a branch selector bolted on, and the brochures read identically. Names you will meet include Entab (CampusCare), long established in large CBSE chains; Next Education, whose NextERP is marketed at scale with an explicit single-login, all-branches pitch; Edunext; Fedena, which has supported multi-institute setups for years; MyClassboard; Campus 365; edumerge, which positions specifically at groups running anywhere from two to fifty-plus campuses; and newer organisation-first platforms including Inkwelly. Some of these will pass all six tests. Several will pass the first and fail the third. The point is not the vendor's size or age — it is whether the organisation exists inside the software as a real thing, and the only way to find that out is to make them show you.

The pricing reality

Indian school software runs roughly ₹20–₹100 per student per year, and multi-school buyers have more leverage than they usually use. At group volume — say 3,000 students across three campuses — you should be negotiating a single rate in the ₹20–₹40 band, not accepting three separate small-school quotes that quietly add up to double. Two things are worth pinning down in writing. First, that the organisation view and campus-to-campus transfer are part of the product and not an enterprise upgrade; charging extra for the group layer is charging you extra for the thing you came to buy. Second, the payment gateway charge on online fees, typically 1.5–2% per transaction, which most Indian schools pass to parents — confirm it is identical at every campus, because inconsistent gateway settings across campuses is a common and avoidable mess. Also insist on one renewal date. Four renewals in four months is a real cost measured in your office's time.

Where Inkwelly fits

Inkwelly is organisation-first by construction: the organisation is the root, and every school lives inside it, so the campus is part of the address of every student, invoice, mark and message in the system. That is why the group view is immediate rather than assembled — and why campuses on different academic sessions still report correctly, which is the case most group software gets wrong. Moving a student between your own campuses is a first-class action that carries their record across, not an exit and a re-admission. Access maps to your org chart through role-based permissions, one login opens every campus a person is entitled to, and the whole group runs on one contract with transparent per-student pricing. If you run a group, do not take our word for it — run the six-point test on us, and read the group and multi-branch buyer guide before you shortlist anyone.

“The question is not whether the brochure says multi-school. It is whether the organisation exists inside the software as a real thing — and a student who cannot move between your own campuses is the answer.”

Decide in two weeks

Shortlist three platforms and put every one of them through the same six-point test on multi-campus data — one established enterprise name, one mid-market product, one organisation-first platform. Score the group layer only; ignore the feature count, because on features almost everyone is close enough. Two questions will separate the field on their own: can two campuses run different academic sessions, and can a student move between campuses with their history intact. In our experience those two questions eliminate most of a shortlist in a single afternoon. Whatever survives both is genuinely multi-school, and you can go back to comparing the things that are easy to compare.

See your whole organisation on one screen

Book a 20-minute demo and we will run the six-point test live — every campus in one view, two campuses on different sessions, and a student moving between them with their record intact.