A surprising number of school ERPs generate exactly one report card layout and expect every school to make it work. That's fine if every school followed the same board — but CBSE, ICSE, and State Boards genuinely differ in how they expect academic performance to be represented, and a report card that ignores those differences ends up needing manual rework every term, which defeats the point of automating it.
Where the formats actually differ
| Aspect | CBSE | ICSE | State Board |
|---|---|---|---|
| Assessment style | Grade-based (CCE-influenced), often with grade points | Percentage-and-marks based, more granular | Varies by state; many use marks with local grading bands |
| Co-scholastic areas | Explicitly graded (life skills, work education, discipline) | Less standardised, school-defined | Varies widely by state board |
| Term structure | Typically two terms with a cumulative view | Often has more frequent periodic tests | Depends on state — some annual, some term-based |
| Subject naming | Standardised subject codes | Board-specific subject list | State-specific subject list and local language options |
None of these differences are exotic — but they mean a report card template hardcoded for one board will show the wrong structure, or worse, force teachers to manually recalculate a grade band that should have been automatic.
What this means for how the ERP should actually be built
The board should be a school-level setting, not a hardcoded assumption
A school's board affiliation is a fact about that school, set once during onboarding — CBSE, ICSE, State Board, IB, IGCSE, or another arrangement. Every report card, and ideally every grading rule, should read from that setting rather than assuming one layout fits everyone. This also matters for multi-branch trusts, where different campuses under the same management can follow different boards.
Marks entry should stay board-agnostic; only the output should differ
Regardless of board, the underlying data a teacher enters is the same shape: a student, a subject, an exam, marks obtained, and the maximum marks. What changes is how that data gets presented — as a percentage, a grade, or both — and whether co-scholastic fields need to appear at all. Keeping the raw data board-agnostic and only branching at report-generation time avoids duplicating the entire marks system per board.
Report card headers and templates need to be editable per school
Beyond the board's grading logic, individual schools also want their own header (school name, logo, motto), their own remarks format, and sometimes their own additional fields. A report card system that hardcodes the header alongside the grading logic makes both harder to change independently.
A practical test for any ERP demo: ask the vendor to show you a CBSE-format report card and an ICSE-format one, generated from the same underlying marks-entry screen, for two different demo schools. If they can only show you one layout, that's the constraint you'll inherit.
Why this is easy to overlook until it isn't
Most schools evaluating an ERP are only thinking about their own board at the time, so a single hardcoded layout doesn't seem like a limitation. It becomes one the moment the school switches boards, opens a branch under a different board, or a state board updates its own grading circular — which happens more often than people expect. Building the report card system to read from a per-school board setting, rather than assuming one format, is what avoids a manual rebuild when that happens.
See Your Board's Report Card Format Generated Live
Tell us your board during the demo and we'll show you the actual output — not a generic mockup.
🚀 Book a Free Demo