School ERP software for multiple branches

School ERP software is the system a school group runs on: admissions, academics, attendance, fees, HR, payroll and reporting in one place. Choosing it is less about the module list and more about whether the software can model your organisation.

Most buying decisions go wrong because the demo is run against one school, while the actual problem is running five of them under one owner.

Start with your organisation, not the features

Before comparing vendors, draw the structure you need to operate:

• How many campuses, and do they share an owner or operate as separate entities?
• Which decisions belong to head office, and which belong to a principal?
• Do fees, calendars and grading differ per campus?
• Does the group need consolidated reporting, or only campus-level reports?

If the answer includes "head office needs the whole picture, each campus needs its own controls", you are buying a multi-tenant platform, whether or not the vendor uses that phrase.

The modules that matter, in order

1. Admissions and student records — one student, one record, from enquiry to alumni 2. Academics and results — periods, assessments, grading schemes per campus 3. Attendance — feeding both academic reporting and payroll 4. Fees and finance — vouchers, invoices, reconciliation, budgets 5. HR and payroll — staff records, allowances, deductions, settlements 6. The extras — LMS, inventory for uniforms and books, fixed assets, transport

A platform is only as good as the module you switch on second. Ask what breaks when enrolments double.

School ERP software price: what you are actually paying for

Pricing models differ widely: per student, per campus, per module, or a platform fee plus sub-accounts. Ignore the headline and compare three-year total cost:

• licences for the campuses you will onboard in years two and three
• implementation and data migration
• training hours across administrators, teachers and accountants
• the cost of the modules you will realistically enable
• support and upgrade terms

Per-student pricing looks cheaper until enrolment grows. A flat platform fee looks expensive until you add the third campus.

The questions that separate a platform from a product

Ask each vendor the same five:

• Can we add a campus without a new deployment or a fork of the code?
• Can a group and a campus both report from the same data?
• Can fee rules and grading schemes differ per campus?
• What happens to historical periods when a policy changes?
• Can we export our full data, including documents?

The answers reveal architecture. A vendor who answers "we can customise that per client" is selling projects disguised as software.

Migration is where most rollouts fail

The system is not the risk; the data is. Plan the migration before signing:

• agree one source of truth per field (student, guardian, fee, staff)
• clean duplicates before import, not after
• migrate one campus first and reconcile a fee month end to end
• keep the old system read-only for a term

Groups that skip reconciliation discover discrepancies three months in, when history is harder to unwind.

What to look for in a demo

Ask for a live walkthrough of a task you actually do badly today — for example, reconciling a month of fee collection across two campuses. A vendor demo shows features; your scenario shows whether the data model holds.

Watch how the system handles a change: a mid-term fee revision, a new campus, a promoted student.

What this looks like in practice

We built ITQAN ERP for exactly this problem: one configurable platform, five role-based dashboards and sixteen operational modules, with each school configured rather than forked. If you want the build side, see the ITQAN school ERP case study or our custom software development service. For another sector with the same evaluation questions, read what to check in pharmacy POS systems — the pattern is identical.

The short answer

Choose school ERP software on organisation fit, not module count: branches and ownership layers must be data, reporting must work at both levels, and migration must be planned before the contract. Match the platform fee to how many campuses you will realistically run in three years.