--- title: "SquareCampus Pricing | School OS Plans for Schools and Trusts" description: "Explore Starter, Pro and Enterprise plans for SquareCampus. Annual institutional licensing scales with student volume, campus complexity, governance depth and deployment requirements." canonical: https://squarecampus.com/pricing/ describedby: https://squarecampus.com/llms.txt --- Commercial model # Pricing that scales with the institution — not with software complexity. SquareCampus is licensed annually as one institutional platform. The licence is calculated through student-volume bands and scoped according to the operational depth, governance requirements and deployment profile the institution actually needs. [Get a tailored proposal](https://squarecampus.com/demo/) · [Explore the Founding Partner programme](https://squarecampus.com/launch-partners/) No hidden module wall. No compulsory rip-and-replace. Scope, ownership and success measures agreed before deployment. Commercial doctrine Students price platform scale. The plan prices operational and governance depth. Two separate dimensions, decided separately. Scale is a fact about the institution; depth is a decision about how much command it wants over daily operations. **Licence** Annual, institutional **Calculated on** Student-volume bands **Shaped by** Operational depth How the licence is composed ## Four inputs, agreed openly, before any number is issued. The annual platform licence is not a module count. It is the sum of institutional scale, the depth of operational command selected, the complexity of the institution and how the platform is delivered. The equation Annual platform licence One annual institutional licence, composed of four inputs that are each discussed openly during scoping. Nothing is bundled into an unstated blended rate. **Scale** Active enrolled students **Depth** Starter, Pro or Enterprise **Complexity** Campuses, workflows, roles and governance **Delivery** Migration, deployment, integrations and support ### Scale Active enrolled students Student volume sets the platform baseline. Larger enrolments sit in progressively better volume bands, so the marginal rate reduces as the institution grows. ### Depth Starter, Pro or Enterprise The plan reflects how much operational and governance control the institution needs — from connected core operations through to trust-level command. ### Complexity Campuses, workflows, roles and governance Multiple campuses, deeper approval chains and wider role structures change the shape of the rollout and the shape of the commercial. ### Delivery Migration, deployment, integrations and support Data migration, deployment profile, integrations and the support model are scoped explicitly rather than folded into an unstated blended rate. Plan architecture ## Three levels of institutional command, not three feature bundles. Each plan represents progressively deeper control over how the institution runs: connected core operations, then visibility and accountability, then trust-level governance across campuses. ### Starter Core school operations on one connected institutional backbone. Depth 1 of 3 The problem it solves Records, attendance, fees and results live in separate tools, so every question needs a person to reconcile an answer by hand. Best suited for - Schools replacing fragmented spreadsheets and disconnected tools - Institutions that need reliable core workflows before anything else - Institutions beginning on managed SquareCampus Cloud Deployment posture Managed SquareCampus Cloud, with standard onboarding and support. Capability themes - Student and staff records - Attendance workflows - Fees and reconciliation - Exams and reports - Parent and staff communication - Parent and staff mobile apps - SquareCampus-managed sign-in with role-based access - Audit history - Standard operational dashboards [Discuss Starter](https://squarecampus.com/demo/) ### Pro Operational command for institutions that need deeper visibility and accountability. Depth 2 of 3 The problem it solves The core runs, but leadership still cannot see what is slipping, who owns it, or whether an exception was ever closed. Best suited for - Growing schools taking on more operational complexity - Institutions that need management dashboards and workflow governance - Institutions introducing cross-functional accountability Deployment posture Managed SquareCampus Cloud, with priority implementation and support options. Capability themes - Everything represented in Starter - Owner command views - Richer operational analytics - Advanced exception routing - Workflow SLAs - Deeper auditability - Optional institutional single sign-on with Microsoft Entra ID - API and standard integration readiness - AEGIS eligibility or controlled access #### Institutional single sign-on Pro adds optional single sign-on with Microsoft Entra ID for the institution's own tenant, subject to technical onboarding. Staff sign in with their existing institutional accounts under the institution's own MFA, Conditional Access and user-assignment policies, and SquareCampus continues to govern authorisation. - Optional, never mandatory - Institution's own Entra ID tenant - Customer MFA and Conditional Access apply - SquareCampus-governed authorisation Single sign-on is an option the institution chooses, not a requirement. SquareCampus-managed credentials remain available in every plan, and an institution is not asked to change its directory to use SquareCampus. [Explore Pro](https://squarecampus.com/demo/) ### Enterprise Selected by governance need Institutional governance, cross-campus command and advanced controls for larger or more complex institutions. Depth 3 of 3 The problem it solves Central policy and local accountability pull against each other, identity and audit requirements outgrow ordinary controls, and no single view reconciles what every campus is actually doing. Best suited for - Educational trusts and multi-campus groups - Church-run school chains - Institutions balancing central policy with local accountability - Standalone schools with governance, identity or audit requirements Deployment posture Managed cloud, private-cloud or on-premises eligibility, with enterprise implementation governance and tailored support structures. Capability themes - Everything represented in Pro - Trust and campus hierarchy - Cross-campus command - Approval and governance chains with configurable exception ownership - Advanced policy and audit controls - Identity governance requirements, scoped during technical discovery - Deeper and custom integrations - Governed AEGIS access within an allowance - Advanced audit exports and data portability #### Identity governance Enterprise is differentiated by identity governance rather than by having SSO. Identity requirements across several campuses or directories, directory-group to role mappings, SSO enforcement policy, joiner-mover-leaver lifecycle controls, identity migration and identity audit controls are scoped as Enterprise requirements during technical discovery. - Multi-campus and multi-directory requirements - Directory-group to role mappings - SSO enforcement policy - Lifecycle and identity audit controls Enterprise is not Pro with more modules. It is selected when governance, identity, audit or cross-campus requirements sit above what ordinary controls provide. Identity governance requirements are established during technical discovery and set out in the proposal. [Design an Enterprise plan](https://squarecampus.com/demo/) ### At a glance SquareCampus plan comparison across operational scope, visibility, accountability, structure, integrations, intelligence, deployment and support. The licensing model is published; figures are issued in a written proposal after institutional discovery. | Dimension | Starter | Pro | Enterprise | | --- | --- | --- | --- | | Operational scope | Connected core operations | Core operations plus workflow governance | Cross-campus operations under central policy | | Leadership visibility | Standard operational dashboards | Owner command views and richer analytics | Trust-level command and advanced analytics | | Accountability model | Role-based access and audit history | Exception routing, workflow SLAs, deeper auditability | Approval and governance chains, advanced policy controls | | Institutional structure | Single campus | Single or growing campus operations | Trust and campus hierarchy | | Sign-in and identity | SquareCampus-managed credentials, role-based access | Credentials plus optional Microsoft Entra ID single sign-on | Identity governance: multi-directory, group-to-role mappings, enforcement policy, lifecycle (scoped) | | Integrations | Standard configuration | API and standard integration readiness | Enterprise integrations, custom integrations | | Mobile apps | Parent and staff apps included | Parent and staff apps included | Parent and staff apps included; white-label scoped separately | | AEGIS intelligence | Not included | Eligibility or controlled access | Governed access within an agreed allowance | | Chosen because | The core needs to work as one system | Leadership needs visibility and accountability | Governance, identity or audit requirements — at any enrolment | | Deployment | Managed SquareCampus Cloud | Managed SquareCampus Cloud | Managed, private-cloud or on-premises eligibility | | Implementation and support | Standard onboarding and support | Priority implementation and support options | Enterprise implementation governance, tailored SLA structures | Capability themes are indicative. Final inclusions, limits and service levels are set by the proposal and the signed order form. Small institution. Enterprise-grade control. ### Enterprise control is not reserved for large institutions. Enterprise is selected by governance requirement, not merely by enrolment. A standalone school may require institution-managed identity, advanced approvals, executive visibility, stricter auditability or governed intelligence even without operating a large campus network. Most institutions are well served by Starter or Pro. Enterprise exists for institutions whose governance, identity or audit requirements genuinely sit above them — not as a safer version of the same product. Reasons a single-campus school lands on Enterprise - Identity governance beyond a single tenant's single sign-on: enforcement policy, group-to-role mappings, lifecycle controls - Deeper approval chains and configurable exception ownership - Executive command views for a board or trustee group - Stricter access governance and advanced audit exports - Governed AEGIS access within an internal allowance - Implementation governance and support escalation policy Enterprise capabilities are institutional controls rather than open-ended service commitments. Governed AEGIS access, messaging, storage and third-party usage run within agreed allowances or on a metered basis, and implementation, migration and custom engineering are scoped as their own lines. Allowances and fair-use terms are set in the proposal and the order form. What Enterprise adds ## Enterprise is not Pro with more modules. An ordinary ERP grows by adding modules. Enterprise grows by adding institutional governance: the structure, command, identity, audit and deployment controls a trust or a complex institution actually has to run on. What Enterprise adds beyond ordinary ERP modules, by dimension. | Dimension | Ordinary ERP modules | SquareCampus Enterprise | | --- | --- | --- | | Institutional structure | Several schools run as separate instances or branches | Trust, school and campus modelled as one hierarchy: policy set once, executed locally, deviations recorded as exceptions | | Command | Consolidated reports prepared from each branch | Cross-campus command views built on the same records the campuses run on | | Governance | Approval steps inside individual modules | Approval and governance chains with configurable exception ownership across workflows and campuses | | Identity | User accounts per instance | Identity governance: multi-directory requirements, group-to-role mappings, SSO enforcement policy and lifecycle controls, scoped during discovery | | Auditability | Change logs per module | Advanced policy and audit controls, advanced audit exports and data portability | | Intelligence | Reports and dashboards | Governed AEGIS access within an agreed allowance: permission-scoped, source-grounded, audited | | Deployment and integration | Vendor cloud, standard connectors | Managed cloud, private-cloud or on-premises eligibility, enterprise integrations and implementation governance | Identity options ## Sign-in is the institution's choice. Authorisation is always SquareCampus's. The identity provider establishes who a person is. SquareCampus decides what that person may do: institution membership, campus scope, roles, workflow privileges, record access and operational permissions are governed inside SquareCampus and are never derived from an email address or domain alone. Identity and access options by plan. | Dimension | Starter | Pro | Enterprise | | --- | --- | --- | --- | | SquareCampus-managed credentials with role-based access | Included | Included | Included | | Microsoft Entra ID single sign-on for the institution's own tenant | Not included | Optional, subject to technical onboarding | Optional, subject to technical onboarding | | Sign-in mode chosen by the institution (credentials, both, or enforced SSO) | Credentials | Institution's choice | Institution's choice, with enforcement policy scoped | | Multi-campus and multi-directory identity governance | Not included | Not included | Scoped as an Enterprise requirement | | Directory-group to role mappings, lifecycle controls, identity audit | Not included | Not included | Scoped as an Enterprise requirement | | Authorisation: membership, campus scope, roles, records, workflows | Governed in SquareCampus | Governed in SquareCampus | Governed in SquareCampus | - Single sign-on is optional. An institution is not required to adopt it, and is not required to move between Google Workspace and Microsoft to use SquareCampus. - Standard sign-in authenticates identity only. It does not require access to email, files, Teams, SharePoint or other Microsoft 365 data. - Single sign-on authenticates users; it does not create or remove them. Automated provisioning and deprovisioning are a lifecycle requirement scoped under Enterprise. - Where institution-enforced single sign-on is configured, SquareCampus credentials are designed not to act as an ordinary alternative route around the institution's identity policy. Fit ## Who SquareCampus is priced for, and who it is not. SquareCampus is priced for institutions that want operational governance, workflow ownership, exception management, institutional visibility, accountability and auditability. To an institution that needs only the cheapest attendance, fees and report-card product it will look expensive, and that is a correct reading rather than a misunderstanding. Best suited to - Institutions where leadership wants to know what requires attention today, who owns it and whether it was closed - Trusts and groups balancing central policy with campus-level accountability - Institutions that need auditability, approval chains and role-scoped access as institutional configuration rather than as favours from a vendor - Institutions that expect their systems to interoperate rather than to be replaced wholesale SquareCampus may not be the right fit if - The requirement is limited to basic attendance, fee collection and report cards - The lowest possible licence price is the dominant selection criterion - The institution does not need workflow ownership, exception management, governance or cross-campus visibility - Leadership wants a tool for one office rather than an operating system for the institution Volume-based pricing ## The marginal rate reduces as enrolment grows. Student volume sets platform scale, and larger volumes use the shared platform foundation more efficiently. The commercial model reflects those economies rather than imposing a flat rate for every institution. The institution benefits from its own scale SquareCampus maintains one shared platform baseline — capacity, security, observability, workflow infrastructure and the operations behind them. That baseline does not multiply with every additional student. Larger institutions therefore receive the benefit of platform economies of scale. The marginal rate reduces as enrolment grows, while the selected plan reflects the workflow, analytics, governance and deployment depth required. An institution is not charged the entry rate indefinitely for growing. Platform foundation Shared capacity, security and operations. Greater utilisation Larger enrolments use that foundation more fully. Lower marginal rate The benefit returns to the institution. Pricing uses progressive, volume-based student bands. The chart shows the direction of the marginal rate as enrolment grows — the bands themselves are set out in your proposal. What shapes the proposal ## The inputs we establish during institutional discovery. A proposal is only useful if it reflects the institution as it actually operates. These are the dimensions mapped before commercial terms are issued. ### Active student count The billable enrolment basis for the term. ### Number of campuses Single campus, group, or trust hierarchy. ### Workflows selected Which operational areas move onto the platform. ### Migration volume and data quality How much history moves, and in what state. ### Integrations Accounting, identity, payments and existing institutional systems. ### Deployment profile Managed cloud, private cloud, or on-premises. ### Support and SLA requirements Response expectations and escalation structure. ### Governance and approval depth Approval chains, policy controls and audit expectations. ### AEGIS usage Whether governed intelligence is in scope, and at what depth. ### Communication and storage requirements Messaging volume and document retention. Exact commercial terms are issued after a short institutional discovery. [Begin discovery](https://squarecampus.com/demo/) Included versus separately scoped ## No hidden subsidies. No surprise implementation bill. The licence covers the platform capability represented by the plan, the standard SquareCampus parent and staff mobile apps, and the standard onboarding and support that belong to that plan. Complex legacy migration and data cleaning, bespoke integrations, custom engineering, premium implementation, private-cloud or on-premises deployment, exceptional SLA or support requirements and metered third-party usage are scoped and quoted as their own lines rather than folded into the licence. ### Data and migration - Legacy data migration - Historical data cleaning - Bespoke reporting ### Engineering and deployment - Custom integrations - Private-cloud deployment - On-premises deployment - White-label Android and iOS apps (One charge, full term) ### Identity governance requirements - Automated provisioning and lifecycle controls (Enterprise) - Multi-directory and multi-campus identity governance (Enterprise) - Identity migration (Enterprise) - Custom federation requirements (Enterprise) ### Implementation and support - Premium implementation services - Premium support SLA ### Metered third-party usage - SMS and WhatsApp usage (Passed through) - Payment-gateway charges (Passed through) - Excess storage (Metered) - Unusually high AEGIS usage (Metered) Each of these is quoted as a distinct line in the proposal. Metered third-party usage — messaging, payment gateways, storage — is passed through rather than marked into the licence. The SquareCampus parent and staff mobile apps are included in every plan at no additional charge. White-labelled Android and iOS apps, published under the institution's own branding and store listings, carry a single charge that covers the entire agreed term, whether that is one year or many. Founding Institutional Partners receive the white-labelled apps without the standard white-label charge. Founding-partner pilot ## The lowest-risk way to establish evidence before committing. A pilot is a measured operational exercise, not a trial account. It runs on a written baseline and closes against an agreed metric. For the two Founding Institutional Partner positions it runs inside that programme. 60–90 days Convert, extend or stop — decided on evidence. One campus or one workflow bundle, implemented with founder-level involvement, and closed against the baseline written down at the start. [Scope a pilot](https://squarecampus.com/demo/) · [Founding Institutional Partners](https://squarecampus.com/launch-partners/) **Scope** One campus, or one agreed workflow bundle. **Measure** One agreed success metric, written down before the start. **Ownership** Founder-led implementation, with a written baseline. **Close** Measured against the baseline — then convert, extend or stop. Procurement questions ## The commercial questions institutions ask before signing. Answers here describe how the model works. The signed order form governs the specific terms for your institution. **Is pricing public?** The licensing model is published on the pricing page; figures are issued in a written proposal after institutional discovery. One annual institutional licence, calculated through progressive student-volume bands and shaped by the plan selected (Starter, Pro or Enterprise), the institution's complexity and its deployment profile. A single published figure would be wrong for most institutions in both directions, so the proposal is written against the institution's actual enrolment, plan, complexity and deployment profile. **What is included in the licence, and what is scoped separately?** The licence covers the platform capability represented by the plan, the standard SquareCampus parent and staff mobile apps, and the standard onboarding and support that belong to that plan. Complex legacy migration and data cleaning, bespoke integrations, custom engineering, premium implementation, private-cloud or on-premises deployment, exceptional SLA or support requirements and metered third-party usage are scoped and quoted as their own lines rather than folded into the licence. Every separately scoped line appears in the proposal before signature. **How is student count determined?** Billable enrolment is agreed in the order form using active enrolled records. Growth may be reconciled through an agreed true-up mechanism, while reductions are normally considered at renewal. The signed order form governs in every case. **What happens as enrolment grows?** Billable enrolment is agreed in the order form using active enrolled students. The marginal per-student rate reduces as enrolment grows through successive volume bands; growth is reconciled through an agreed true-up mechanism, and reductions are normally considered at renewal. **What does Enterprise add beyond ordinary ERP modules?** Enterprise is selected by governance requirement, not by enrolment or module count. It adds the trust-school-campus hierarchy with policy set once and executed locally, cross-campus command views built on the records campuses run on, approval and governance chains with configurable exception ownership, identity governance requirements scoped during discovery, advanced policy and audit controls with audit exports and data portability, governed AEGIS access within an agreed allowance, and managed, private-cloud or on-premises deployment eligibility with enterprise implementation governance. **Is SquareCampus appropriate if we only need attendance and fees?** Usually not. SquareCampus is priced for institutions that want operational governance, workflow ownership, exception management, institutional visibility, accountability and auditability. To an institution that needs only the cheapest attendance, fees and report-card product it will look expensive, and that is a correct reading rather than a misunderstanding. Starter is the right conversation only when the institution wants those functions connected on one governed record with owners against exceptions. **Can we keep our existing ERP during the pilot?** Yes. A pilot is deliberately scoped to one campus or one workflow bundle, so the existing ERP keeps running and stays authoritative alongside it. Replacing anything is a later decision the institution takes once the evidence exists, never a precondition of starting. **Is migration included?** Legacy data migration and historical data cleaning are scoped separately from the annual licence, because the effort depends entirely on how much history moves and what condition it is in. The scope and its commercial treatment are agreed in the proposal. **Can SquareCampus run in our cloud account?** Private-cloud and on-premises deployment are available under Enterprise, subject to scoping. Deployment profile is one of the inputs to the proposal, and the resulting responsibilities are set out before implementation begins. **Is the mobile app charged separately?** No. The SquareCampus parent and staff mobile apps are included in every plan at no additional charge. White-labelled Android and iOS apps, published under the institution's own branding and store listings, carry a single charge that covers the entire agreed term, whether that is one year or many. Founding Institutional Partners receive the white-labelled apps without the standard white-label charge. **Can an institution use normal SquareCampus credentials?** Yes. Every plan includes SquareCampus-managed credentials with role-based access. Privileged roles are designed to carry additional sign-in verification, applied according to the institution's policy. Single sign-on is an option, not a requirement. **Does Pro support institutional single sign-on?** Yes. Pro adds optional single sign-on with Microsoft Entra ID for the institution's own tenant, subject to technical onboarding. Staff sign in with their existing institutional accounts under the institution's own MFA, Conditional Access and user-assignment policies, and SquareCampus continues to govern authorisation. The institution chooses the sign-in mode: SquareCampus-managed credentials only; SquareCampus credentials alongside institutional single sign-on; Institution-enforced single sign-on, where the institution's policy requires it and the configuration supports it. **Does SquareCampus access our Outlook or Microsoft 365 data?** No. Standard Microsoft Entra ID sign-in is used to authenticate identity. Access to email, files, Teams, SharePoint or other Microsoft Graph data is not required for sign-in. **Does single sign-on automatically create and remove users?** No. Single sign-on authenticates users. Automated provisioning, deprovisioning and joiner-mover-leaver lifecycle controls are identity governance requirements scoped under Enterprise rather than part of SSO. **What identity governance does Enterprise add?** Enterprise is differentiated by identity governance rather than by having SSO. Identity requirements across several campuses or directories, directory-group to role mappings, SSO enforcement policy, joiner-mover-leaver lifecycle controls, identity migration and identity audit controls are scoped as Enterprise requirements during technical discovery. The identity provider establishes who a person is. SquareCampus decides what that person may do: institution membership, campus scope, roles, workflow privileges, record access and operational permissions are governed inside SquareCampus and are never derived from an email address or domain alone. **Is GST included?** Quoted commercial figures are exclusive of applicable taxes unless the proposal states otherwise. Applicable Indian taxes are shown on the order form and invoices. **How is AEGIS usage handled?** AEGIS availability depends on the plan, and governed usage is part of the scoping conversation. Ordinary institutional use is covered by the plan; unusually high usage is treated as a separately scoped, metered dimension so it never distorts the base licence. **Can a trust contract cover multiple campuses?** Yes. Enterprise is built for trust and campus hierarchies, and a single trust-level agreement can cover multiple campuses with central policy and local accountability. Campus coverage is defined in the order form. **How many Founding Institutional Partner positions exist?** There are exactly two Founding Institutional Partner positions, ever: one school or eligible school institution, and one university. Once both positions are allocated, the programme closes permanently. A Founding Institutional Partner is not an ordinary customer. The position involves a strategic capital commitment under a separately executed agreement, material participation in product validation, and structured roadmap input. Next step ## Price the institution you operate — not a generic software package. Bring your campus structure, student volume, the workflows in scope, the migration you are carrying and the governance your board expects. We map them, then issue a written proposal against that reality. SquareCampus is priced for institutions that want operational governance, workflow ownership, exception management, institutional visibility, accountability and auditability. To an institution that needs only the cheapest attendance, fees and report-card product it will look expensive, and that is a correct reading rather than a misunderstanding. [Request a tailored proposal](https://squarecampus.com/demo/) · [Book an operational diagnosis](https://squarecampus.com/demo/) · [See how rollout works](https://squarecampus.com/rollout/)