Skip to content
All work / Application and Software Development

ITQAN ERP: multi‑campus school platform

A white-label school ERP covering multiple branches and ownership layers - admissions, academics, LMS, attendance, HR, payroll, finance, cheques, budgets, inventory and assets - through five role-based dashboards.

Client

ITQAN

Year

2026

Services

Product Architecture, Multi-Tenant Platform, ERP Modules, Web, Mobile and Desktop

Links

N/A

ITQAN ERP: multi‑campus school platform

Overview

Overview

ITQAN ERP is a complete schooling system: admissions, academics, learning, attendance, HR, payroll, finance, cheques, budgets, inventory, fixed assets, tasks, communication and audit - built as one platform that serves many school organisations rather than one school at a time.

It is our flagship build. Multi-branch by design, configurable per owner, departmental in its permissions, and delivered through five different dashboards depending on who is looking at it.

The problem

A school group rarely runs on one system. Head office keeps its own reports, each campus keeps registers, finance runs on vouchers and spreadsheets, and the same student exists three times in three places with three different names spelled three different ways.

The business asked for a system that could carry the whole organisation - and then be reused for the next school group without starting again.

One platform, many schools

ITQAN ERP is a white-label platform. Each school organisation is onboarded as its own environment with its own branding, hierarchy, academic calendar, fee rules, approval chains and enabled modules.

Nothing client-specific is hard-coded into the product. The same engine runs behind every client, and a new school is configured - not quietly forked into a separate codebase.

Five experiences, one engine

The interface is not one dashboard with permissions bolted on. There are five distinct experiences, each designed for how that person actually works:

  • Executive - the group at a glance: performance, finance, HR, attendance and risk.
  • Head Office - directors, managers and supervisors overseeing campuses, approvals and audits.
  • Campus - principals, accountants, reception and storekeepers running the day.
  • Teacher - classes, attendance, lessons, homework, marking and results.
  • Student / Parent - only their own information: attendance, assessments, homework, notices, invoices and receipts.

Every experience reads from the same business engine and the same rules, so a fee calculated at reception is the same fee the parent sees.

The operational modules

The platform runs the full school year: admission enquiries through enrolment and student lifecycle, academic periods and results, a real learning management system with lessons, assignments and quizzes, employee records and recruitment, payroll with allowances, deductions and settlements, and attendance that feeds both academic reporting and payroll.

Around that sit school finance with vouchers, invoices and reconciliation; cheque management with approval and lifecycle tracking; budgets with allocation and variance; a saleable store for uniforms and books with variants, transfers and stocktaking; fixed assets with custody, transfer and depreciation; and tasks, official notices, internal messaging and audit follow-ups.

Money and governance

Financial work is treated as financial work. Vouchers, receipts, cheque issuance, budget revisions and payroll runs follow approval flows, preserve their history and reconcile against the ledger rather than overwriting it.

Historical periods stay reproducible. Changing a policy today does not silently rewrite a closed month, and every consequential action leaves a record of who did it, when, and under what authority.

The developer console

The platform is operated from a separate Aumenso-only console: client registry, deployment status, white-label theme builder with preview and rollback, onboarding workflow that provisions a new school environment, engineering workspace, and a permanent delivery timeline covering every phase of the build.

It is the part of the product that makes the platform a product rather than a set of custom projects.

Web, mobile and desktop

The web application is the operational home. Teachers and parents are reached through the mobile apps, and a desktop client handles the heavy administrative workflows - all sharing the same authorised backend, so no business rule is reimplemented on the client.

Outcome

A schooling system that an entire organisation can run on: multiple campuses, multiple ownership layers, departmental permissions and five role-based dashboards, from one configurable platform.

The Challenge

A school group was running its campuses on separate registers, spreadsheets and paper vouchers, so the same student and the same rupee appeared in several systems that never agreed with each other. Leadership could not see the group as one business, while each campus needed its own controls - and whichever system was built had to be reusable for the next school group without a rewrite.

Our Approach

We built a configurable multi-tenant platform rather than a school application: organisational hierarchy, departments, roles and scopes are per-client configuration, and the same engine serves every deployment. On top of it we delivered the operational modules in phases - students, academics and LMS, then HR and payroll, then finance, cheques, budgets, inventory and assets - and wrapped them in five purpose-built dashboards so an executive, a principal, a teacher and a parent each see the system their job requires rather than the whole database.

Results

5

Role-based dashboards

16

Operational modules

1

Platform, many schools

"Configured per school, never rebuilt per school."

— The aumenso team

Have a project like ITQAN ERP: multi‑campus school platform?

Let's talk about how we can help you achieve your goals.