Multi-Branch School ERP: How a Trust Runs Many Schools

TL;DR: A multi-branch school ERP puts one trust account on top of several schools or campuses. Each branch runs its own admissions, attendance and fees through its own admin, and only trust-level users see across branches. Before you choose software, decide what the trust controls centrally (fee head names, academic year, user access) and what each branch controls locally (fee amounts, timetables, daily work). Roll out one branch first, then copy the setup.

Who this guide is for

Many Indian schools are run by a trust or society that has grown from one campus to two, three or six. Often there's a CBSE school in the city, a state-board school in a nearby town, a PU college, and perhaps a tuition or coaching wing.

At that size, three problems show up:

• The trust can't see the numbers (strength, fee collection, attendance) without phoning each principal.
• Each branch keeps records its own way, so nothing adds up across branches.
• Access is messy: an office clerk at one branch can see, or edit, another branch's data.

A multi-branch setup solves these only if it's designed properly. Here's how to think about it.

Understand the hierarchy first

Most multi-branch systems follow some version of this:

1. Trust or society: the legal entity that owns everything. The trustees and the correspondent sit here.
2. Institution: a type or level of education run by the trust, for example a K-12 school, a PU or junior college, or a degree college.
3. Branch or campus: a physical location where an institution runs. One institution can have several branches.

Why this matters: if the software only knows "schools" and not "trust above schools", the trust ends up with several separate accounts and adds up totals by hand. If it has no "institution" level, a trust running both a school and a PU college has nowhere sensible to put each.

Decide what to centralise and what to leave to branches

Write this down before you set up anything. A simple split that works for most trusts:

Area	Decide at trust level	Leave to the branch
Fee head names (Tuition, Exam, Activity)	Yes, so reports line up
Fee amounts		Yes, branches differ
Academic year dates	Usually yes
Classes and sections		Yes
Timetables		Yes
Daily attendance		Yes
Who gets an admin login	Yes
Receipt number prefix per branch	Yes (so numbers never clash)
Holidays and working days	Common holidays at trust level	Local holidays at branch level

The rule of thumb: centralise the names and the rules; decentralise the amounts and the daily work.

Set up access carefully

This is where most multi-branch problems come from.

• Trust users (correspondent, trustees, an accounts head) see all branches.
• Institution admins see the branches under their institution.
• Branch admins (principal, office manager) see only their own branch.
• Teachers see their own classes. Parents see only their own children.

Test this during any demo. Ask the vendor to log in as a branch admin of Branch A and try to open a student from Branch B. It should fail. If the vendor can't show you this, assume the separation is weak.

Access control is also about privacy. India's Digital Personal Data Protection Rules were notified on 14 November 2025, with an 18-month phased timeline for compliance, and they require verifiable consent before processing children's personal data (PIB, 14 Nov 2025). Limiting each person to the data they actually need is a sensible habit whatever your legal advisor tells you about the details.

Fees across branches

Fees are where trusts most want one view, and where branches differ most.

• Use the same fee head names in every branch. "Tuition", not "Tuition Fee" in one and "TF" in another.
• Let each branch set its own amounts per class.
• Give each branch its own receipt series (a prefix like HBL/ or DWD/) so two counters never issue the same number. Our fee receipt format guide covers numbering in detail.
• Decide who can approve concessions: the branch principal, or only the trust.

What the trust should look at every month

You don't need a complicated dashboard. Five numbers per branch, compared month on month, tell you most of what you need:

1. Student strength by class (new admissions, leavers)
2. Fee collected against fee due, and the pending amount
3. Average attendance and the list of students with low attendance
4. Staff strength and vacancies
5. Admissions enquiries for next year

If your software can produce these per branch, use it. If not, ask each branch for these five numbers in the same Excel format on the 5th of every month. Consistency matters more than the tool.

Rolling out software across branches

A safe order:

1. Set up the trust, institutions and branches in the software, with the right admins.
2. Pick one pilot branch. Ideally the one with the most organised office, not the biggest.
3. Import students and staff for that branch from Excel. Clean the data first: one row per student, admission numbers unique, class names consistent.
4. Set up fee heads and structures, and run fee collection in the software for one full month.
5. Train teachers on daily attendance. Start with one week of parallel paper registers if teachers are nervous.
6. Review with the pilot principal: what was confusing, what took too long.
7. Copy the setup to the next branch, with the pilot branch's office staff helping train.

Rolling out all branches on the same day means every branch makes the same mistakes at once, and you have no one to learn from.

Common mistakes

• One shared admin login for all branches. You lose track of who did what, and anyone can change anything.
• Different fee head names in each branch. Trust-level totals become meaningless.
• Importing dirty data. Duplicate students and misspelt class names multiply across branches.
• No owner per branch. Someone in each branch office must own the system day to day.
• Treating coaching as "outside the system". If your trust runs tuition or coaching batches, keep them in the same system so fees and students aren't split across two tools.

How EduTechMonitor handles multiple branches

EduTechMonitor is built around the trust → institution → branch structure described above. Each branch has its own admin, and logins are role-based: trust, institution and branch admins, teachers, students and parents. Branches run their own admissions (including an online admission form and bulk import from Excel), daily attendance, fee structures with printable receipts, and class timetables. A trust can also run school classes and coaching batches in the same system.

What it doesn't do yet: exams and report cards, a parent mobile app, online fee payment, transport, and SMS/WhatsApp alerts. Plan for those separately if you need them now.

Pricing is published: ₹1,20,000 a year + 18% GST for up to 250 students, and ₹20 per student per month above that (cost guide). For a trust with several branches, ask us for a written quote showing exactly how the student count is applied to your setup. Our support team is in Dharwad, Monday to Saturday, 10am–6pm IST, with on-site visits by appointment. More on the multi-branch setup.