Rebuilding the FY27 Forecast Around Three Dates You Don't Control

Abstract illustration of a forecast line broken into dated step changes rather than a smooth curve

Rebuilding the FY27 Forecast Around Three Dates You Don't Control

Each one is a step change on a specific day. None of them belongs in the commentary — they belong in the model, and each has a different shape.

Three dated changes land in the next four months and none of them are negotiable.

On 1 October 2026, personal care moves from the Independence category to Clinical Supports under Support at Home, meaning the Commonwealth fully funds it and participants stop contributing. On 1 December 2026, NDIS claims must be submitted within 90 days of the support being delivered. On 1 January 2027, recommended maximum prices for Social, Community and Civic Participation supports delivered by unregistered providers drop by 10%, and annual indexation for those items ceases.

Most FY27 models I've seen handle these as a sentence under the revenue schedule. That's the wrong place for them, and the reason is mechanical rather than stylistic: a change described in the commentary can't be flexed, can't be varied in a scenario, and can't be found again in six months when one of the dates moves. This post is about the modelling, not the strategy — the strategic version of this argument ran last Friday and is linked below.

Rule one: model the date, not the year

A 10% price reduction from 1 January is not a 10% revenue reduction in FY27. It's a 10% reduction on roughly half a year's volume in the affected line items, and about 5% of the annual total, which is a materially different number to explain to a board.

The fix is unglamorous. Build FY27 monthly, put a dated switch on each change, and let the annual figure fall out of the months rather than the other way round. If your model is annual with a monthly phasing tab bolted on, the phasing tab is where these belong and it needs a date column, not a percentage-of-year column.

1 October: a mix change disguised as nothing

The Support at Home change is the one most likely to be modelled as a non-event, because at the total revenue line it very nearly is. The service is still delivered, still funded, still claimed. What changes is who pays.

That makes it a balance sheet and cash timing change more than a P&L one. The participant-contribution component of personal care revenue goes to zero and the same service arrives instead as government-funded revenue. Those two streams have different collection lags, different failure modes and — importantly — different bad debt characteristics. If your doubtful debt provision is a single blended percentage across all receivables, the mix underneath it changes on 1 October and the model won't tell you.

The operational trap sits in the cut-over, and the Department has been explicit about it: claims for services delivered before 1 October still attract a participant contribution, even if they are claimed after 1 October. So the October and November claim runs carry two contribution regimes at once, split by delivery date rather than claim date. Model that explicitly as an overlap, and get the September delivered-not-yet-claimed balance out of the system before you need it, not after.

1 Dec 2026
NDIS claims must be submitted within 90 days of delivering the support. A working capital and forfeiture event, not a pricing one.
1 Jan 2027
SCCP prices for unregistered providers fall 10% and indexation ceases — a widening gap, not a one-off step.

1 December: model the tail, not the mean

The claim window is not a revenue assumption. It's a control assumption with a revenue consequence, and the only way to size it is from your own historical data.

Take the last twelve months of delivered services and calculate, for each one, the number of days between delivery date and claim submission date. You now have a distribution. The mean of that distribution is close to useless here. What matters is the right-hand tail: what proportion of your claim volume, by value, was submitted more than 90 days after delivery? That percentage, applied to forward revenue, is your forfeiture exposure — not a provision, but a number that tells you how much process change the December date is actually demanding.

If the answer is 0.3%, you have a monitoring task. If it's 4%, you have a project, and it needs to start in September rather than November. Either way it's a measurement you can do this week from data you already hold, and it beats the alternative of forming a view about it.

1 January: the second-order effect is the bigger one

The 10% reduction gets the attention. The clause worth modelling is the other one: annual indexation for those items ceases.

A one-off 10% cut is a step. A cut plus frozen indexation, against a cost base that continues to index, is a wedge that widens every year. In a single-year FY27 model this is invisible — you'll see the 10% and nothing else. In a three-year view it's the dominant term, because it compounds against wage growth that doesn't stop. If your model only goes to June 2027, this is the change that argues for extending it.

It's also the first time registered and unregistered providers will be paid differently for the same support, which makes registration status a modelling variable rather than a compliance fact. If you deliver SCCP supports through both registered and unregistered arms, or you're weighing registration, that decision now has a quantifiable price attached to it in a way it didn't before.

Keep the assumptions somewhere the calculations aren't

This is the structural point, and it matters more than any of the three changes individually.

Every one of these dates could move, and one of them still isn't settled — the interim Schedule E increase of around 15% flagged for 1 October 2026 was expressed as the Fair Work Commission's provisional view in its 1 June 2026 decision, with draft determinations issued, submissions closed at the end of June and the final determination still to come as at late August. A model where "1 October" is typed into fourteen formulas cannot absorb that. A model where every dated assumption lives in one register — assumption, value, effective date, source, status, last verified — and every calculation refers back to it, can be re-run in an afternoon.

Add a status column and use it honestly: confirmed, provisional, or assumed. Boards deal with a provisional assumption clearly labelled far better than they deal with discovering that a confirmed-looking number was a guess. It is also the fastest way to answer the only question that matters when a date slips, which is "what else does that touch."

Where AI earns its place — and where it doesn't

Two jobs in this workflow are genuinely well suited to AI assistance, and they're both downstream of the modelling rather than part of it.

The first is decomposing the variance between model versions. When you re-run the forecast after a date moves, the useful output isn't the new number, it's the bridge: this line moved by this much because of this change. Producing that bridge by hand across a dozen assumptions is an afternoon's work and it's the first thing dropped under deadline. Pointing a tool at two versions of the same structured output and asking it to identify and quantify the differences is a well-defined comparison task.

The second is drafting the "what changed and why" narrative for the management reporting pack from that bridge. Not writing the commentary — drafting it, from a set of quantified movements you've already validated, so that a person edits rather than starts blank.

What must not be handed over: the assumption register itself. Every value in it needs a human who verified it against a source and can say when. A tool that populates an assumption from a plausible-sounding search result has introduced an error that will propagate through the entire model and survive every subsequent review, because nobody re-checks a number that's already in the register. The register is the one artefact in this whole workflow where the provenance has to be human and documented.

Before financial or participant data goes into an AI tool: forecasts, claim data and participant-level figures are sensitive. Confirm whether the vendor trains its models on customer inputs, and prefer a tool where your data isn't retained for training. This matters more than usual for forecast work, because a model version is a fairly complete picture of an organisation's position.

Can your FY27 model absorb one of these dates moving?

If the answer involves finding every formula the date is buried in, the model isn't finished. PFL provides senior-level outsourced finance, management reporting, and AI automation for Australian NFP, NDIS, and SME organisations — including building forecasts that survive the assumptions changing.

Talk to PFL →
This post is general commentary based on publicly available information and does not constitute legal, tax or financial advice. Several of the settings referred to here remain subject to further process — verify current status before relying on any of them. Always seek independent professional advice before acting.
Timothy, CPA is Managing Director of Professional Financelink (PFL), providing senior-level outsourced finance, management reporting, and AI automation for Australian NFP, NDIS, and SME organisations. 20+ years in finance leadership across NFP, NDIS and SME.

Comments

Popular posts from this blog

Google Gemma 4 Just Launched — And It Might Solve Finance's Biggest AI Privacy Problem

Claude vs Gemini for Australian Finance: An Honest Comparison After 12 Months of Using Both

Why NFP Boards Are Finally Talking About AI — And What the Finance Team Should Do Before They Ask