Policy at the trust level
Fee structures, concession rules, approval limits and academic calendars are defined once and inherited by campuses, with local variations recorded as exceptions.
School management system · Multi-campus school management software
School groups swing between two failures: a head office that becomes the bottleneck for every decision, and campuses that drift into their own processes. SquareCampus is modelled on trust, school and campus from the start, so policy is set once and executed locally.
Direct answer
Multi-campus school management software runs several schools or campuses on one system with a shared institutional model. The trust or head office sets policy, fee structures, academic calendars and approval limits; each campus executes within them; and leadership sees attendance, collections, admissions and exceptions across all campuses in one view without consolidating reports.
SquareCampus includes these capabilities and is positioned as a School Operating System. Read the canonical definition.
How it runs in SquareCampus
A module list hides the real question: does the work connect? These are the workflows as they run in production.
Fee structures, concession rules, approval limits and academic calendars are defined once and inherited by campuses, with local variations recorded as exceptions.
Each campus runs its own admissions, attendance, fees and communication inside the trust's rules, with its own owners and its own audit trail.
A campus principal sees their campus; a trust finance officer sees collections everywhere; a trustee sees exceptions across the group. Scope is a property of the role.
Collections behind plan, attendance dips and stalled approvals surface as exceptions with an owner, whichever campus they belong to.
Monthly trust-board views come from the same data the campuses run on, so there is nothing to reconcile before the meeting.
Governance versus support
Most school software can hold several campuses' records. The buyer question is whether policy, scope, exceptions and board reporting cross campuses without consolidation. This is the difference, dimension by dimension.
| Dimension | Supports multiple campuses | Multi-campus governance |
|---|---|---|
| Structure | Each campus is a separate instance or a branch code on the same records | Trust, school and campus are one hierarchy in the institutional model |
| Policy | Head office circulates a policy; each campus configures its own version | Policy is set once at the trust level and inherited; local variation is recorded as an exception with a reason |
| Access | Campus users are separated by login | Scope is a property of the role: a principal sees one campus, a trust officer sees across campuses, on every screen, report and AEGIS answer |
| Exceptions | Each campus escalates by phone or email | Collections behind plan, attendance drift and stalled approvals surface as owned exceptions, whichever campus they belong to |
| Reporting | Campus reports are consolidated before the board meeting | Board views come from the records the campuses run on, with nothing to reconcile first |
Built for India
Boards, fee structures, trusts and parent channels are configuration here, not customisation projects.
India-first specifics
What to check in any vendor
Ask these of every vendor you evaluate, including us. The answers separate a connected system from a set of modules.
Questions
Short answers, the way a buyer asks them. The FAQ page covers evaluation, security and rollout in more depth.
More on evaluation, security and rollout in the FAQ.
Related
The pages a buyer on this question usually reads next.
Next step
A guided demo on your own scenario, followed by a written scope, from a founder-led team. The licensing model is published; figures follow a written proposal.