SDA payment request setup: A provider checklist before claim runs

Many SDA claim runs are reviewed only after a rejection, delayed payment or owner question. By then the finance team is trying to work backwards through bank details, provider identifiers, participant funding management, my provider status, service booking history, support item codes and upload errors. That creates noise because the root cause may be administrative setup rather than SDA pricing, occupancy or participant eligibility.

The NDIS guidance is explicit that bank account details must be provided before a payment request can be created. It also says providers should check the funding management type and the computer system the participant's plan is in before claiming. If the participant is in the old system and NDIA-managed, a service booking is needed. If the participant is in the new system and the support is SDA, home and living, behaviour support, NDIA-managed or plan-managed, the provider needs the correct my provider relationship.

Treat those checks as a pre-claim gate. The useful question is not only can we calculate this claim? It is can we prove the provider, participant, portal pathway, price, dates and evidence are ready before anyone presses submit?

Start with the organisation record because one stale provider field can create repeated exceptions across every dwelling. The my NDIS provider portal guide shows organisation details, ABN, contact details, bank account details and employee records in the organisation area. It also notes that only Primary contacts and Account Managers can view the bank account card.

A practical SDA provider should hold a monthly payment setup snapshot: organisation ID, legal name, trading name, ABN, registered scope, payment bank account last checked date, authorised portal contacts, backup access, finance owner and escalation owner. This should not expose the full bank account in broad operational reporting. Use the minimum detail needed to show that the payment record was checked and who can access it.

This is especially important for providers managing multiple entities, acquired dwellings, owner portfolios or plan-managed participants. The NDIS bulk payment guide includes fields such as provider registration number, participant NDIS number, support dates, support number, claim reference, quantity, unit price, GST code and conditional ABN data for plan-managed service bookings. If your source system cannot tie those fields back to a controlled provider record, the upload becomes a spreadsheet risk rather than a finance process.

Do not use one participant status called ready to claim. Split it into at least three facts: which NDIS computer system the plan is in, how the SDA funding is managed, and whether the required provider relationship exists for the SDA or home and living role.

The my provider guidance says participants or nominees need to tell the NDIA who their my providers are when they have NDIA-managed funding, SDA, home and living or behaviour supports, or plan-managed funding. Providers can submit a relationship request in the my NDIS provider portal, and the request can be for a specialised support category role including specialist disability accommodation. If the participant does not appear in the my participant section, the provider is not recorded as their my provider.

That means claim readiness should include relationship source, request date, start date, support category, accepted status and evidence owner. A provider should not assume an active service booking, old plan history, vacancy acceptance, signed service agreement or owner approval proves the current my provider state.

Use this checklist before each monthly SDA claim run, after a participant moves in, after a plan changes, after an entity or bank change, and after any bulk upload rejection pattern.

The bulk payment request guide makes clear that the upload is not just a file transfer. Providers need the right reference files, the correct template, valid participant and provider identifiers, accepted date formats, support item codes, claim references and the right ABN handling for plan-managed service bookings. A successful file upload may still need payment validation before the individual payment requests are treated as valid.

For SDA, use a small number of structured error states instead of free-text notes: file validation failed, row validation failed, relationship missing, funding pathway mismatch, support item mismatch, date outside plan or booking, price capped, duplicate claim, enquiry lodged, evidence requested, paid and reconciled.

That structure matters because repeated spreadsheet errors can look like cashflow volatility or NDIA delay when the underlying issue is a weak export rule. Review every rejected or capped row after each claim run and decide whether it is a one-off correction, a participant record problem, a provider setup problem or a system rule that needs to be fixed before the next run.

The NDIS record-keeping page says providers are responsible for complete, truthful and accurate claims and must keep complete and accurate records of supports delivered. It lists records such as invoices, support logs, rosters, case notes and service agreements. For invoices, it includes participant name, NDIS number, support dates, amount, support type, business name, ABN and, for SDA, the participant address including postcode. It also states that each invoice can only be for one participant and that written service agreements are required for SDA.

Do not let owner reporting pull private participant evidence into the wrong audience. Owners need operational states such as claim submitted, payment pending, relationship exception, evidence requested, rejected and corrected, or paid and reconciled. They do not need participant NDIS numbers, plan screenshots, private correspondence, bank details or support notes.

A clean SDA payment setup process gives owners more confidence because it separates confirmed income from claim friction. It also protects participants because payment evidence stays attached to the participant record and owner updates stay at the dwelling and income-status level.

StepFree SDA can help providers connect the payment setup record to participant onboarding, dwelling enrolment, my provider status, claim runs, bulk upload exceptions, reconciliation and owner reporting. The aim is not to replace official NDIS portals or pricing documents. It is to keep the operating record complete enough that teams can see whether a claim is blocked by setup, evidence, relationship status, pricing, upload validation or payment follow-up.

For commercial SDA operators, that distinction matters. It reduces repeated finance rework, gives operations clearer escalation states and keeps owner reporting grounded in actual claim and payment outcomes.