NDIS Commission portal cutover: An SDA compliance-queue checklist

This transition should not sit only with the person who logs in to the portal. SDA providers operate homes where compliance tasks can connect directly to participant safety, support-provider boundaries, tenancy records, dwelling access, incidents, restrictive practice evidence and owner reporting.

The Commission guidance says new work starts in the new portal from 12 October, while existing work continues in the existing portal. That means the useful internal record is not just portal name. It is a queue that shows what work exists, which portal owns it, whether there is a draft at risk, which deadline applies and who is accountable for the next action.

Use the outage weekend as a forcing function. Before 8 pm on 9 October, list every open Commission-facing action and classify it as submit before outage, finish in existing portal, start in new portal from 12 October, preserve as historical evidence, or monitor only.

Use this checklist before the outage, during the 12 October changeover week, and in the first month after the new portal goes live.

Reportable incidents are the highest-risk cutover workflow. Commission guidance says registered providers must notify the Commission of reportable incidents, including incidents already recorded and responded to in their own incident management system. Serious categories generally require notification within 24 hours, while unauthorised restrictive practice without immediate harm is generally within five business days.

Portal unavailability does not make the incident disappear from the provider's operating record. SDA teams should keep a time-stamped incident triage record showing when the provider became aware, what immediate safety steps were taken, who reviewed reportability, whether the matter connects to another support provider, and what will be lodged once the portal pathway is available.

For shared homes, add dwelling-level context without overcollecting private information. The record should show whether the event affects home access, repairs, another resident, support-provider handover, tenancy communication, worker screening, behaviour support or owner-safe reporting. Keep participant-identifying incident detail out of owner updates unless an existing permission and purpose clearly allow it.

Behaviour support work needs its own cutover control. The Commission guidance says new behaviour support plans are lodged in the new portal from 12 October, while monthly reporting for plans lodged before 12 October continues in the existing portal. It also says implementing providers use the new portal for tasks such as accepting or rejecting plans, uploading evidence of restrictive practice authorisation and monthly reporting for plans lodged from 12 October.

SDA providers may not be the specialist behaviour support provider, but the home environment can still be affected by behaviour support plans, restrictive practice authorisation, support-provider implementation and housemate risk. The internal SDA record should show the plan source, implementing provider, restrictive practice evidence state, affected dwelling, authority limits, support-provider owner and any tenancy or safety actions.

Do not blend old-plan monthly reporting with new-plan actions in one vague note. Use a clear plan-date field and portal field so managers can see which record remains in the existing portal, which starts in the new portal, and which follow-up belongs to the support provider rather than the SDA provider.

The cutover also affects registration and audit work. Commission guidance says the new portal is used for applying for registration, re-registration, changes or events affecting registration, registration details and new audits from 12 October, while the existing portal is used to finish registration or audit work that was already underway before the change.

For SDA providers, registration status and scope are not abstract compliance data. They affect owner confidence, referral credibility, participant trust, support-provider handoffs and whether the organisation can show an auditor a coherent record of how homes are managed.

Create a registration control note for each open item: legal entity, ABN, registration group, service location, condition or audit dependency, affected dwellings, evidence owner, portal location, deadline and management decision. If a change has no direct effect on claims or owner reporting, record that too so the absence of action is deliberate rather than assumed.

The NDIS Commission portal is not the same workflow as SDA dwelling enrolment, my provider relationship checks, payment requests, claim enquiries or myplace claiming. During cutover week, that distinction matters because staff may use portal as a catch-all label when the task actually belongs to a different system.

A clean SDA operating record should show whether the task is Commission-facing compliance, NDIA SDA enrolment, NDIA claim or payment, plan-manager invoicing, participant agreement, support-provider handover, RRC, vacancy listing or owner reporting. That prevents a Commission access issue from being mistaken for a claim blocker, or a claim rejection from being treated as a registration problem.

Finance should still maintain claim ageing, evidence packs, payment holds and reconciliation states separately. Compliance should maintain incident, behaviour support, audit and registration states separately. The two views should connect through the participant and dwelling record, not collapse into each other.

StepFree SDA can help providers turn the portal cutover into a controlled compliance queue: dwellings, participants, incidents, behaviour support boundaries, registration tasks, audit evidence, support-provider handoffs, claims, RRC and owner-safe reporting can be connected without treating the official portal as the provider's operating system.

The practical benefit is clarity during a messy week. Teams can see which actions are time-sensitive, which portal owns them, which evidence is already stored, what must wait until 12 October, and how to communicate property-level status without exposing private participant information.