Why NDIS and Aged Care Software Shouldn’t Run Your Grant-Funded Programs

If your organisation delivers NDIS or Aged Care services alongside Grant-Funded programs, you have probably been told that one software system can do it all. It sounds sensible. One vendor, one login, one source of truth. What tends to happen instead is that the funded programs get bolted onto a platform that was never shaped for them, and within a year the real work has quietly moved into spreadsheets, shared drives and a caseworker’s notebook. The cost of getting this wrong is not only a failed implementation and wasted funds, it’s also a re-tender process you cannot evidence.

Nothing here is a criticism of NDIS or Aged Care software. It does its job well. The mistake is asking it to do a job it was never designed for. The case for system separation becomes clear once you look at how each stream is funded and how services are actually delivered.

NDIS software is built around the claim, while Aged Care software is built around the package and the budget. Both put a billable unit at the centre of the record, and both are excellent at it. Grant-funded programs have no billable unit. The money has already arrived under a funding agreement deed, and what the system has to hold instead, is the story of each client’s journey: who was referred, what was assessed, what was planned, what was delivered, and was anybody better off.

One kind of system is built to get money out. The other is built to prove what the money achieved.

To do this, NDIS and Aged Care systems have to bake their scheme’s rules into their core data model. That is what compliance with a prescriptive structure requires, and it is a strength. Grant-funded programs need the opposite. Every funding agreement is different, and the next one will be different again, so the system has to change shape as your program mix changes. Flexibility becomes the key advantage.

That single distinction shapes every decision that follows, from how you write your requirements to where you draw the boundary between systems. Understanding this difference is the first step in selecting the right software for your NDIS, Aged Care and Grant-Funded programs.

If you want the details please read on. If you want to cut to the chase: Comparison table: NDIS vs Aged Care vs. Grant-Funded program software

So, what’s the difference?

The NDIS

Participants hold individual plans with funded support budgets. The National Disability Insurance Agency (NDIA) administers the scheme through its PACE system, and the NDIS Quality and Safeguards Commission regulates providers.

The funding structure matters. A plan divides funding into four support budgets: core, capacity building, capital and recurring. Within those sit support categories, and within each category sit individual support items. Some categories are flexible, so funding can move between them. Others are stated, meaning the funding is locked to the supports described. Price caps bind NDIA-managed and plan-managed participants, but not self-managed ones.

Providers authenticate through PRODA and claim against the NDIS Support Catalogue, which lists every claimable item with its unit of measure, registration group, claim types and separate national, remote and very remote price points. Rates also vary by day and time. Get the line item wrong, or claim outside the category you are endorsed for, and the claim line is rejected.

Aged Care

The Aged Care Act 2024 and the Support at Home program both commenced on 01/11/2025, replacing Home Care Packages and Short-Term Restorative Care. The Department of Health, Disability and Ageing sets policy, the Aged Care Quality and Safety Commission regulates, and Services Australia pays.

Providers manage registration through the Government Provider Management System (GPMS), publish pricing through the My Aged Care Service and Support Portal, and claim through the Aged Care Provider Portal or through software that has passed a conformance assessment and connected to the government’s business-to-government (B2G) gateway. Support at Home uses eight funding classifications and quarterly budgets across three service categories.

Grant-funded programs

A government department, a Primary Health Network, a local council or a philanthropic funder contracts your organisation to deliver an activity for a population over a defined period. The money arrives under a funding agreement deed, usually in instalments, usually in advance. Your obligation is not to claim. It is to demonstrate what you did and what impact your services had.

What the deed does not generally give you is an operating model. In contrast, the NDIS and Aged Care come with rulebooks: priced line items, claim rules, mandated quality standards, prescribed portals and set assessment pathways. A funding deed for Grant-funded programs sets the target cohort, the geography, the output or outcome targets and the reporting cadence, then stops. How you take referrals, triage them, run a waitlist, assess risk, structure a case plan, escalate, close an episode and measure change is left to you.

That is the trade. Less prescription, more discretion, and the burden of designing the practice model sits with you the provider. Run several programs and you are potentially running several operating models at once, each one yours to define, document and defend at re-tender.

Rostering shifts vs. managing caseloads

In NDIS and Aged Care, revenue is a direct function of who worked, for how long, where, and at what time of day. That makes rostering the operational core of the business, and the software reflects it.

A rostering engine has to match workers to participants on qualification, clearance, gender, language and preference. It has to interpret the award: penalty rates, broken shifts, sleepovers, minimum engagement periods, travel between clients. It has to handle cancellations under scheme-specific rules, cover unfilled shifts, capture check-in and check-out from a phone, and then push timesheets into payroll and claims into the payment engine. Roster to timesheet to payroll to claim to reconciliation is a closed loop, and margin is won or lost in the gaps.

Grant-funded programs do not work that way. Staff are generally salaried against funded positions in a budget that was set before the first client walked in. Costs do not rise because a caseworker saw four people this week instead of two. The scarce resource is not shift coverage. It is caseload capacity.

So the scheduling problem changes shape. What matters is how caseloads are allocated and balanced, how well the waitlist is managed, how group programs and sessions are run and attended, how rooms, vehicles and interpreters get booked, and how planned activity tracks against the output targets in the deed. Some of the work has no appointment at all: outreach, drop-in, court support, a phone call at 8pm.

The distinction is structural, not cosmetic. In a rostering system the shift sits at the centre of the data model and everything else hangs off it. In Grant-Funded  work the client’s journey is the spine and the calendar hangs off that. Invert it and staff end up inventing shifts to record a phone call, and every report you run is a roster report wearing a different label.

One is a claiming engine, the other is a system of record and evidence

This contrast drives everything.

NDIS and Aged Care software exists primarily to get money out of a government payment engine. That is a legitimate and demanding job. It requires current price catalogues, line-item validation, budget drawdown tracking, award-compliant rostering, time capture to the minute, and reconciliation of rejections. The Support at Home payment rules alone run to claim windows, late claim reasons, quarterly budget rollover and separate care management accounts. Get it wrong and revenue stops.

Grant-funded program software does something different. The money has already been committed under a deed. The system’s job is to hold the evidence: who was referred, what was assessed, what was planned, what was delivered, what changed, and whether the program met the targets in the contract. Reporting is an acquittal obligation, not a payment trigger.

Both matter. They are just not the same problem, and the failure modes are opposite. A rejected NDIS claim line is a cash flow event. A weak outcomes dataset shows up years later, in a re-tender, when the funder asks what changed for the people you saw and you cannot answer. By then it is unfixable. You cannot retrospectively collect data you never captured.

Grant-funded programs are measured on outcomes over time

Most Grant-Funded programs now require evidence of client change, not just service counts.

The Data Exchange uses Standard Client/Community Outcomes Reporting (SCORE) under the partnership approach. The Primary Mental Health Care Minimum Data Set mandates instruments including the K10 and the Strengths and Difficulties Questionnaire, administered at specified points in an episode. South Australia’s Results Reporting Data Dock is built on Results Based Accountability and expects assessment coverage across active clients. Many providers also run the Personal Wellbeing Index (PWI), published by Deakin University’s Australian Centre on Quality of Life, a seven-domain subjective wellbeing measure with adult, school-age and intellectual disability versions scored on a 0 to 10 scale.

The common pattern is that an instrument is administered more than once, scored consistently, tracked per client across the episode, and aggregated per program for the funder. That is a longitudinal measurement model, and it has to accommodate whichever instrument the funder specifies, including ones your organisation adopts itself.

NDIS and Aged Care systems track budget utilisation and service delivery against priced units. They are good at that. They are not built to carry a repeatable, configurable outcomes measurement framework that differs by program.

Every funder wants something different

This is the point most procurement processes underestimate when evaluating software for Grant-Funded programs.

Run three or four Grant-Funded programs and you may face three or four unrelated collections, each with its own portal, identifiers, cadence and file format. Here are a few of the common ones:

• DEX (Data EXchange, Department of Social Services, plus several state jurisdictions using their own Program Specific Guidance, including NSW DCJ’s Targeted Earlier Intervention program). Outcomes are reported through SCORE (Standard Client/Community Outcomes Reporting), which spans four domains: circumstances, goals, satisfaction and community. Protocols and DSS guidance changed from March 2026, including group activity data reported at least twice a year, census-style, and updated SCORE reporting guidance. The current protocols specifications run to hundreds of pages.
• PMHC MDS (mental health services commissioned by Primary Health Networks). Funded and owned by the Commonwealth health department. Its own client key, episode, service contact and collection occasion model, with mandated outcome instruments and a versioned data specification.
• AODTS NMDS (Alcohol and Other Drug Treatment Services National Minimum Data Set, held by the Australian Institute of Health and Welfare). Running since 2000 across government-funded AOD treatment specialist services nationally. The unit is the treatment episode, and client matching relies on a statistical linkage key derived from name, date of birth and sex rather than a client number. Collection and submission requirements are reissued each financial year.
• infoShare (NSW Department of Communities and Justice). Family Preservation providers submit a quarterly minimum data set through the infoShare portal, using a DCJ-controlled spreadsheet template, while referrals for the same program are managed separately in ChildStory Partner Community. Two systems, one program.
• IRIS and CRISSP (Victorian Department of Families, Fairness and Housing). IRIS holds client, case and service data for funded family services casework, with a quarterly export to the department. CRISSP covers placement and support. Alcohol and other drug services report separately through the Victorian Alcohol and Drug Collection, and monthly delivery against service agreement targets goes through the Service Delivery Tracking tool.
• OMS via P2i (Queensland). Organisations funded for the Queensland Community Support Scheme register on the Outcome Measurement System portal through P2i and upload an Excel or CSV file of client-level data each quarter, with performance reports lodged as P2i milestone reports when outputs fall outside allowable variation.
• R2D2 (South Australian Department of Human Services). Periodic performance reports built on Results Based Accountability, with narrative “story behind the data” sections sitting alongside the quantitative measures.

Different scope.

Different frequency.

Different file formats.

Different client identifiers.

Different consent handling.

…and by the time you read this article the above departments or reporting obligations have probably changed!

Then add the ones with no collection behind them: a state department that wants a quarterly spreadsheet against contract KPIs, a council that wants attendance and postcode breakdowns, a philanthropic funder that wants a narrative report against a logic model.

The capability that actually matters here is not just “does the system support DEX”. It is whether you can build a new extract, a new field set and a new report for the next funder, without waiting for a vendor release or paying for a costly rebuild.

A platform whose data model is shaped by the NDIS Support Catalogue or the Support at Home service list will bend only so far. Beyond that point you are forcing a round peg into a square hole, and the usual result is that the real reporting happens outside the system, usually in Excel.

The same person, two different funding relationships

There is some overlap between NDIS or Aged Care clients and Grant-Funded program clients. An NDIS participant may also turn up at financial counselling, or an older person receiving Support at Home may also be in a carer support program. It happens, and it is worth being able to see when it does.

But it is generally not frequent enough to build your entire system architecture around. Designing for the minority case, where one person appears in two funding streams, at the cost of the majority case, where they do not, is a poor trade.

And even where a person does appear on both sides, the funding relationships stay separate. Two arrangements, two consent bases, two reporting obligations, two retention rules, and often a legitimate reason to keep one program’s records away from another program’s staff. A safeguarding matter or a conflict-of-interest restriction does not dissolve because the person is also an NDIS participant.

The overlap is a linking problem, not a consolidation mandate.

NDIS and Aged Care rules change constantly. Let a specialist absorb that.

Aged Care alone has seen a new Act, a replacement home care program, new pricing rules, new caps on what providers can charge, and a requirement to review existing care plans, all inside about twelve months. The NDIS resets pricing every July, and further legislative reform is being rolled out in stages. So expect more structural changes.

Anyone operating in these schemes knows the pace. The point is what it costs the software vendor. A platform carrying that regulatory load is spending its roadmap on complying with it. That is the right call for them, and it is genuinely valuable if you claim NDIS or Support at Home revenue. But it is roadmap that is not being spent on your DEX or PMHC MDS extract, your funder’s new KPI set, or the reporting model for the program you won last quarter.

Buy the specialist for the specialist job. Do not ask it to carry everything else.

Sensitive data, tenancy and where it lives

Regardless of which platform you select, the same questions apply. High-volume SaaS is usually delivered as a multi-tenant service, meaning many organisations share the same application and database, with each organisation’s records separated by logic rather than by physical boundary. Shared infrastructure is how vendors keep per-seat pricing low at scale, and that is a reasonable engineering trade-off for many buyers, not a fault in itself. It does however warrant closer examination if you hold child protection records, family violence records, criminal justice records or safeguarding investigations.

You should consider single-tenant when:

• A funder or contract requires you to evidence exactly where data sits and who can reach it.
• A record crossing the wrong boundary creates a safety risk, not just a privacy breach.
• Staff in one program must not see another program’s clients, or a specific client must be walled off from a named staff member.
• You may need to hand an auditor or investigator full visibility of the environment.
• Retention, legal hold or disposal obligations need to be proven, not just asserted.

The trade-off is cost. Dedicated environments (single-tenanted) are upgraded one at a time rather than once across shared infrastructure, so maintenance effort is per-client rather than spread across the vendor’s base. Worth pricing in rather than discovering later.

Questions worth putting to any vendor, in writing:

• Is our data held in a dedicated database instance, or in a shared database separated by row-level logic?
• Which country is it hosted in, which legal entity controls the hosting account, and who holds the encryption keys?
• Can we restrict a program’s records from other programs’ staff, and can that restriction be applied per client where a conflict of interest exists?
• What happens to our data, and in what format, if we exit?
• Is the vendor’s security posture independently attested, and can we see the current report?

The answers will differ by vendor, and there is no single correct architecture. The point is that sensitivity varies enormously between a rostered personal care visit and a disclosure recorded in a child safety matter, and your data model should reflect that difference.

Final thoughts… the pattern that works

If you have made it this far, congratulations. There is a lot to take in and consider.

In short however, we recommend to keep the specialist where the specialist earns its place. If you claim NDIS or Support at Home revenue, run that on software purposely built for those payment engines and let that vendor absorb the regulatory churn.

Then put everything else, most likely your Grant-Funded programs, on a configurable platform that can be shaped to each funder: intake and waitlists, case and support plans, goals and actions, assessments and outcomes instruments, incidents, referrals, brokerage and expenses, and the reporting to go with them. Connect the two where a single client view genuinely matters. A single client view is a data problem and can be solved with identity matching and a reporting layer. It is not a reason to put every program inside one application.

This is where SmarterSoft sits deliberately. We are not an NDIS claiming system and we are not a Support at Home B2G product. We are the configurable system of record for everything else, which for most diversified providers is the larger and less well-served half of the organisation.

Comparison Summary: NDIS vs Aged Care vs. Grant-Funded programs

Frequently asked questions

What is the difference between NDIS funding and Grant-Funding?

NDIS funding is an individual entitlement. A participant holds a plan with a funded budget, and providers claim against it for delivered supports. Grant funding is a contract between a funder and an organisation to deliver an activity for a population over a period. The money is committed up front and the obligation is to report on delivery and outcomes.

Do Grant-Funded programs need rostering software?

Usually not in the NDIS or Aged Care sense. Staff are salaried against funded positions rather than paid per shift, so the constraint is caseload capacity rather than shift coverage. What is needed is caseload allocation, appointment and group session scheduling, waitlist management and resource bookings, tied to the client’s episode rather than to a timesheet.

How do we get a single client view if we run two systems?

Through identity matching and a reporting layer, not by forcing every program into one application. Decide which system is authoritative for which facts, match people across them, and report from a combined view.

Is running two systems more expensive than one?

Not necessarily. The cost of a single system is rarely the licence. It is the customisation needed to make an unsuitable data model fit, the manual workarounds where it does not, and the reporting that ends up in spreadsheets. Two fit-for-purpose systems with a clean boundary are often cheaper to run and much cheaper to change.

Can a Grant-Funded program system handle Fee-For-Service activities?

Yes, and many organisations need it to. Alongside deed-funded work, providers commonly run fee-for-service activities: client contributions, sliding-scale counselling fees, training and workshops sold to other agencies, room hire, EAP contracts, brokered services delivered on behalf of another provider. These are not NDIS or Aged Care claims. There is no government payment engine, no price catalogue and no conformance gateway. What is needed is the ability to record a chargeable activity against a client or an organisation, apply the right rate, and produce an invoice or records for a financial system.

What should we ask a vendor during procurement?

Ask who owns the roadmap. Ask how a new funder’s reporting requirement gets built, who builds it, how long it takes and what it costs. Ask whether your administrators can do things themselves, or whether every change is a vendor ticket.

Then push on the two things that matter most:

• Flexibility: Name a program you actually run and ask them to walk through how they would configure it, end to end, including the funder extract. Ask what happens when a funder changes its specification mid-contract: who absorbs the cost, and what is the turnaround?
• Security: Ask the tenancy and hosting questions above, and ask for the current independent attestation rather than a summary of it. Ask whether you can restrict one program’s records from another program’s staff, and whether that can be applied per client.