NDIS system outages and SDA: A claim-continuity checklist

SDA providers often rely on several NDIS systems for one operating cycle. A finance team may submit claims in myplace, an operations lead may manage a claim enquiry in the my NDIS provider portal, an enrolment lead may be responding to a dwelling request for information, and a manager may be preparing an owner update from expected payment dates.

When those systems are offline at the same time, the risk is not only delayed portal access. The larger risk is untracked manual work: screenshots copied into inboxes, claim rows edited offline without version control, vacancy dates discussed verbally, or owners told that income is expected before the claim state is confirmed.

Make every outage notice a controlled event in the claim calendar. Record the official outage window, affected systems, planned pre-window tasks, blocked tasks, post-window checks and reporting hold points. That gives the team a shared source of truth instead of asking each person what they managed to do before the portals disappeared.

The NDIS provider portal guidance separates key SDA actions across systems. SDA dwelling enrolments and claim or payment enquiries sit in the my NDIS provider portal, while claims and payments are submitted through the myplace provider portal. Payment request guidance also says providers should check funding management type, participant system status, ABN requirements and my provider requirements before claiming.

During an outage, that split becomes operationally important. If a claim cannot be submitted, the workaround is different from a claim enquiry that cannot be lodged or an SDA enrolment task that cannot be updated. Treat those as separate blocked states rather than one generic portal problem.

Keep a short action matrix for each dwelling and participant: claim submission, payment enquiry, relationship status, dwelling enrolment, vacancy notice, evidence response, pricing check, plan-manager handoff and owner-reporting status. Name the portal, owner, deadline and fallback evidence for each action.

Use this checklist before planned outages, during unplanned downtime, after API failures, or whenever portal access problems affect a claim run, payment enquiry or SDA vacancy workflow.

The NDIS guide to getting paid says providers need core information such as participant details, dates of support, support item and support item price before requesting payment. It also explains that payment timing can change if the provider is not recorded as a my provider or if a claim needs accuracy checks.

An outage should not push the team into submitting claims with incomplete participant, pricing, relationship or service agreement evidence. That may create a faster submission but a slower recovery if the claim rejects, is queried, or enters review.

Instead, use the downtime to clean the internal batch: confirm enrolled dwelling identity, participant funding management, my provider status, service agreement source, support item, price source, vacancy state and owner-reporting hold. When portals return, the submitted claim should be stronger than it was before the outage.

SDA vacancy rules create time-sensitive operating steps. Providers need to notify the NDIA when vacancies occur, manage SDA Finder visibility, preserve notice evidence and submit vacancy payment evidence through the correct enquiry pathway when eligible.

If the my NDIS provider portal is unavailable, the provider still needs an internal vacancy clock. Record the vacancy date, notice source, dwelling address, current resident count, room availability, SDA Finder task, email confirmation state, enquiry task and planned post-outage submission owner.

Dwelling enrolment work deserves the same treatment. RFIs, enrolment modifications, cancellation tasks and viewing enrolled dwellings should not live in a person's memory while the portal is unavailable. A blocked enrolment task can become a claim-readiness problem if it is not visible after systems return.

Outages can create duplicate-risk moments. A team member may prepare a bulk file, another may manually resubmit a rejected row, and a third may chase a payment enquiry after access returns. Without a reconciliation gate, owner statements can reflect expected income, not paid income.

Create a post-outage reconciliation sequence: check submitted claim rows, check portal status, compare against internal batch, isolate rejections, confirm paid amounts, review manual payment review notices, verify claim and payment enquiry receipts, then release owner reporting.

Owner updates should explain operational timing without exposing participant-identifying information, plan details or portal evidence. Labels such as portal outage delay, submitted after outage, payment pending, evidence response lodged or reconciliation hold are usually enough for owner visibility.

StepFree SDA is designed to keep claim batches, payment exceptions, dwelling records, participant onboarding, vacancies, evidence requests, reconciliation and owner-safe reporting connected in one operating workflow.

That matters when NDIS systems are unavailable. The provider still needs a controlled internal record of what was ready, what was blocked, what was submitted later and what should not yet flow into owner reporting.