Skip to main content
Schoolyi

School ERP modules

Find the modules your school needs first

School management software modules for admissions, student records, timetable, attendance, fees, exams, and family portals. Start with one student record and the academic calendar; later modules read those two.

Students on a vibrant modern school campus between classes

One catalog, connected workflows

Search by the job your team needs to complete. Every module links back to shared student records, academic dates, permissions, and reporting instead of creating another isolated data store.

Adoption order

Which modules to adopt first, and why the order matters

The modules depend on one another. Adopting them in dependency order means each phase builds on data that is already correct, instead of recalculating what an earlier phase got wrong.

  1. Foundation

    Student identity and the academic calendar

    Nothing else can be correct until a student exists once, in one place, and until the platform knows which days the school is actually open. Every downstream number, attendance percentages, fee due dates, timetable slots, term boundaries on a report card, is calculated from these two things. Schools that skip straight to the module causing them the most pain end up rebuilding it once the roster is right.

    Why not later: Every other module reads the student record and the calendar. Configuring them later means recalculating everything already entered.

  2. Phase one

    Admissions and fees

    These are usually the two workflows with the clearest cost of the current process, and they sit next to each other for a reason: admissions creates the record and the guardian relationship that fee invoicing depends on. Running admissions in the platform while fees stay in a spreadsheet means re-keying every family, which is the specific duplication the platform is meant to remove.

    Why not later: Fee ledgers attach to the student and guardian records admissions creates. Reversing the order means creating families twice.

  3. Phase two

    Timetable, attendance, and the family portal

    Once the roster is trustworthy, teaching operations can move across. Timetable comes before attendance because the register is generated from it, and the family portal comes after both because it is the surface where errors in either become visible to parents. Opening the portal before attendance and fee data are reliable is the most common way schools lose family confidence in a new platform.

    Why not later: Registers are generated from the timetable, and the portal exposes attendance and fee data to families. Both need to be right first.

  4. Phase three

    Assessment, reporting, and leadership views

    Examinations and report cards come last, not because they matter least but because they aggregate everything above. A report card reads marks, attendance, and term dates; a leadership dashboard reads all of it plus fee collection. Moving assessment first produces reports that draw on data still living elsewhere, which is worse than leaving assessment where it is for another term.

    Why not later: Report cards and dashboards aggregate marks, attendance, calendar, and fee data. They are only as accurate as the modules feeding them.

Module selection FAQ

What schools ask when deciding how much of the platform to adopt, and in what order.

Do we have to adopt every module?+

No. Schools commonly run admissions, student records, and fees for a full year before adding anything else.

The modules read one shared student record, so adding a module later does not require re-entering data. A module you skip does not leave a gap the others cannot work around.

Which module should we start with?+

Start with the workflow currently costing your team the most hours, provided student records and the academic calendar are configured first.

In practice that is usually admissions or fees. Starting with the most painful workflow gives the rollout visible early value, which matters for staff confidence more than technical sequencing.

Can modules run alongside our existing systems?+

For a transition period, yes, and most schools do this for at least a term.

Avoid running two systems permanently for the same workflow, because the records diverge and staff learn to trust whichever one they entered data into. Set a date to switch off the old process when you plan the module.

How are modules connected?+

They read the same student records, guardian relationships, academic calendar, and permission model rather than exchanging copies.

A student marked as withdrawn stops appearing in registers, stops accruing fee instalments, and disappears from the parent portal because all three views read one record, not three synchronised ones.

What if a module does not fit how our school works?+

Tell us during evaluation with the specific case, not the general requirement.

Some constraints are configuration and can be changed; others are architectural and cannot. Knowing which one you are dealing with before you sign is the difference between a configuration task and a workaround you live with for years.

Do modules cost extra individually?+

Pricing is quoted for the scope you adopt rather than assembled from a public per-module price list, because student count, campus count, and implementation effort change the figure more than the module mix does.

The pricing page explains the assumptions behind a quote, so schools can compare a platform on the work required to go live.

Buyer guides

School software topics school leaders search for

Focused guides, not generic country templates. Each page explains how Schoolyi connects admissions, fees, exams, and family portals.

Browse all software guides ยท Product articles

Students walking together across a school campus at sunset

Need help choosing phase one?

Use the module finder or bring your student count, curriculum, and first-year priorities to a focused walkthrough.

Already using Schoolyi? Sign in