UDISE+ and APAAR: what a school fixes before submission

The problem is the register, not the portal

Every student has to be on UDISE+ with a PEN — a Permanent Education Number that follows the child between schools. The submission itself is mechanical. What makes it painful is that the Data Capture Form asks for a complete profile, and a school's register almost never is: it grew over years, across admission clerks, with a rushed migration somewhere in the middle.

So the work is not "submit UDISE". The work is to find, months earlier, the small number of records that will be rejected — and to fix them while the family is still reachable and the file is still in the cupboard.

The minimum student profile

A record that is missing any of the following is not UDISE-ready, and will come back at submission:

• Full name, spelled as it will appear on every later document — a mid-year correction propagates to the transfer certificate, the board record and the APAAR account.
• Gender and a valid date of birth. Check specifically for placeholder dates — 01/01 of the admission year is the one to look for. It passes a completeness check, fails at the portal, and stays invisible until you look for it deliberately.
• Mother's name and father's or guardian's name, both, as separate fields rather than one "parent" string.
• Social category, recorded from what the family declared, not inferred.
• Address and a contact mobile number that still works. Ten digits, Indian format.
• Admission number and the current class and section — the admission number must be unique in your school, which is exactly what breaks when two clerks number in parallel.

Validate formats, not just presence: a real ISO date, a ten-digit mobile, a six-digit postal code. "Present but nonsense" passes a null check and fails a portal.

APAAR is a consent problem before it is a data problem

APAAR — the Automated Permanent Academic Account Registry — is described by the Ministry of Education as a lifelong twelve-digit academic ID linked to the Academic Bank of Credits and DigiLocker. A student is ready for it only when the UDISE-core fields above are complete, a UDISE PEN exists, an Aadhaar reference is on file, and parental consent has actually been recorded as received. The official descriptions of both UDISE+ and APAAR are linked at the end of this article.

Two rules follow from that, and both are easy to get wrong in a hurry.

1. Store the Aadhaar reference as the last four digits only. A school does not need the full number to establish a reference, and holding it creates an obligation nobody asked for. Aadhaar e-KYC is not part of this workflow at all — document upload reviewed by a school administrator is.
2. Consent is evidence, not a tick. A checkbox in a spreadsheet is not something you can produce eighteen months later when a parent asks who agreed to what. Record the decision, when it was made, who made it, and what they were told — and record a withdrawal the same way.

A submission sequence that ends quietly

1. Run the check early — twice. Once well before the window opens, when families can still be called, and once a week before you submit. The first run finds the systemic gaps; the second catches the new admissions.
2. Sort findings by who can fix them. Missing category or guardian name is an office task. A wrong date of birth needs the family and usually a document. Duplicate admission numbers are a numbering-policy fix, and they will recur every year until you take numbering away from the counter and give it to one register.
3. Collect consent before you need it, not on the day. A consent chased under deadline pressure is a consent nobody documented properly.
4. Fix in the record of truth, never in the export. A corrected spreadsheet is a submission that passes once and a school register that is still wrong.
5. Keep the run. The list of what was flagged, what was fixed and what was accepted as-is is your evidence next year — and your answer when somebody asks why a record changed.

How this works in Vidyapeeth360

The readiness check is deterministic: a rulebook of field-level checks over your own records, grouped by finding type, producing counts and the exact rows to fix. No model decides whether a record is ready — the same input always produces the same finding list, which is what makes it defensible to re-run and to argue with.

Guardian consent for APAAR is written to an append-only ledger: each decision — granted, rejected or withdrawn — is a new row carrying who, when, the purpose, and how it was verified. The current state is simply the latest row, and withdrawal is as easy as granting, because a consent you cannot withdraw is not consent. Nothing is overwritten, so the evidence survives the correction.

Where Aira is enabled, it can explain a finding in plain language — what the rule is, why the record failed it, and what to change. The finding itself, and the count, stay deterministic; the assistant writes the explanation, never the verdict.

The boundary is worth restating because it is where marketing usually overreaches: Vidyapeeth360 prepares records, holds consent evidence, exports the correction work, and stores an APAAR ID after the government process has issued it. It does not generate the ID, does not synchronise with UDISE+ live, and does not verify Aadhaar. Everything else — the student record, the supporting documents, the report you export — is yours to keep clean.

If you take one thing from this: check in October for a submission you make in December. The records will be no better in December, and the families will be harder to reach.