NDIS provider software: build, buy or extend?

Should an NDIS provider build, buy or extend its software?

Buy first. For most providers the right answer is an established NDIS platform, extended with integrations and reporting where it falls short. Mature NDIS platforms already handle participant records, service agreements, rostering, shift notes, incidents and claiming, and they absorb NDIA and Commission changes for every customer at once. A small provider building that from scratch would spend a great deal to recreate what a subscription already does.

Custom work earns its place around the platform. The table shows where each approach usually fits.

Situation	Usually the best approach	Why
Sole trader or small team, common support types	Buy a platform, configure it well	Cheapest and fastest; the vendor carries the regulatory updates
Growing provider with payroll, accounting and rostering in separate tools	Buy, then integrate	The pain is retyping between systems, not the platform itself
Provider with reporting needs the platform can’t meet	Buy, then add a reporting layer	A data warehouse and dashboards read from the platform’s API or exports
Large or multi service provider whose workflows don’t fit any platform	Build the core, or a platform plus substantial custom modules	Only when the fit gap costs more than building, and you can fund ongoing maintenance
Technology company building a product for providers	Build	You become the vendor, with the NDIA and Commission obligations that follow

If you are that last case, note that the NDIS Commission states that from 1 July 2026 SIL providers and NDIS digital platform providers need to register with it. Whether a particular product is a digital platform for that purpose is a question for your lawyer, and it should be settled before you design the business model.

Our build vs buy guide walks through the decision in general terms.

What do the NDIS Practice Standards expect your systems to evidence?

The Practice Standards set the quality outcomes registered providers must meet, and auditors check them against quality indicators, so your software has to produce the evidence on demand. The Commission describes a core module for registered providers delivering higher risk supports, supplementary modules depending on the supports delivered, and a verification module for lower risk supports. Each module has participant focused outcomes and quality indicators that auditors use to assess compliance.

Software doesn’t make a provider meet the standards, but poor software makes it hard to prove. A useful test is whether you could produce each of these in an audit within an hour:

• Every current service agreement, with the participant’s signature or recorded agreement and the date.
• Progress notes for a chosen participant over a chosen period, showing who wrote and approved each one.
• The incident register with each incident’s assessment, actions, notifications and closure.
• Complaints received, how each was handled and what changed as a result.
• Each worker’s screening status, training records and the roles they were rostered into.
• Behaviour support plans and any restrictive practices used, matched against authorisations.
• Risk assessments and the reviews that followed them.

If any of those means opening five systems and a shared drive, that is where integration and reporting work pays for itself.

How does incident management need to work?

The NDIS Commission expects providers to identify, assess, record, manage and resolve incidents through an incident management system, and to notify reportable incidents within strict timeframes. The Commission defines an incident broadly, as an act, omission, event or circumstance that has or could have caused harm to a person with disability, or where a person with disability has caused serious harm or the risk of it to another person.

Reportable incident (registered providers)	Notify the Commission within
Death of a person with disability	24 hours
Serious injury of a person with disability	24 hours
Abuse or neglect of a person with disability	24 hours
Unlawful sexual or physical contact with, or assault of, a person with disability	24 hours
Sexual misconduct against, or in the presence of, a person with disability	24 hours
Unauthorised restrictive practice, or one that doesn’t follow a behaviour support plan	5 business days (24 hours if it caused harm)

Timeframes run from when the registered provider became aware. That shapes the software design:

1. Capture on any device, immediately. A worker on shift needs to record what happened from a phone in a few minutes, with the time of awareness stamped automatically.
2. Classify with a person, not a model. The system can prompt with the Commission’s categories, but a trained person decides whether it is reportable.
3. Show the clock. Once flagged as reportable, the deadline is visible to the people responsible, with escalation if it is approaching.
4. Keep the evidence together. Notifications, follow up reports, actions and closure stay linked to the original record.
5. Report on patterns. Incident trends by service, site or type feed continuous improvement, which auditors also look for.

What are the realities of claiming?

Claiming runs through the NDIA’s provider portals or its APIs, and the rules on timing and format matter as much as the software. The NDIA says payment requests must be submitted within 2 years after a support is delivered, and for NDIA managed participants it recommends claiming within 90 days, because later claims get extra checks and may be held for review for up to 28 days.

The practical points for system design, as the NDIA describes them at the time of writing (November 2026):

• Two portals. The my NDIS provider portal is used for participants on the NDIA’s new computer system, and the myplace provider portal for participants on the old system. Staff access the portals with myID linked to the business through Relationship Authorisation Manager (RAM). Older guidance refers to PRODA, so check the NDIA’s current page when setting up access.
• Bulk upload is unavoidable for some participants. Single claims can be made through the payment request tile in myplace, but the bulk payment request upload must be used for participants with plans in the new computer system. Your platform or integration needs to generate that file accurately, with participant numbers, support item numbers, dates and prices that match the plan.
• API access is gated. Registered providers and plan managers can apply to integrate directly with the NDIA’s APIs through its digital partner process. Software developers must partner with a registered provider and complete additional cyber security activities.
• Rejected claims need a loop. Each rejection should come back into your system with its reason, so it is fixed and resubmitted rather than lost.

Payment terms reward getting this right: the NDIA says valid claims from providers recorded as “my providers” are usually paid within 2 to 3 business days.

Why is SCHADS rostering hard to automate?

Because the Social, Community, Home Care and Disability Services Award has many rules that interact: shift types, minimum engagements, broken shifts, sleepovers, travel, overtime and penalty rates, and they apply differently across employee classifications. Generic rostering and payroll tools often handle the common cases and get the edge cases wrong, which shows up as underpayment risk.

If rostering, timesheets and payroll sit in different systems, an integration that applies the award consistently, and flags shifts that need a person’s review, is often more valuable than any new feature. The rules come from the award as published by the Fair Work Ombudsman, and your payroll adviser should sign off the interpretation before it is coded. Our workflow automation and API development services cover this kind of integration.

How should participant information be protected?

Treat every participant record as sensitive information, because much of it is health information, and because the Privacy Act’s small business exemption doesn’t apply to businesses that provide a health service and hold health information. That has direct consequences for the software:

• Role based access so workers see only the participants they support.
• An audit trail of who viewed and changed each record.
• Australian hosting for records, files, backups and any AI processing.
• Retention and destruction rules that match your obligations.
• A tested process for notifiable data breaches.

Our Privacy Act and AI guide covers how these rules apply when AI touches personal information.

Where does AI help, and where are the red lines?

AI is useful for drafting and reading, for staff to check, and it should stay out of decisions about people’s safety and rights.

Good uses, with human review	Red lines
Drafting a progress note from a worker’s dictated summary	Writing notes without the worker reviewing them
Reading referral documents and plans to prefill participant details	Deciding whether an incident is reportable
Summarising a participant’s recent notes before a review meeting	Any decision about restrictive practices
Checking claims against service agreements before upload	Submitting claims without a person approving the batch
Answering staff questions from your own policies and procedures	Giving participants or families clinical or legal advice

Document intake is a standard AI document processing pattern, and the controls on the AI in healthcare page apply equally here: source links, approval records and no silent training on participant data.

How AWLabs approaches NDIS projects

We start by checking whether your current platform can do the job with better configuration, and say so if it can. If custom work is needed, every build starts with our Discovery Audit, a fixed fee credited in full against the build. After two strategy sessions you receive a fixed price Schedule of Work with three options: The Minimum, The Recommended and The Complete. Senior engineers lead every build and review every change, updates arrive every Tuesday and Friday, Sydney time, and the code and IP are assigned to you as they are paid for. We aren’t a registered NDIS provider or an NDIA digital partner, and we haven’t yet delivered a project for an NDIS provider; we bring the engineering, and your compliance lead and advisers own the regulatory interpretation. For related reading, see our aged care software page and the healthcare industry page.