Student information system: what an SIS is, what it isn't, and what it has to include

This market has a vocabulary problem, and it costs schools real money. Student information system, school management system, school ERP and school MIS are used more or less interchangeably by vendors, and each buyer arrives with a slightly different idea of what they are shopping for.

Most of that confusion is harmless. One instance of it is not: the difference between a student information system and a learning management system. Schools buy one expecting the other several times a year, and the discovery happens after the data migration.

This page is the counted version — what 46 real school systems actually ship — plus the distinctions that decide whether the thing you buy or build fits the institution you actually run.

SIS or LMS? The distinction worth getting right

They overlap in appearance and barely overlap in purpose.

A student information system is the system of record. Who is enrolled, in which class, with which guardians, present or absent on which day, what fees are owed and paid, what grade was awarded and stands on the transcript. It is the institution's administrative truth, and it is answerable to auditors, inspectors, funders and courts. Its defining property is that its records have to be right years later.

A learning management system is the delivery mechanism. Courses, content, assignments, quizzes, progress through material. Its defining property is that learners move through it.

The overlap is a single word — "grades" — and it hides the whole distinction. A grade in an LMS is the output of an assessment. A grade in an SIS is a record of attainment on a transcript. They are produced in different places, approved by different people, and corrected through different processes. Most schools need both systems and a defined handoff between them, which is why the question "does your LMS do attendance" almost always gets a yes that does not mean what the buyer thinks.

We maintain counted inventories of both markets — 46 school systems and 38 LMS platforms — and the capability lists barely intersect. If you take one thing from this page: decide which of the two you are buying before you look at a single demo, because both will demo well against the wrong requirement.

The counted core

Ranked by how many of 46 real school systems ship each capability. The 46 span 18 live commercial products, 13 open-source and developer-visible systems, 10 marketplace products, and 5 market and practitioner sources.

Capability	Systems	Share
Admin / principal portal	38	83%
Gradebook and marks entry	38	83%
Attendance and fee reports	37	80%
Classes, grades and sections	36	78%
Teacher portal	35	76%
Parent / guardian portal	35	76%
Fee structure and fee master	35	76%
Exam scheduling	33	72%

Eight capabilities above 70%, which is a much tighter core than most software markets. School systems have converged, and that is useful: it means a first delivery that covers those eight is recognisably a school system, and anything you add beyond them is a choice you should be able to justify.

What each one has to actually do

Admin portal — 38 of 46. Not a dashboard. A control centre where the things an office does every day are reachable without hunting. Test: time how long it takes to find and correct a misrecorded absence from three days ago. Practitioners complain about click depth more than about missing features, and this is why.

Gradebook and marks entry — 38 of 46. The decorative version is a grid you type into. The real version knows about assessment structure, handles a teacher entering marks for one class without seeing another's, and — critically — records a change to a submitted mark as an amendment rather than an overwrite. Test: change a grade after submission and look for who did it and when.

Attendance and fee reports — 37 of 46. Named reports with filters and exports, not a widget on a homepage. Schools have reports they are required to produce, and "we can build you a custom report" at extra cost is the most common integration complaint in this market. Test: ask for the specific report your office produces now, in the format it is produced in.

Classes, grades and sections — 36 of 46. Sounds trivial and is not: it carries the academic year boundary. What happens on the day the year rolls over, when every pupil moves up a class and last year's records must stay attached to last year's class? Test: ask to see annual promotion. It is missing from a surprising number of builds and every single generic AI-built one we have looked at.

Teacher portal — 35 of 46. Today-first: this morning's registers, this week's marks due, homework to set. The decorative version is a menu of modules. Test: open it as a teacher at 8:45 on a Tuesday and count how many taps to mark a register.

Parent portal — 35 of 46. Mobile first, because that is where parents are, with a child switcher for families with more than one pupil. This is the surface most likely to be built last and worst. Test: open it on a phone as a parent with two children in different year groups.

Fee structure and fee master — 35 of 46. The hardest of the eight. Real fee handling is date-effective and academic-year scoped, and it needs instalments, concessions, sibling discounts, scholarships and part payments. Test: apply a mid-year concession and see whether last term's invoices change. They should not.

Exam scheduling — 33 of 46. With admit cards and seat plans as contextual extras rather than defaults.

Attendance, which is harder than it looks

Attendance is the thing a school does most often and the capability most under-specified in every build we have seen. It is worth its own section because "mark present or absent" is not the requirement.

A register is a legal document in most jurisdictions. That single fact drives everything else: it must be retained, it must be amendable with a trace, and the amendment has to say who and why.

Sessions or periods, and probably both. Primary schools typically take two sessions a day. Secondary schools take a mark every period, and the two have to reconcile — a pupil present at registration who leaves at lunch is present for one and absent for the others, and the daily figure has to be derivable from that.

The codes are not present/absent. Real registers distinguish authorised from unauthorised, late-before-register-close from late-after, educational activity off-site, exclusion, illness, and approved absence. These vary by jurisdiction, and a system that hard-codes two states cannot produce the statutory return.

Retrospective amendment is normal, not exceptional. A note arrives on Thursday explaining Tuesday. The mark changes from unauthorised to authorised, and the original has to remain visible. A system that lets a teacher silently overwrite Tuesday has destroyed the document.

Who may amend, and for how long. Usually a teacher may set a mark and only the office may change it afterwards, often within a window. This is a permission rule with a time dimension, which is why it is skipped.

Test, in any demo or build: mark a pupil absent, then change it to authorised three days later, then produce the report. You are looking for the original mark still being visible, an attributed amendment, and a report figure that has moved. Most generic builds fail all three, because none of them is visible on a screen.

Six institutions, six different products

"School" covers institutions with genuinely different requirements, and the vocabulary alone will trip a build:

K-12 private, fee-paying. The fullest shape: parent portal, fee ledger, report cards.
Government or public. Fees often absent entirely; statutory reporting dominates instead.
Coaching centre. Batches and cohorts rather than classes and sections. Enrolment is continuous rather than annual, which breaks the academic-year assumption underneath everything else.
College or higher education. Course registration, credits and electives replace fixed class groups.
Online academy. No attendance in the physical sense, and the SIS/LMS boundary blurs.
Boarding school. Adds residential, pastoral and guardianship-at-distance concerns that no day-school product handles.

A specification that does not name the subtype produces the average of all six, and the average is a K-12 template with wrong words in it. If you are building, write the subtype in the first paragraph and write down which of the other five you are not building.

The guardian data model, which is where migrations die

If there is one technical decision that separates a school system that survives from one that has to be redone, it is this, and it is almost never discussed at the demo stage.

A guardian is not a text field on a student record. In reality:

A child can have several guardians with different rights — one who may collect them, one who may not, one who receives reports, one who may consent to a trip.
A guardian can have several children, often in different year groups, sometimes at different campuses. The parent portal has to present one login across all of them.
Guardianship changes. Custody arrangements change. A contact who may see a record this term may not next term, and the system has to be able to express that without deleting history.
Some contacts are emergency-only and must never receive routine communication.

Model that as parent_name and parent_email on the student row and everything downstream is wrong: the portal cannot show two children, communications go to the wrong adult, and — the one that matters — a person with no right to a child's information can end up receiving it.

This is also the single most common casualty of migration. Practitioners describe imports where guardian data landed in the wrong contact model and quietly broke reporting for a term. Every serious implementation guide in this market treats migration as its own project phase, and the schools that skip it are the ones still reconciling records at half term.

If you evaluate nothing else in a demo, ask to see a pupil with two guardians who have different permissions, and a guardian with two children in different year groups.

What practitioners actually complain about

From the research behind our own planner, the recurring pains are not missing features. They are:

Data migration, and specifically dirty guardian records.
Click depth on daily tasks — the register, the mark, the absence note.
Reporting gaps, where the required report is the one the system will not produce.
Mobile parent expectations, which have moved and which older systems have not met.
Security and vendor access — who at the supplier can see children's records, and under what controls.

Notice that four of those five are not solvable by adding functionality. They are consequences of how the system was designed, which is why "it has that feature" answers so few of the questions that matter here.

Scoping one that finishes

Name the institution subtype, and name the ones you are not building.
Decide SIS or LMS, and if both, define the handoff — where a grade is produced and where it becomes a record.
First delivery is the eight core capabilities, and nothing else.
Model guardians as their own entity with a relationship to students carrying rights. Do this on day one; it is not retrofittable.
Academic year is a real dimension, not a filter. Annual promotion is a named workflow, not something to work out later.
Permissions are enforced on the server, and a teacher can reach their own classes and no others. Prove it in both directions: the owning teacher must actually see their class, or an empty result for everybody looks like working isolation.
Name the reports you are required to produce before anyone builds a dashboard.
Treat migration as a phase, with validation errors logged rather than silently swallowed. An import that reports success while dropping rows is worse than one that fails.

Everything else — transport, hostel, library, HR, timetabling, communication channels — is genuine scope and genuinely optional for a first version. Each of them is a module in real products, and each of them is a project.

If you want the architecture side, web-based student information system covers hosting, who can see a child's record, and what breaks specifically in browser-delivered school software. What a school management system includes and how to build one cover the build path, and build vs buy works through the decision.

If the thing you actually need is course delivery rather than a system of record, that is the other product — features of a learning management system is the counted list for it.

And if you are pointing a coding agent at this, the School Management planner is the specification we hand ours — the institution subtype locked first, the guardian model made explicit, and every module an evidenced include, defer or skip rather than a guess.