Back to blog
Compliance8 min read

NDIS service agreement resources and SDA: A refresh checklist

On 13 October 2026, the NDIA released new service agreement resources, including a template, checklist, guidance and Easy Read materials. The update is especially practical for SDA teams because service agreements are mandatory for specialist disability accommodation. A new template is not a policy shortcut: the NDIA says neither the NDIA nor the NDIS Commission is a party to service agreements or keeps and enforces them. For SDA providers, the useful work is a controlled agreement refresh covering participant communication, dwelling terms, pricing and payment evidence, tenancy and support boundaries, claim records and privacy-safe owner reporting.

Treat the release as a refresh trigger

The new resources should not cause providers to overwrite signed agreements or push a standard document onto participants without explanation. The NDIA says the template is optional and must be tailored if used. That is a workflow instruction: review the template, compare it with the provider's SDA agreement, decide what should change, and record why each change is appropriate for the dwelling, participant and funding pathway.

For SDA, the refresh should sit beside enrolment, RRC, tenancy, vacancy and claim controls. Teams should be able to see which agreement version is current, whether the participant received it in a format they understand, what changed from the previous version, and whether the signed agreement supports accurate claiming.

This is also a good moment to remove risky boilerplate. A service agreement should not imply the provider can contract out of NDIS Code of Conduct responsibilities, Australian Consumer Law obligations or the participant's housing and support choice rights.

Build the SDA agreement refresh checklist

Use this checklist when adopting the new NDIA resources, onboarding a new resident, issuing a new plan-period agreement, changing dwelling terms, correcting payment details or preparing evidence for audit and claim review.

Version the source pack

Record the NDIA service agreement release date, template version reviewed, Easy Read resources offered, internal template owner and approval date.

Map the agreement to the dwelling

Tie the agreement to the enrolled SDA dwelling, resident, design category, service start date, rent contribution handling, dwelling safety features, repair pathway and review date.

Check communication format

Record the participant's preferred language, communication method, interpreter needs, Easy Read preference, support person involvement and whether enough time was given to review and ask for changes.

Separate housing from support

Confirm the agreement does not blur SDA with SIL, onsite shared support, personal care, plan management, support coordination or informal support arrangements delivered by someone else.

Connect to claim evidence

Make sure agreement dates, participant details, dwelling address, support category, payment pathway, pricing assumptions and invoice records are consistent with the claim and reconciliation workflow.

Filter owner reporting

Owners can usually see agreement status, review due dates and claim readiness. They should not see participant plan details, private support needs, nominee correspondence or complaint material.

Keep participant understanding visible

Current NDIS guidance says a service agreement should be clear, accessible and easy to use. It also says participants can ask for the agreement in the format they prefer, with words they understand, and can ask the provider to arrange an interpreter if needed. For SDA providers, that means understanding should be evidenced, not assumed.

A practical register should capture the format sent, the person who explained the agreement, the date explanation occurred, any questions or requested changes, the authority source for a nominee or guardian, and whether the participant received a signed copy.

Clear service agreement communication reduces move-in confusion, cancellation disputes, repair escalation friction, RRC misunderstandings, support-provider boundary conflict and owner pressure for information the provider should not share.

Do not mix the SDA agreement with every other relationship

The NDIS service agreement page is explicit that a service agreement is different from an NDIS plan, service booking or tenancy agreement. SDA teams should extend that distinction into their operating system. The SDA agreement can explain the dwelling service, rights and responsibilities, payment terms, review dates, maintenance pathway and disagreement process. It should not pretend to authorise unrelated supports or override another provider's responsibilities.

This boundary matters where one organisation is close to both housing and support delivery, or where a SIL partner, plan manager, support coordinator, guardian or family member is heavily involved. The SDA Practice Standards require providers to support participants to understand the distinction between SDA and other NDIS supports, and to manage conflicts of interest.

Use separate states: SDA agreement current, tenancy document current, SIL agreement separate, support-provider handoff open, claim ready, invoice evidence aligned, complaint pathway explained or owner update restricted.

Tie agreements to claims and records

The NDIS record keeping page says providers need complete and accurate records of supports delivered, and lists service agreements as part of the record set. It also says SDA providers need written service agreements with participants. That makes the agreement a claim-control input, not a document stored after the fact.

Finance teams should be able to compare agreement dates, dwelling address, support item, payment pathway, invoice address, claim type and pricing assumptions before a claim is lodged or reconciled.

If the agreement changes, do not leave the claim workflow guessing. Use dated states such as variation drafted, participant review open, signed copy received, invoice setup updated, old version archived and claim controls confirmed.

Use consumer-rights language carefully

The NDIA says the new resources aim to improve participant safety through alignment with the NDIS Code of Conduct, Practice Standards and Australian Consumer Law. The ACCC has also highlighted contract issues, unfair terms, overcharging and false or misleading SDA claims as consumer concerns in NDIS markets.

For providers, the practical response is controlled language. Avoid promises that a dwelling is NDIA approved for a participant before the plan, enrolment and claim facts support that statement. Avoid clauses that hide fees, bundle unrelated supports or suggest housing rights depend on choosing the provider's preferred support model.

A better agreement register shows what the provider promised, what evidence supports it, who approved it, where the participant can raise a concern, and how the provider will keep the agreement current.

How StepFree fits the workflow

StepFree SDA can help providers manage service agreement versions, participant communication preferences, authority records, dwelling links, RRC records, claim readiness, invoice evidence, support-provider handoffs and owner-safe reporting in one SDA-specific operations workflow.

The goal is to make agreement status visible beside enrolment, move-in, vacancy, claim, reconciliation and owner reporting work, so teams can act before a missing or unclear agreement becomes a payment, complaint or audit problem.

Conclusion

The NDIA's new service agreement resources are a timely prompt for SDA providers to refresh agreement controls. Providers should version the source pack, tailor documents to the dwelling and participant, evidence communication preferences, separate SDA from other supports, connect the agreement to claims and records, and keep owner reporting filtered. That turns a template update into a safer operating workflow.

StepFree SDA helps providers connect service agreements, participant authority, dwelling records, RRC tracking, claims, reconciliation and privacy-safe owner reporting in one SDA-specific platform.