Student reporting: identify the event and the clock

Start with the event-specific rule

For non-enrolment, Document 2 gives ten working days after the enrolment period ends. Other student events have their own trigger dates and exceptions. Institutional changes belong to a separate table. The reporting manual explains SMS use, not a universal deadline.

The central control is identifying when an event becomes reportable. Record the relevant facts and the policy paragraph before asking a calendar tool to calculate a date.

Suggested reporting queue

Keep each case in a visible queue with a reference, event type, trigger date, owner, reviewer and submission evidence. Distinguish an academic decision date from the date a team learned of it; both may be relevant to investigating a late internal handover.

Use a review stage for ambiguous cases. Record why a report is or is not required and when that conclusion should be revisited. Marking “not reportable” without a reason prevents meaningful assurance later.

• Identify the route, provider category and exact event.
• Check the current duty, trigger, reporting channel and any exception.
• Verify the working-day calculation and relevant bank-holiday calendar.
• Keep the approved factual narrative and necessary supporting references.
• Retain the SMS submission confirmation and reconcile it with the internal record.
• Escalate overdue or uncertain cases; do not silently change dates to hide lateness.

Avoid common process gaps

A database status change, an email to a tutor and a draft SMS narrative are different steps. Build a control that proves the required step was completed. During busy periods, use a second person to reconcile the queue against submitted reports and unresolved cases.

Calendar outputs support planning. They do not determine whether a report is legally required, interpret a notice or submit anything to UKVI.