Twenty-Two NDIS Support Items Stop Being Claimable on 30 September. One of Them Sits in Every Plan Manager's Catalogue.
Twenty-Two NDIS Support Items Stop Being Claimable on 30 September. One of Them Sits in Every Plan Manager's Catalogue.
This is not a price change and it is not a claiming error. It is a catalogue expiry — and the only signal most providers will get is a quiet gap in the October revenue run.
There is a sheet inside the NDIS Support Catalogue that almost nobody in a finance function has opened. It lists legacy support items — codes that remain valid up to a stated date and then simply stop. The 2026-27 catalogue, published on 3 July, carries twenty-two of them with an end date of 30 September 2026.
That is a fortnight away, and it does not behave like anything else on the NDIS calendar. Price limits change and your revenue per hour moves. Rules change and your claiming process changes. An item expiry is different: the service still happens, the participant still has budget, the support is still legitimate — and the code you were claiming it against no longer accepts a claim until you remap it.
What actually expires
The twenty-two are not a random slice. Broadly, three groups.
Two community nursing items at $124.05 an hour. These sit in the higher-value end of most nursing providers' billing mix, so the dollar exposure per affected participant is meaningful rather than incidental. Worth noting alongside it: the 2026-27 registered nurse limit for community nursing is $128.05, up 3.6% on last year. A provider still claiming against the legacy items is therefore not only heading for a 1 October problem — it is currently billing $4 an hour below the limit it is entitled to.
One plan management item at $65.09. This one needs stating carefully, because it is easy to read as worse than it is. The monthly plan management fee — the $104.45 line that recurs across an entire participant book — was left unchanged in the 2026-27 schedule and is not on the expiry list. What expires is a separate, lower-value plan management item. The exposure is narrower than a plan manager's first reaction to this news will be. It is still worth ten minutes, because it sits in the same catalogue and very likely in the same billing template as the fee that does still work.
Nineteen assistive technology and home modification items. These are the ones most likely to be missed, because AT and home mods are often claimed sporadically. A code you use four times a year does not live in anyone's muscle memory, and it does not get caught by a monthly rhythm.
|
22 items
Legacy support items in the 2026-27 catalogue carrying an end date of 30 September 2026 — two community nursing, one plan management, nineteen AT and home modification.
|
$65.09
The expiring plan management item. The $104.45 monthly plan management fee is unchanged for 2026-27 and is not affected.
|
Why this one fails quietly
Most compliance deadlines announce themselves. A registration lapses and you receive correspondence. A price changes and your software vendor emails a release note. An item expiry produces neither, because from the scheme's point of view nothing went wrong — a code reached its published end date, exactly as the catalogue said it would.
The consequence lands on the other side of the service, which is the part that makes it expensive. Support is delivered in the first week of October. It gets claimed a few days or a few weeks later. The claim fails. Somebody in the claims queue sees a rejection among a batch of rejections and codes it as an ordinary error to be reworked. By the time anyone notices that the same rejection is repeating across every participant, three or four weeks of delivery may already sit behind it.
None of that revenue is lost, assuming the support was legitimate and the remap is done correctly — rejected claims can be corrected and relodged. What you lose is settlement time on the affected items, in a month where you have already paid the staff who delivered them. For a nursing provider with volume sitting on two expiring codes, a few weeks of delayed settlement on that slice of billings is a cash timing problem rather than an administrative one. It is not a revenue stream stopping; it is a portion of it arriving late — which, on the margins the sector is currently running on, is still a month you have to fund.
Three places a dead code hides
Your claiming templates and rostering defaults. This is the obvious one, and it is usually the only one that gets checked. Support item codes get baked into shift types, service templates and bulk upload files, sometimes years ago, sometimes by someone who has left.
Your service agreements. A service agreement that names a specific support item and rate is a document you have given a participant, and from 1 October it will name something that no longer exists. Whether that is a technical breach depends on how the agreement is drafted and how specific it is. What is not in doubt is the practical effect: it is the document a participant or their nominee reads when they query an invoice, and a mismatch between the agreement and the claim is precisely the kind of thing that turns a billing question into a complaint.
Quotes and approvals already in flight. Assistive technology and home modifications have a long tail. A quote issued in August against an item that expires on 30 September, for work scheduled in October, is a problem that already exists in your pipeline today. Nobody will find it by looking at October's claims, because it was created in August.
The remap is a fortnight's work, not an afternoon's
The instinct is to treat this as a find-and-replace exercise. It rarely is, for two reasons.
First, a retiring item does not always map cleanly to a single replacement. Where an old code has been split, or the replacement carries a different unit of measure or claim type, somebody has to judge which new item correctly describes the support actually being delivered — and that has to be a person who understands the service, not whoever owns the spreadsheet.
Second, the change has to be sequenced. Claims for September services must continue to use the old codes even when they are lodged in October. Claims for October services must use the new ones. If you switch the templates over on 28 September to get ahead of it, you have created a different problem for every service still to be claimed from the back half of September.
Where AI is genuinely useful here — and where it isn't
There is a narrow, mechanical piece of this that a language model does well: comparing the previous catalogue against the current one and listing every item whose status, end date, unit or rate has moved. Publishers issue a summary of changes; the ones that hurt are the changes nobody thought worth summarising. Because every line of that output points at a specific row in a specific file, it is checkable in a way most AI output is not.
The second pass is running that list against your own claiming history — the last three or six months of lodged claims — to answer the only question that matters to you: which of these twenty-two have we used, how often, and for which participants? That is a lookup, not an analysis.
What must not be delegated is the mapping decision itself. Choosing which replacement item correctly describes a delivered support is a claiming judgement with compliance consequences, and a model will make a confident, plausible and occasionally wrong choice without signalling any difference between the three.
Four things to do before 30 September
Open the legacy items sheet yourself. Not a summary of it, not a vendor's newsletter about it — the catalogue file. Confirm which of the twenty-two you actually use. Most providers will use none or one or two, and finding that out takes twenty minutes.
Search your pipeline, not just your ledger. Quotes issued, approvals pending, AT and home modification work scheduled into October and beyond. This is where the money is, and it is the step that gets skipped.
Fix the service agreements before you fix the templates. The agreement is the document with a participant's signature on it. Changing your internal codes while leaving the agreement naming an item that no longer exists creates the mismatch you least want to explain.
Decide the cutover rule in writing, now. Old codes for September service dates, new codes for October service dates, regardless of when the claim is lodged. Write that sentence down and give it to whoever runs the claim batch, because they will be asked, and they will otherwise have to guess.
Do you know which support items you would stop being able to claim tomorrow?
Most providers can tell you their rates and cannot tell you their code lifecycle — which is how a fortnight of revenue goes quiet before anyone asks why. PFL provides senior-level outsourced finance, management reporting, and AI automation for Australian NFP, NDIS, and SME organisations, including keeping the billing catalogue and the ledger pointing at the same thing.
Talk to PFL →NDIS — What is the support catalogue (includes the NDIS Support Catalogue 2026-27 download)
NDIS — Pricing arrangements (NDIS Pricing Schedule 2026-27)
NDIS — Pricing and payments
SupportAbility — NDIS Pricing Arrangements and Price Limit Updates 2026-27
Provider360 — NDIS Pricing Schedule 2026-27
Comments
Post a Comment