Pricing that scales with the institution — not with software complexity.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

Quoted commercial figures are exclusive of applicable taxes unless the proposal states otherwise. Applicable Indian taxes are shown on the order form and invoices.

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.

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.

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.