Yes. One ERP can run several school branches, and for a trust running more than two it is usually the only arrangement that produces reliable consolidated numbers. The real decision is not whether to centralise but which decisions stay central and which belong to each branch, because getting that split wrong is what makes multi-branch systems fail.
What should be centralised, and what should not
The useful test is whether a decision needs to be consistent across branches to be meaningful.
| Decision | Central | Per branch | Why |
|---|---|---|---|
| Student record format | Yes | A transfer should not need re-entry | |
| Fee heads | Yes | "Tuition" must mean the same thing in two cities | |
| Fee amounts | Yes | A Pune branch rarely charges what a tier-3 branch does | |
| Academic calendar skeleton | Yes | Term and exam windows anchor consolidated reporting | |
| Local holidays | Yes | These vary by state | |
| Report card templates | Yes | The board does not vary by branch | |
| Timetable and sections | Yes | Teacher allocation is local | |
| Transport routes | Yes | Entirely local | |
| Role definitions | Yes | Who sees what must be consistent to be enforceable | |
| Parent communication | Yes | The branch knows its own parents | |
| Admission intake per class | Yes | Capacity is a building constraint | |
| Consolidated reporting | Yes | Only works if the rows above are shared |
The mistake worth avoiding is centralising fee amounts because fee heads were centralised. Heads are a schema and should be identical; amounts are a local commercial decision and forcing them uniform creates workarounds inside a month.
How student transfers between branches work
A transfer inside a trust should not look like a new admission. When branches share one database, moving a student is a reassignment rather than a re-enrolment:
- The receiving branch raises a transfer request against the existing student record.
- The student's ID, academic history, documents and fee ledger move with them.
- Outstanding dues at the old branch remain visible at the new one, which is the point. Transfers are a common way for arrears to disappear.
- The old branch's roll count drops and the new branch's rises in the same action, so neither branch double-counts the student in its attendance or strength figures.
What to test in a demo: transfer a student mid-term, with an unpaid instalment, and check whether the arrears follow. Many systems handle the clean case and lose the ledger on the messy one.
What consolidated reporting actually gives a trust
The honest answer is that it gives you comparable numbers, not more numbers. A trust running four branches usually already receives four reports. The problem is that they arrive in different formats, on different dates, computed differently.
Shared definitions produce:
- Collection against target by branch, on the same date, with the same definition of "collected"
- Strength and attendance by branch, so a drop in one is visible before the term ends
- Staff cost per student by branch, which is the number that usually explains why one branch is unprofitable
- Admission funnel by branch and class, showing where intake is short against capacity
The caution: consolidated reporting is only as good as the slowest branch's data entry. If one branch marks attendance weekly, the trust dashboard is weekly. This is a process problem that software surfaces rather than solves, and it is worth agreeing a data-entry standard before go-live rather than after.
Branch-level access and who sees what
A principal should see their own branch in full and nothing from another branch's parent contacts or staff salaries. A trust administrator should see every branch in aggregate and be able to drill into one. A teacher should see their classes.
Ask any vendor to demonstrate three things live: a branch principal attempting to open another branch's data, a trust-level user drilling from a consolidated figure into one branch, and what a branch accountant can and cannot see about staff payroll. Role-based access is easy to claim on a slide and visibly either works or does not in a demo.
When separate instances make more sense
One ERP is not always right. Separate systems per branch are defensible when:
- Branches run different boards and different academic calendars, with no shared reporting requirement
- The branches are separate legal entities with no consolidated financial reporting
- One branch is being prepared for sale or separation
- A branch is in a jurisdiction with a data residency rule the others are not
If none of these apply and you are running more than two branches, the cost of reconciling four spreadsheets each month usually exceeds the cost of the system.
What this costs
Multi-branch is typically priced above single-school plans, and usually as a tier rather than a per-branch multiple. Ask specifically whether the quote is per branch, per total student count across branches, or a flat trust licence, because the three produce very different numbers at four branches. Our own plans and what sits in each are on the pricing page, and the cost guide covers how to put two multi-branch quotes on the same basis.
FAQs
Can one ERP run multiple school branches?
Yes. A single ERP runs several branches by sharing the student record format, fee heads, academic calendar and report card templates centrally, while each branch controls its own fee amounts, timetable, transport routes and local holidays. This split is what makes consolidated reporting across branches possible.
How do student transfers between branches work?
Inside one system a transfer is a reassignment rather than a fresh admission. The student keeps their ID, academic history, documents and fee ledger, outstanding dues stay visible at the receiving branch, and both branches' roll counts update in the same action so the student is never counted twice.
Should fee amounts be the same across all branches?
No. Fee heads should be identical across branches so reporting is comparable, but amounts should stay local, because branches in different cities rarely support the same fees. Systems that force uniform amounts get worked around within a month.
What does a trust see that individual branch reports do not?
Comparable figures rather than more figures: collection against target by branch on the same date, strength and attendance by branch, staff cost per student, and admission intake against capacity. The limit is data entry discipline, since the dashboard is only as current as the slowest branch.
Is one ERP always better than separate systems per branch?
No. Separate instances make sense when branches are separate legal entities with no consolidated reporting, run different boards and calendars with nothing shared, or when one branch is being prepared for separation. Past two branches with shared reporting, one system usually wins.
For colleges and institutions running multiple campuses rather than schools, see multi-branch college management software. The underlying structure is similar, but college intake, programme and semester handling differ enough to be worth reading separately. If you are still deciding on the category, what is school ERP software covers the modules.
