Exams

Generating report cards & transcripts without the spreadsheet chaos

18 July 2026 · Exams · 9 min read

Ask any exam controller about result season and you will hear the same story: a folder of spreadsheets emailed between teachers, a master sheet that broke when someone inserted a column, a CGPA formula that was subtly wrong in one class, and a frantic night before results go out. Spreadsheets are wonderful and completely unsuited to this job — they have no notion of who is allowed to change a mark, no record of what was published when, and no memory between terms. Good report card software replaces the folder with a workflow. Here is what that workflow should look like, using CBSE-style report cards as the running example.

Start with the exam structure

A report card is generated, not typed. That means the structure has to exist first: the exam (a periodic test, a term exam, a board practical), the subjects under it, and the maximum marks for each. Define this once and every downstream artifact — the mark sheet, the grade, the CGPA, the transcript — derives from it. Trying to build report cards without a fixed structure is how two students in the same class end up with subjects in a different order and a parent notices.

Marks entry that belongs to the teacher

The person who knows a mark is the teacher who graded the paper, so that is who should enter it — directly, from their own portal, for their own class and subject. Two properties make this reliable:

• Bounded by the maximum. If a subject is out of 80, the system should not accept 85. Validation at entry prevents the error that is invisible in a spreadsheet until a parent finds it.
• Scoped to the teacher's classes. A teacher sees the roster for their subject and section, enters marks down the list, and saves. No shared master file, no overwriting a colleague's column.

Because the roster comes from enrolment, the names are already right and in order. The teacher's job is to type numbers, nothing else.

The approve-then-publish workflow

This is the part spreadsheets simply cannot do, and it is the whole point. Marks should move through three deliberate states, each owned by a different role:

1. Entered — the teacher has recorded marks, but nobody outside the school-facing side can see them.
2. Approved — a head of department reviews for obvious errors and signs off. This is advisory quality control, a second set of eyes before anything is final.
3. Published — the exam controller releases results. Only now do parents and students see them.

The value of this gate is that nothing reaches a family by accident. A half-entered mark sheet is invisible. A correction made before publish leaves no trace on anyone's report card. And once published, results flow everywhere at once — the student profile, the report card, and the portals — from a single action, so there is never a version where the office and the parent see different numbers.

A spreadsheet emailed around has been "published" the moment it leaves your outbox. A proper workflow decides publication on purpose, once, by the right person.

CGPA, grades and transcripts

Grading rules — a marks-to-grade band, a grade-to-point mapping, a CGPA computed across subjects — are exactly the kind of arithmetic software should own and humans should never re-derive per class. Define the scheme once and every report card applies it identically. That consistency is what makes a transcript trustworthy: a transcript is just the accumulation of published, approved results across terms and years, assembled on demand. When each term's results are captured properly at the time, the year-end transcript and the leaving certificate are a report, not a project.

What parents and students should see

The output that matters is the clean one the family reads. A published result should appear in the parent and student portals with subjects, marks, grade and overall standing — and nothing else. No admin controls, no draft marks, no clutter. The same published record is what prints as the report card, so the screen a parent sees and the paper they receive always agree.

A result-season checklist

1. Exam defined with subjects and maximum marks before entry opens.
2. Marks entered by the subject teacher, validated against the maximum.
3. Entry scoped so teachers touch only their own classes.
4. An HOD approval step before anything is final.
5. A single publish action owned by the exam controller.
6. Grade bands and CGPA defined once and applied uniformly.
7. Published results visible in parent and student portals.
8. Transcripts assembled from accumulated published results, on demand.

How Vidyalaya does it

Vidyalaya models exactly this flow. A teacher creates or opens an exam, adds a subject with its maximum marks, and enters the class's marks from the teacher portal. An HOD can approve as an advisory check, and the exam controller publishes — only then do parents and students see results. Published results flow straight into each student's profile and report card, and into the parent and student portals, from one action. Grades and CGPA are computed from the scheme, so report cards and transcripts are generated, not hand-built.

See the full workflow on the Exams feature page, or walk through a result cycle in a demo.

Report cards depend on the data upstream being right. That starts with accurate rosters — see choosing a student attendance system teachers actually use — and a clean enrolment, covered in how to run admissions online.