Board-specific operations
CBSE, ICSE and State Boards: What Your School Software Must Handle Differently
Most school software was built around one board’s assumptions and bends badly for the rest. Here is what genuinely differs across CBSE, ICSE and state boards in daily practice — assessment, report cards, promotion, examinations, registration, languages — and how to make any vendor prove ‘all boards supported’ live, before you sign.
The software remembers which board it was built for
Ask an examination in-charge who has worked under more than one board, and they will tell you quickly: the software remembers where it grew up. A marks-entry screen that fits one board’s assessment pattern perfectly will fight you at another. Fields that should exist don’t. Fields that shouldn’t exist are compulsory. The report card comes out almost right, which, for a mandated document, means wrong. Most school software in India was built around one board’s assumptions, then stretched to claim support for the rest.
The board a school is affiliated to decides more than the syllabus. It decides how marks are structured and combined, what the report card must show, how a student is promoted to the next class, when examinations happen and how the year is divided, how candidates are registered and roll numbers issued, which subject combinations are allowed, and, for state boards, which languages the school teaches and reports in. Each of those touches software every single week of the academic year.
One honest note before we start. Boards revise these rules. Weightings, grade bands, formats and calendars change from year to year, sometimes mid-year. So this article describes the shape of each difference, not the current numbers. For the numbers, work from the board’s current circulars — the official notices boards issue when rules change — and expect your software to keep up with them, because the circulars will not wait for your vendor’s next release.
Assessment and grading differ in structure, not just in names
Start with the deepest difference. Every board splits a student’s result between internal assessment, the marks the school itself awards through the year for tests, projects and practicals, and external assessment, the board’s own examination. But boards differ in how the two are weighted, which components count inside the internal share, and how the split is reported. And they revise these weightings. Software that hard-codes one split will be wrong somewhere, or wrong soon. The split must be configuration a school can change: per board, per year, per subject.
Grading is the same story one layer up. Some boards report marks, some report grades, some report both, and the bands that convert marks into grades differ by board and get revised. Some grade subjects individually; some also grade co-scholastic areas — the non-examination parts of school life such as arts, sport and behaviour — on separate scales. A system built for one pattern will quietly misreport another. The practical test is simple: can your office reproduce the board’s current scheme without calling a developer?
- Internal and external weightings held as editable configuration, per board, per class, per subject and per academic year — never hard-coded.
- Assessment components (periodic tests, projects, practicals, orals) named and weighted the way each board names and weights them.
- Grade bands and conversion rules editable by the school when a circular changes them, with past years preserved exactly as they were.
- Scholastic and co-scholastic areas graded on separate scales where a board separates them.
- A clear recalculation path when rules change mid-year, so marks already entered are never silently re-marked.
Report cards are mandated documents, not templates
A report card is not a template your designer tweaks. For a board-affiliated school it is a mandated document: the board prescribes fields, sections, terminology and often the layout, and a school that omits a mandated field creates real problems for students later, at admission time and at verification time. Coordinators know this, which is why so many schools quietly maintain a parallel Excel version of the ‘real’ report card their official software cannot produce.
The differences are concrete. Boards differ in which attendance figures appear, how internal and external marks are shown, whether grades sit beside marks, what the co-scholastic sections look like, which signatures and declarations are required, and what the promotion remark must say. State boards add another layer: report cards in the state language, or bilingual, matching the school’s medium of instruction — the language in which classes are actually taught.
So evaluate report cards with your own document in hand. Bring your board’s current format to any demo and ask to see it generated, field for field, from real marks entered that day. ‘We support all boards’ is a brochure sentence. A report card matching your mandated format on screen is evidence. And ask how the format is updated when the board revises it — by your own office, or by a support ticket to the vendor.
Examination schedules, terms and promotion rules follow the board
The examination calendar is the school’s real clock, and boards wind it differently. Boards differ in how the year is divided — terms, semesters, or a single annual cycle — in when board examinations fall for the classes they examine, and in what leads up to them: practical examinations, project submissions, and the pre-board tests the school schedules itself. A school’s teaching plan, unit tests and revision weeks all hang off this structure, so the structure has to live in the system.
Software with a fixed two-term assumption bends badly here. It must instead model the year the board actually prescribes: term structure as configuration, examination windows for board classes alongside school-conducted exams for the rest, practical and project schedules with their own dates, and the operational layer underneath — seating plans, invigilation duties, and marks-entry deadlines timed to the board’s own submission dates. When the calendar is modelled honestly, everything downstream falls into place: attendance cut-offs, syllabus tracking, report card timing.
Promotion, the decision that a student moves to the next class, is governed differently too. Boards differ in the criteria that decide it, in the attendance expectations attached to it, and in what happens when a student narrowly misses: many provide a second-chance examination in the subject concerned, under names that vary by board, and the policies themselves get revised. Software should hold promotion rules as readable configuration, apply them consistently, and record each decision with its basis — because a promotion query, years later, is answered from these records.
Registration and roll numbers are the board’s paperwork, done your side
For the classes a board examines, students become the board’s candidates, and the paperwork changes hands. The school submits a candidate list to the board — a roster carrying each student’s name, date of birth, subjects and photograph exactly as records must show them — and the board issues registration numbers, roll numbers and admit cards against it. A spelling mismatch or a wrong date of birth here follows a student onto certificates, and corrections after submission are slow and painful for everyone involved.
This asks something specific of software. Board-facing identity fields should be held carefully and validated before submission — names as per records, dates of birth, subject codes — and exported in the shape each board’s own portal expects, because every board runs its own portal and that portal stays authoritative for registration. Your software’s job is to make the school’s side of that exchange clean: one accurate record feeding the submission, not three spreadsheets reconciled the night before the deadline.
Subjects, electives and languages vary most across state boards
Subject structure looks similar across boards until you try to model it. Boards differ in which subjects are compulsory, in how electives — the optional subjects a student chooses — are grouped, in whether an additional subject can be taken beyond the standard set, and in which combinations are permitted together. Software must express these rules and validate them at enrolment, because a student steered into an impermissible combination in one class becomes a registration problem when board paperwork begins.
Language is where state boards diverge most, and where software built for English-medium schools struggles hardest. The medium of instruction — the language classes are taught in — varies by state and sometimes within a single school. Language subjects follow patterns the state prescribes. And the paperwork follows the language: report cards, certificates and parent communication may need to be in the state language, bilingual, or both, in scripts the software must render correctly everywhere they appear, from marks screens to printed documents.
- Compulsory subjects, elective groups and permitted combinations modelled per board, and enforced when a student enrols.
- Additional or optional subjects handled the way the board treats them, including how they appear in results.
- Multiple mediums of instruction within one school, each section reporting in its own language.
- State-language and bilingual report cards, certificates and notices, rendered correctly in the required script.
- Subject codes matching each board’s own coding, so exports to board portals need no manual translation.
The multi-board trust is the hardest case — and the best test
Now the hardest case, and the one that exposes weak software fastest: a trust running CBSE at one campus and a state board at another. This is common. Trusts add campuses over decades, and affiliation decisions made decades apart rarely match. Head office wants one picture of the organisation. Each campus lives a genuinely different academic reality: different calendars, different assessment structures, different report cards, and different words for the same idea.
Watch what breaks. A consolidated academic report compares grades produced under different schemes as if they sat on one scale. The trust’s calendar review finds one campus mid-examinations while another is mid-term. A teacher transferring between campuses discovers that ‘internal assessment’ means something different on arrival. Even the word ‘result’ is ambiguous: board-issued at one campus for the senior classes, school-computed at the other. Averaging across boards does not produce insight; it produces a number nobody can defend to a trustee.
The structural answer is that the board must be an attribute of the campus — or even of a class group within a campus — not an assumption of the whole system. Each campus keeps its board’s assessment scheme, calendar, report card and registration workflow intact. Above them, the trust sees one governed picture built on shared definitions: enrolment, attendance and fee data consolidate cleanly because they are board-independent, while academic results are presented side by side, each in its own board’s terms, never silently merged.
If you run such a trust, this is your entire software evaluation in one scenario. Ask the vendor to set up two campuses on two boards in one system, live, and then show the trust-level view. Most products fail this in one of two ways: they flatten the boards into one scheme and misreport both, or they effectively run two separate systems with a spreadsheet on top. Either failure sends your head office straight back to manual reconciliation every month.
Make the vendor demonstrate it live, not promise it
Every brochure says ‘all boards supported’, and the sentence is unfalsifiable until you make it falsifiable. The way to do that is to stop asking whether something is supported and start asking to watch it work: on your board, your format, your current circular, in a live system, with your coordinators in the room. What a vendor can show you today is real. What they promise for after signing is a roadmap, and roadmaps slip.
Score each item the way procurement scores a written answer: demonstrated live, promised for later, or declined. Then weigh the pattern rather than any single item. This test is vendor-neutral by design. It will sort any shortlist, whether or not SquareCampus is on it, because it measures the one thing a brochure cannot fake: whether board-specific behaviour is configuration inside the product, or custom work sitting in the vendor’s backlog.
- Configure your board’s current assessment scheme — components, weightings, grade bands — from the circular on the table, during the demo.
- Enter sample marks and generate your board’s report card, then compare it to your mandated format field by field.
- Change one weighting the way a mid-year circular would, and show exactly what happens to marks already entered.
- Run two boards in one instance with different calendars, and show the consolidated view a trust would actually see.
- Produce the candidate-list export in the shape your board’s portal accepts, from data entered in the system that day.
- Generate a report card in your medium of instruction, if your school reports in a state language.
- Show promotion rules as configuration a school administrator can read, not behaviour buried in code.
Where SquareCampus fits
SquareCampus is built as a School Operating System — an institutional decision layer for Indian schools and trusts — and board-specific behaviour is treated the way this article argues it must be: as configuration on one governed data model, not as assumptions baked into code. Boards attach at the campus level, so a trust running CBSE alongside a state board consolidates what is genuinely comparable and sees the rest side by side. The platform page at squarecampus.com/platform/ walks through how that model is put together.
Rollout follows the same respect for what already works. A bounded first deployment coexists with the systems a school already runs — the existing ERP, the board’s own portals, the payment gateway — and those stay authoritative for what they do. If the institution later chooses to consolidate fragmented tools onto the platform, that is a decision it makes deliberately, never a rip-and-replace forced on day one. The rollout page at squarecampus.com/rollout/ describes how a bounded deployment is scoped and proven.
Whatever you evaluate, take the live-demonstration list above into every demo, ours included. Bring your board’s current circular, your mandated report card format and, if you are a multi-board trust, both campuses’ realities. A walkthrough can be booked at squarecampus.com/demo/, and we would rather earn the evaluation on your board’s paperwork than on a brochure sentence. A vendor who cannot survive an afternoon with your circulars will not survive an academic year with your school.
See board-specific structure as configuration
The platform page shows how assessment schemes, report cards, calendars and multi-board trusts are modelled on one governed system — worth reading before any vendor demo, including ours.