School Management System · School ERP
One student record, from enquiry to year end.
A system built around the record a school actually works from: the class a student sits in, the attendance marked against them, the fees owed, the results published, and what the parent is allowed to see. Built for how your school runs rather than fitted to somebody else’s modules.
Branditify builds these to order. There is no school portal to log into here — the page describes the system and what a build has to get right.
AdmissionsA family asks about a place. Nobody is a student yet, and what they said here is the beginning of the record rather than a note that gets thrown away.
AdmissionsThe form, the documents and whatever the school needs to decide. The state that answers "what is this waiting on", which is where most admissions time is lost.
AdmissionsA place is offered and accepted. This is the handover most schools do by hand, retyping a family into a student sheet that knows nothing about the application.
OfficeThe student record exists, and it is the application grown up — same family, same documents, same history, now with a class and a section.
Class teacherThe daily record. Its value is not the count at the end of the term — it is that an unexplained absence can reach the right person on the day it happens.
AccountsThe term’s fee cycle is open against this student. What the school needs to know is who has paid, who has not, and who has already been reminded.
AcademicsAssessment, entry, review, publish. The record carries the result rather than a spreadsheet named after the exam, so next year can still read it.
OfficePromotion into the next year. The new year is a new class and a new section — and the year just finished stays readable rather than being written over.
- Guardian
- Rohan Mehta · father · primary contact
- Class
- Grade 6 · Section B · 2026–27
- Attendance
- Marked daily · one absence needs a reason
- Fees
- Term 2 cycle open · not yet paid
- Result
- Not yet
- Next school action
- Send the fee reminder · owned by accounts
Illustrative interface · sample data
Fees: The term’s fee cycle is open against this student. What the school needs to know is who has paid, who has not, and who has already been reminded.The point is not that the school owns more software. It is that the student stops becoming a new row in a new sheet every time the school changes task — so the answer to "what does this child still need from us" is on one record instead of in four people’s heads.
The problem underneath
One child, seven places, and no single record that knows all of it.
Nobody designed this. It accumulated — a form here, a sheet there, a register that works perfectly well until somebody needs it in a hurry.
- 01The admission formEverything the family told you, filed once and rarely opened again.
- 02The student sheetThe master list. Usually correct, usually one person’s.
- 03The attendance registerAccurate for the day, hard to answer questions from later.
- 04The fee sheetWho owes what, reconciled by hand at the end of the term.
- 05The exam sheetOne per assessment, named after the assessment rather than the student.
- 06Notices and messagesWhat the school told parents, and no record of who actually saw it.
- 07A phone callThe most important part, and the only place it exists.
Every one of these does its job. What is missing is anything holding them together, so a simple question — has this child’s absence been explained, and does the family know about the fee — takes three people and a search through a folder.
This is not an argument against your registers or your spreadsheets. A register is a genuinely good tool and a school will always take phone calls. The problem is not that each tool exists; it is that the same student becomes a different, disconnected row in every one of them.
- What is a school management system?
- Software that connects a school’s operational records around one student — admissions, the student record itself, guardians, class and section, attendance, fees, exams and results, and what parents are allowed to see. The distinction from general business software is that it understands a school year: a student belongs to a class for a year, is promoted out of it, and keeps a history that has to stay readable afterwards.
- What is school ERP software?
- The same category under the name most vendors sell it by. ERP borrows a manufacturing term for the idea that one system runs the whole operation rather than each department keeping its own book. In a school that means admissions, students, attendance, fees, exams and communication sitting on shared records instead of being reconciled between departments by hand — which is why the two phrases return almost the same results.
The handover that costs the most
The application should become the student, not be replaced by one.
In most schools admission ends with somebody retyping a family into a student sheet. Everything the admissions team learned stops at that moment.
- The familyNames, relationship, who to call first, and who else may be called.
- Contact detailsEntered once, by the family, in their own spelling.
- DocumentsWhat was submitted, what was verified, what is still outstanding.
- The grade applied forAnd what was actually offered, if the two differ.
- What was saidThe conversation that explains the decision, still attached a year later.
Nothing in that list is difficult to keep. It is lost because the admission record and the student record are two different files in two different tools — and the retyping is where the phone numbers start to disagree.
- How does admission become a student record?
- By being the same record rather than a copy of one. The enquiry becomes an application, the application is approved, and enrolment turns that same file into a student — carrying the family, contacts, documents and history forward instead of asking the office to retype them. The practical test is whether a class teacher in March can still see what the family told admissions in January.
The distinction everything else depends on
A guardian is not a student, and a family is not one row.
The commonest structural mistake in a spreadsheet-run school, and the hardest to unpick once fees and notices are attached to it.
Guardian details on the student row
Rohan Mehta appears twice, once per child. His number is updated on one row and not the other, and nobody can answer what this family owes in total.
One guardian, linked to each student
Rohan Mehta is one contact linked to Aanya in Grade 6 and Arjun in Grade 3. Each child keeps their own record, attendance and result; the family is visible across both.
- A phone number changes once, for both children
- Fee reminders can be sent to a family, not to two unrelated rows
- A notice for one class does not reach the wrong sibling
- Each child keeps their own attendance, results and history
Families are more varied than a data model likes, and it is worth deciding early which arrangements a school actually needs — a second contact, a guardian who is not a parent, a family where only one adult may collect. Building for every possible structure costs more than building for the ones your school has.
- Can one parent account connect to multiple students?
- Yes, and this is the structure worth getting right first. One guardian record links to each child rather than being copied onto every student row, so a phone number is updated once and a parent signs in once to see both children — while each child keeps their own class, attendance, fees and results. Copying guardian details onto each student row is what makes contact details drift apart and fee reminders go out twice.
The daily record
Attendance is only useful if somebody does something with it.
A register that is filled in perfectly and read at the end of term is a compliance exercise. The value is in the day.
- MonPresent
- TuePresent
- WedAbsent
- ThuPresent
- FriPresent
What Wednesday should produce
Not a figure at the end of the month. A named person seeing that one absence has no reason against it, and a family who can supply one — on Wednesday, while anyone still remembers.
Which is why this scene shows one child’s week rather than a percentage. A percentage is the thing you look at afterwards; the absence is the thing you can still act on.
How attendance is captured is a scoping decision, not an assumption. Marking on a phone in the classroom, marking in the office from a paper register, or something else entirely — each has a different cost. Nothing on this page claims biometric, card, face or transport-based attendance; those are separate pieces of hardware and work, and are only included where a school asks for them and the build accounts for them.
- How does attendance management work in a school management system?
- A class teacher marks the day against the class, and each mark lands on the student record rather than in a separate register. What makes it worth having is the follow-up: an absence with no reason attached becomes a visible task for a named person, and the guardian linked to that student is the one contacted. The end-of-term summary falls out of the daily record rather than being compiled from it.
The cycle that repeats
What the school needs to know is who has paid, who has not, and who has already been asked.
Fee management in a school system is a record of state. It is not, and should not pretend to be, your accounts department.
- 01The cycle opensA term or instalment becomes due against the student, under whatever structure the school actually uses.Done
- 02ExpectedWhat this student owes for this cycle, including whatever concession or sibling arrangement applies to them.Done
- 03ReceivedWhat has come in against it, and what remains. Recorded, with a receipt the family can see.Open
- 04RemindedWho has been contacted and when — so the same family is not asked three times or forgotten entirely.Waiting
- 05ClosedSettled and kept against the year, so a question next March has an answer.Closed
Fee management is not accounting software
A school system can track what a student owes, what arrived and what is outstanding, and that is genuinely most of the daily work. It does not replace a general ledger, tax filing or bank reconciliation, and it should not claim to. Where a school needs those to agree, that is a connection to be scoped rather than a module to be assumed — and no payment provider, gateway or accounting product is named or claimed on this page.
No amount appears anywhere in this scene, deliberately. What a school needs from a screen is the state of the cycle; the numbers belong on the receipt.
- How does school fee management work?
- By holding an expected amount against each student for each cycle, then recording what arrives against it so the outstanding position is always visible on the student rather than reconstructed from a sheet. The part schools value most is usually the reminder history — knowing which families have already been contacted stops the same parent being asked twice and stops others being missed entirely.
- Does school fee management replace accounting software?
- No. It tracks what is owed, what was received and what is outstanding against each student, which is the operational half of the job. Accounting — the ledger, tax, reconciliation with the bank — is a different discipline with its own software and its own obligations. Sensible builds keep the two apart and, where the school needs them to agree, define how figures move between them rather than pretending one system does both.
The academic record
Four steps between an assessment and a parent seeing a result.
Each one is a state somebody is responsible for, and each is a place a result can sit for a week because nobody knows it is waiting.
- 01Assessment definedWhat is being assessed, for which class, and out of what.Done
- 02Marks enteredBy the teachers responsible, against the students in their class.Done
- 03ReviewedChecked before anybody outside the school sees it. The step most often skipped and most often regretted.Open
- 04PublishedA deliberate act with a named owner — not a file appearing in a folder.Next
- 05Visible to the familyOn the student record, where next year can still read it.Next
The useful question is not "can it store marks". It is whether the school can tell, at a glance, which classes are still waiting on entry and which results have not been published.
How a result is calculated and what a report card looks like are school-specific and often board-specific, and this page claims neither. No board grading scheme, rank generation or automated result calculation is offered here — what a build does is implement the scheme your school actually uses, established during scoping rather than assumed from a template.
- Can exams and results be published to parents?
- Where publishing is in scope, yes — and it should be a deliberate step rather than a side effect. Marks are entered by the teachers responsible, reviewed before anyone outside the school sees them, then published by a named owner, at which point the result appears on the student record and in the parent’s view. Keeping review and publication as separate states is what stops a provisional mark reaching a family.
The same record, a different lens
A parent should not have to ring the office to find out whether their child was in school.
This is where the whole thing pays off. Not a second system kept in step — the same student record, seen through what a parent is allowed to see.
- Attendance
- Their child’s own record, and a way to explain an absence without a phone call.
- Fees
- What is due, what has been paid, and the receipt for it.
- Results
- What has been published, when the school chose to publish it.
- Notices
- What the school sent, still there a week later when it is actually needed.
- Documents
- What was submitted at admission, and what the school still needs.
- Both children
- One sign-in for a family, each child kept separate.
And what a parent must not see
Another family’s child, another family’s fees, staff notes, unpublished marks, or anything about the class beyond their own child. A parent view is a permission model before it is a screen, and getting that wrong is worse than not building it.
The school gains as much as the family does. Most of what an office answers by phone is a question the record could have answered — and every one of those calls is a person stopping what they were doing.
- Can parents see attendance, fees and results?
- That is usually the main reason a school commissions one. A parent signs in and sees their own child — attendance, the fee position, published results, notices and outstanding documents — and nothing about anybody else’s. What is visible is a decision the school makes rather than a default: unpublished marks and internal notes stay internal, and a parent with two children sees both from one sign-in.
- How do schools send notices and communicate with parents?
- Through the portal itself, and through whichever additional channels the school selects. Branditify names no messaging provider on this page — email, SMS, an app notification and a chat channel each depend on a provider the school chooses, with its own cost and its own rules. What the system contributes is that a notice is addressed from the record: this class, these guardians, and a note of what was sent.
The shape a school actually has
A student belongs to a class for a year — and then does not.
The academic year is the thing that makes school software different from every other business system, and the thing spreadsheets handle worst.
- Academic year2026–27. Everything below hangs off it, and next year is a different set.
- GradeGrade 6. The academic level that assessments and reporting attach to.
- SectionSection B. The actual group of children who sit together and share a class teacher.
- Class teacherThe person who marks attendance and is asked first when something is wrong.
What happens at year end
- The year closesAttendance, fees and results for 2026–27 are settled and kept with that year.
- A decision is recordedPromoted, repeating, transferred or left. All four are real outcomes and all four need somewhere to live.
- The new year opensGrade 7, a new section, a new class teacher — the same student record underneath.
- Last year stays readableNot overwritten. A parent asking in October about last year’s result should get an answer.
This is the workflow that most exposes a spreadsheet. A sheet promotes a child by editing the row, and last year quietly disappears.
- How does academic year rollover work?
- The finishing year is closed rather than edited: its attendance, fees and results stay attached to it. A decision is then recorded for each student — promoted, repeating, transferred or left — and the promoted ones open a new year with a new grade and section against the same student record. The test of whether it was done properly is whether last year is still readable in six months.
- How does a school management system handle classes and sections?
- As something a student belongs to for one academic year, not as a permanent attribute. Grade is the academic level that assessments and curriculum attach to; section is the group that actually sits together and shares a class teacher, which is what attendance and most day-to-day communication run on. Because both are scoped to a year, moving a child between sections or into the next grade changes the current placement without rewriting their history.
The three questions every buyer asks
It runs the school. It does not teach the lesson, and it is not a sales pipeline.
All three are real systems answering real problems. Schools frequently need more than one, and knowing which does what is most of the buying decision.
School management system
Answers: what is happening with this student?
- Admissions and the student record
- Guardians, classes and sections
- Attendance and fees
- Exams, results and the parent view
An LMS
Answers: what is this student learning?
- Courses, lessons and material
- Assignments and submissions
- Assessments inside a course
- Learning progress over time
Knows the learning, not the school. It cannot tell you whether the fee was paid or who to ring about Wednesday.
LMSA CRM
Answers: who might join us?
- Enquiries and where they came from
- Follow-up and ownership
- A pipeline with stages
- Conversion into an admission
Stops at the admission. Knows nothing about the class, the register, the fee cycle or the result.
CRMA school system contains CRM-shaped things before admission and touches learning after it. What it adds is the middle — the year in which a child is actually a student — and that is where the office’s week goes.
- What is the difference between school ERP and an LMS?
- A school ERP runs the institution: admissions, student records, attendance, fees, exams and parent communication, used mostly by administrators and office staff. An LMS runs the classroom: lessons, material, assignments and learning progress, used mostly by teachers and students. They meet at the student and the class, and they answer different questions — whether a child was present and paid for, versus what that child is learning.
- Does a school need both an ERP and an LMS?
- Many schools end up with both, because they solve different problems, and it is reasonable to start with whichever is hurting. A school losing time to admissions, registers and fee chasing needs the operational system first; a school whose teaching has moved online needs the learning platform first. When both exist they should agree on who the students and classes are, which is a connection worth defining rather than leaving to two separate imports.
- What is the difference between school ERP and a CRM?
- A CRM handles the family before they join — the enquiry, the follow-up, whose job it is to call back. A school management system takes over at admission and carries the student through the year: class, attendance, fees, results and what the parent sees. Some schools run a CRM for admissions and hand over at enrolment; others let the school system cover the enquiry stage too. The handover point is a design decision worth making deliberately.
The honest comparison
Most schools should buy one of the established products.
This is a crowded, mature category with capable vendors, and pretending otherwise would not survive one demo. Here is where each answer actually wins.
Buy an established product when
- Your admissions, fees and attendance work broadly the way most schools work
- You want it running this term rather than next year
- You are happy to adapt the school to the software where they differ
- You need a mobile app immediately and do not want to fund one
- There is no in-house person to talk to a development team
A custom build earns its place when
- Your admissions or fee structure keeps needing workarounds in the product you have
- A group runs several branches that must share governance but not data
- The parent experience is part of how the school is positioned
- Systems you already depend on have to connect properly, not by export
- Your roles and permissions do not fit the vendor’s idea of them
- Reporting the management actually reads cannot be produced without manual work
The honest signal is not dissatisfaction with a vendor — it is workarounds. When a school is maintaining a parallel spreadsheet to make its software usable, it is already paying for a custom system without owning one.
- Custom school ERP or off-the-shelf school software?
- Off-the-shelf is the right answer for most schools: the category is mature, the products are capable, and buying is faster and cheaper than building. A custom system earns its place when the school keeps having to work around the product — an unusual fee structure, a group with several branches, a parent experience the school wants to own, or integrations that only work by export. The reliable signal is a parallel spreadsheet kept alive to make the existing software usable.
Getting what you already have into it
Everything is in a spreadsheet, and that is the normal starting point.
It is also the part of a school project most often underestimated — by us as much as by anybody.
- Student master sheet
- Admission exports
- Fee records
- Attendance history
- Past results
- Guardian contacts
- Scanned documents
- 01See what exportsWhat the current system or sheets can actually produce, in what shape. Usually less structured than remembered.
- 02Read a real sampleOne class, fully. It tells you more about consistency than any description of the process.
- 03Map the fieldsWhich column is the student, which is the guardian, and what the ones nobody can explain contain.
- 04Clean and de-duplicateSiblings entered as unrelated families and one child under two spellings are the standard findings. Merging them is the school’s decision, not the software’s.
- 05Load and verifyAgainst the source, by somebody who knows the school well enough to notice what is wrong.
Not every historical record moves cleanly, and promising otherwise would be dishonest. Attendance from years the school did not keep digitally, results that exist only on paper, and documents nobody scanned are the usual three. What can be recovered is knowable in the first pass, and deciding deliberately what to leave behind is better than discovering it later.
- Can old school data be moved from Excel?
- Usually most of it, and a first pass over one real class tells you which parts. The predictable difficulties are siblings that were never linked, the same child under two spellings, attendance from years that were only ever on paper, and documents nobody scanned. Deciding what to bring across is a business decision taken early — most schools bring current students and recent history, and leave the rest archived.
Who can see what
A school system holds information about children. That changes how it is designed.
Not an enterprise permissions framework — four questions, answered honestly for each kind of person who signs in.
- Who can see it?A class teacher usually needs their own class, not the whole school.
- Who can change it?Marking attendance and editing a student record are different rights.
- Who can publish?Results and notices reach families, so publishing is its own permission.
- Who can see money?Fee positions are sensitive inside a school as well as outside it.
- Management
- The whole school, including the fee position.
- Office / admin
- Student records, admissions and day-to-day operations.
- Class teacher
- Their own class — attendance, marks, and the families in it.
- Accounts
- Fees across the school, usually without editing academic records.
- Parent
- Their own children, and nothing else.
On data protection, plainly
Branditify makes no data-protection, privacy or education-sector compliance claim on this page, and treat any vendor that does with caution — obligations attach to the school and depend on where it operates, whose data it holds and what it does with it. What a build can do is settle the questions those obligations turn on: what student information is stored, who reaches it, what parents and students may see, how long it is kept, what deletes it, what can be exported, and what activity history the school needs. Establishing that with you is the work; asserting compliance on your behalf is not something a software page can honestly do.
- Who owns the student data?
- The school does. The records, the configuration and any code written for you are yours, handed over as agreed in scope, and a school should ask what an export looks like before signing anything — with any vendor. There is no per-student fee and no licence to renew on a system built for you. The separate and more important question is not who owns the data but who may reach it, which is why the permission model is settled before the architecture is.
What the records should be able to answer
Not a dashboard. Six questions somebody actually asks on a Monday.
A report is only worth building if somebody acts on it. Each of these is answerable only because the record underneath is connected.
- 01Which applications are waiting on us?And which are waiting on the family.
- 02Which absences have no reason against them?The one that matters today.
- 03Which families have not been reminded about fees?As opposed to reminded twice.
- 04Which results are entered but not published?The week-long gap nobody sees.
- 05Which classes have incomplete records?Before somebody needs them, not after.
- 06What does this family owe us, across both children?Answerable only if the guardian is one record.
Every one is a question about the record rather than a chart. Where a school wants an analytical layer on top of it, that is its own piece of work.
Dashboards When the reporting itself is the project
What changes the size
What makes one school system larger than another.
Not the number of students, which barely moves the build.
- Branches and governanceOne school is straightforward. A group sharing some records and deliberately not sharing others is the single biggest driver.Effect on scope: 3 of 3
- Fee structureOne fee per grade is simple. Concessions, siblings, transport, instalments and part payments are not.Effect on scope: 3 of 3
- Result and report cardsSchool-specific and often board-specific. The scheme is implemented, never assumed from a template.Effect on scope: 3 of 3
- Parent and student accessWhat each may see, and how they sign in. The quiet driver behind most of the rest.Effect on scope: 2 of 3
- Admissions workflowHow much of the enquiry-to-enrolment process the system runs versus records.Effect on scope: 2 of 3
- MigrationDecided by the state of the current records rather than their volume.Effect on scope: 2 of 3
- ConnectionsAn existing ERP, an LMS or an accounting system that has to agree with this one.Effect on scope: 2 of 3
- Optional modulesTransport, library, hostel and similar. Each is real work, and none is included by default.Effect on scope: 2 of 3
- Mobile appWhether parents need an installable app rather than a browser — a second build.Effect on scope: 2 of 3
- NotificationsWhich channels, and who pays for them.Effect on scope: 1 of 3
What we need to scope one
How admissions run today, where student records live, how attendance is recorded, how fees are structured and collected, how results are produced and published, what parents need to reach, which systems already exist, and what historical data must come across. One real academic year, looked at properly, is worth more than any requirements document.
On transport, library and hostel
The category commonly bundles these, and a feature count is easy to publish. They are not assumed here. Each is a real piece of work with its own data and its own daily users, and a school that does not run a hostel gains nothing from one — so they are scope expansions to ask for rather than a checklist to match.
- What determines the scope of a school management system?
- Mostly the fee structure, the result scheme and whether it is one school or a group. A single fee per grade with a standard report card is a modest build; concessions, sibling arrangements, instalments and a school-specific report card across several branches is a substantially larger one. After that it is how much of admissions the system runs, what parents can reach, the state of the records being migrated, and which existing systems have to agree with it.
Background
Relevant capability work.
Branditify has not delivered this exact system. These are delivered projects shown for the capability they document — the records, states and interfaces behind them — each listed as what it actually was.
- Custom software How a system like this gets built
- All work Every project, with what was delivered on each
Questions
Asked before commissioning one.
- We already have a school ERP. Can it be replaced or connected?
- Both are normal. Replacing makes sense when the workarounds have become the system; connecting makes sense when the existing product does one part well and the school only needs to fix the rest. The first step is the same either way — see what your current system can export, because that determines which options are actually open.
- Can teachers use it without training?
- The parts teachers touch daily should need none — marking a class and entering marks are the two that must be quick on a phone between periods. Anything a teacher does once a term will need showing, and it is worth being honest about that in planning rather than assuming an interface will carry it.
- Can several branches use one system?
- Yes, and this is where the design questions get interesting. A group usually wants shared governance and reporting while keeping each branch’s students and staff separate, and where exactly that line falls is a decision for the group rather than a default worth guessing.
- Does every school need a mobile app?
- No. A responsive portal that works properly on a phone covers most of what parents do, and it costs less to build and maintain. An app earns its place when push notifications matter, when parents interact several times a week, or when something has to work with poor connectivity — and it is a second build, not a setting.
- Can students have their own access?
- In senior classes it often makes sense, and in junior ones it usually does not. It is worth deciding by age group rather than switching it on for everybody, because a student view raises its own questions about what a child should see about themselves before a parent does.
- What about transport, library and hostel?
- Available as scope expansions rather than assumed. Each brings its own daily users and its own data, so they are worth adding when the school actually runs them and worth leaving out when it does not — regardless of what a competitor’s feature list includes.
- Does it replace our school website?
- No, and the two should not be confused. The public website exists for families who have not joined yet — programmes, admissions information, the reasons to choose you. This system starts once somebody enquires and runs everything after that. They connect at exactly one point: the enquiry form.
- What about security?
- A school system holds information about children, so access rules, retention and where data is stored are settled early rather than after launch. No certification is claimed on this page; what is offered is that those requirements are established with you before the architecture is fixed.
- How long does one take to build?
- It follows from the fee and result complexity, whether it is one school or a group, and the state of the records being migrated — so it is scoped after seeing a real year rather than quoted before. Schools also have a practical constraint software does not: there are only so many sensible moments in an academic calendar to switch over.
- When is the right time to switch systems?
- Almost always the start of an academic year, and it is worth planning backwards from that date. Mid-year switches mean running two systems through a fee cycle and a set of results, which is the kind of parallel work that makes people distrust the new system before it has had a chance.
- What happens after it goes live?
- The first full academic year is the real test, because that is when the parts designed from description rather than observation show themselves — usually at the first fee cycle and the first result publication. Planning for adjustments after each of those is more realistic than treating launch as the end.
Start here
Bring us the school workflow your team is currently joining together by hand.
The most useful first conversation is about one real academic year — how a student arrived, and everything that had to happen before the year closed.
- How admissions work today, and where enquiries arrive
- Where student records actually live
- How attendance is recorded and who follows it up
- How fees are structured and collected
- How results are produced and published
- What parents need to reach for themselves
- Which systems already exist and must connect
- What historical data has to come across