Learner administration is shaped by programmes, cohorts, prerequisites, attempts, progression and awards, not a simple customer account. We build systems that join this academic record to admissions, scheduling, fees and student services while preserving institutional policy.
Programme regulations change while continuing students remain governed by earlier versions or transition rules. Prerequisites, electives, credit limits and award requirements must be evaluated against the correct curriculum and academic period.
Teaching availability, room capacity, equipment, accessibility, cohort combinations and subject choices create a dense scheduling problem. Late enrolment and room changes must be managed without producing clashes or losing communicated versions.
Marks pass through entry, moderation, approval, reassessment and sometimes appeal. The transcript must distinguish attempts and approved outcomes, with corrections controlled rather than allowing an administrator to overwrite history.
Charges can depend on credits, residency, programme, stage and optional services, while payment may be split among learner, sponsor and funding body. Refund and withdrawal rules operate on academic dates that do not always align with accounting periods.
Staff, learners, guardians and support teams need different views of sensitive records. Age, consent, pastoral responsibility and jurisdiction affect disclosure, so broad role access is rarely sufficient on its own.
Off-the-shelf business ERP can collect fees and buy supplies, but it rarely understands that a learner belongs to a curriculum version, takes several attempts, interrupts study or earns an award through a particular combination of credits. Encoding these decisions as manual spreadsheets makes progression slow and difficult to audit.
We express academic periods, programme structures, enrolments, attempts and outcomes as first-class records. Policy rules are effective-dated and explain their result, while exceptional decisions follow approval rather than bypassing the rule. Finance receives controlled charge and payment events without becoming the authority for academic status.
An education system commonly connects to a learning management system, identity provider, finance, library, payment gateway, attendance devices and government or awarding-body returns. Person, course, class and assessment identifiers must remain stable across these boundaries. Simply matching by email creates duplicates when identities or affiliations change.
We define authoritative fields and synchronisation direction for each interface. Enrolments and class groups can provision learning access, while final approved outcomes return under controlled status rules. Privacy, safeguarding, retention and statutory reporting obligations vary; the institution’s counsel and auditors define them, and technical controls implement the documented requirements.
Implementation planning works backwards from admissions, registration, teaching, assessment and award milestones. A pilot may cover one school, programme family or intake, but it must exercise a complete learner journey and period close. Opening data includes active applications, enrolments, curriculum versions, balances and unresolved assessment cases.
Further phases introduce self-service, timetabling, attendance and advanced reporting after core records are reconciled. Cutover avoids critical registration and results windows, with read-only legacy access where full history migration adds risk. Registrar, academic and finance owners sign off their respective rules and control reports.
Education ERP manages the institutional learner record, curriculum, enrolment, fees, progression and awards. An LMS delivers learning activities and content; the two usually exchange users, classes and approved outcomes.
Yes, but their academic structures and safeguarding duties differ, so they should not be forced into one configuration. The data model and workflows are adapted to the institution’s programmes, periods, governance and reporting needs.
Rules and programme structures are versioned by effective period, with explicit transition arrangements where required. Each learner remains linked to the applicable requirements, and approved substitutions are recorded rather than changing the curriculum silently.
Yes, where the LMS provides supported APIs or standards-based interfaces. Integration typically provisions classes and enrolments and returns selected results, with clear rules for withdrawals, repeats and late changes.
We profile identifiers, programme versions, enrolment states, attempts, credits and approved awards before transformation. Reconciled summaries or read-only archives may be safer than forcing incomplete history into a new transactional model.
Share the workflows, records, exceptions and integration boundaries the system needs to support. We will help define the technical scope.