NDIS Plan Dashboard
Catches NDIS funding that would otherwise expire unspent — and leaves every spending decision with a person.
It reads each plan against actual spend and flags the funding about to expire — before it does.
Where this works well
This pattern works when a participant's plan data already lives somewhere structured — a plan manager's portal, a self-management spreadsheet that's kept current, or a provider's client management system with line-item budgets recorded against NDIS support categories. If the numbers exist and are reconciled monthly, turning them into early warnings about under-utilisation and expiry risk is straightforward and genuinely useful.
It's most valuable for support coordinators and plan managers carrying a caseload, where the same expiry problem repeats across dozens of participants and no one person can hold it all in their head. The slow, invisible problem it makes visible is funding quietly lapsing — Capital sitting unspent because a home-modification quote was never chased, Capacity Building expiring because therapy was booked fortnightly when the plan funded weekly.
Where it works badly
It works badly when spend isn't recorded against line items in any consistent way — where invoices arrive as PDFs in an inbox, get paid, and only get categorised at plan-review time. In that situation the dashboard would be confidently wrong, because the utilisation figures it's reading are stale or miscategorised, and a confident wrong number is worse than no number.
It also works badly for a single participant with a simple, fully-utilised plan: the overhead of feeding it data outweighs glancing at a statement. The honest test is whether the same budget-tracking question recurs often enough, across enough plans, that catching it early is worth the setup. If you manage three plans and you already know them by heart, this isn't for you yet.
What it doesn't do — and shouldn't
It does not approve anything. Every recommendation on this screen — book transport, schedule community access, request an OT assessment — is a prompt to a person, not an action taken. It surfaces that funding is at risk and suggests where it could go; the participant, their coordinator, or their nominee decides whether that spending is actually appropriate to the person's goals.
That distinction is deliberate. An NDIS plan is a person's funded support, not a budget to be drained to hit a utilisation target, and "spend it before you lose it" is bad advice if the spending doesn't serve the participant. The tool's job is to make sure the choice is made on time and with eyes open — not to make it. Recaptured time goes back to the coordinator's judgement, not out of the team.
What your data has to look like for this to work
This is the part most people haven't thought about, and it's usually the real first job. For this dashboard to tell the truth, three things have to be true of your data. First, spend has to be recorded against NDIS line items — the support-item numbers, in the 01_011 / 07_001 format — consistently, so "Transport" always means the same thing and isn't sometimes "travel" and sometimes buried in a general invoice. Second, it has to be reasonably current; a dashboard reading three-month-old data will flag risks that are already resolved and miss ones that aren't. Third, plan dates and category budgets have to be captured accurately at the start, because every "at-risk" figure is calculated against them — a wrong plan end-date makes every warning wrong.
Most organisations have maybe one of those three in good shape. Getting the other two right — usually a matter of how invoices are captured and categorised at the point they arrive, not buying any new tool — is the work that has to happen before the AI layer is worth anything. That's the part we help with, and it's typically bigger and more valuable than the dashboard itself.
Will it push someone to spend money they shouldn't, just to hit a utilisation target?
No. It flags funding that's likely to expire and suggests where it could go, but it never books or claims anything. A person — the participant, their nominee, or their coordinator — decides whether the spend actually serves the participant's goals. "Use it or lose it" is the wrong instinct if the support isn't right for the person, and the tool is built to leave that judgment with a human.
What if our spend data is messy — invoices in an inbox, only categorised at plan review?
Then getting spend recorded against line items consistently is the real first job, and it's the part we help with. Until invoices are categorised at the point they arrive, the dashboard's utilisation figures will be stale or wrong. Fixing how the information is captured is usually bigger and more valuable than the AI layer sitting on top of it.
Does this replace our support coordinators or plan managers?
No. It does the watching no one can do by hand across a whole caseload — tracking expiry risk on dozens of plans at once — so their time goes to the judgment calls and the conversations with participants. It recaptures capacity; it doesn't reduce the team.
How current does the data need to be?
Current enough that you'd trust it to act on — for most caseloads that means spend reconciled at least monthly. A dashboard reading three-month-old figures will raise alarms about funding that's already been spent and miss problems that have just appeared. The tool is only as timely as the data feeding it.
Where does the participant's data go?
The demo you're looking at runs on fake data and makes no claims against anyone's plan. For a real build, data stays in your environment wherever possible; we scope handling to your obligations under NDIS privacy rules and the Australian Privacy Principles, and document where every field is read from and who can see it.
Estimated build: 3–5 weeks. Most of it is template work we've already done.
Fixed scope, fixed price, fixed dates.
The cost band reflects the engagement shape, not a per-feature line item. We work on fixed scope, fixed price, fixed dates — see the services catalogue for what falls inside each band.
Considering this for your org?
The honest place to start is a bite-sized first piece — one contained change, low risk. Tell us where it hurts; we’ll play it back, scope it, and show you what’s possible.