Knowing what a shift earns before you fill it

If you run rosters for an NDIS or aged-care service, you already know the wage cost of a shift and the amount you can bill for it — you just don’t often put the two numbers next to each other before the shift goes out. This is for rostering and finance staff who want a plain way to work out whether a shift is worth running, using nothing but arithmetic you already have on hand.

Every shift has two sides. There’s what it costs to pay someone to work it — the wage rate for their band, any penalty loading for the day and time, casual loading if they’re casual, travel time if it applies. And there’s what you can bill for it — the NDIS line item for that support category, at the rate your price book has set, up to whatever cap applies for that item.

Subtract one from the other and you get gross contribution: the amount that shift adds before you account for anything else the business carries — insurance, vehicles, admin wages, training, leave provisioning, the office lease. It’s not profit. Profit only exists once all of those overheads are covered across every shift you run. A single shift’s number is a contribution toward that, nothing more, and it’s worth being strict about the distinction, because the moment “margin” quietly becomes “profit” in someone’s head, decisions start assuming money that hasn’t actually been made yet.

The pay side is knowable before anyone works a minute: you know the worker’s band, whether the day attracts a penalty rate, whether it’s a sleepover, and whether travel time will be claimed at clock-off. None of that is a forecast — it’s the same rate table your payroll already runs on. The SCHADS mechanics underneath are the same ones that decide the pay run.

The bill side is equally knowable in advance: the NDIS item you’ll claim against, the price your book has for that item at that band, and the cap that item sits under for the current price guide. Unless the shift changes shape, that number doesn’t move. If your price book is still on last year’s figures, that is the thing to fix first — the 2026-27 pricing schedule moved some caps down, not just up.

Put together, before a single hour is worked, you can already say: this shift, run as planned, contributes this much. That’s the whole calculation. No forecasting model, no judgement call — it’s the pay-side number subtracted from the bill-side number, both of which already exist in your systems.

Here’s the part worth sitting with. Once a shift is filled and worked, the wage cost is locked in. The worker clocked on, the hours are what they are, the penalty loading applied or it didn’t, the travel time was claimed or it wasn’t. Nothing about the pay side can be revisited after the fact except by disputing a timesheet, which is a different conversation entirely.

The bill side has a little more flexibility right up until you submit the claim — you can still choose which item to claim against, within what actually happened — but the shift itself, the thing that generates the cost, is done. You’re now managing what already occurred rather than choosing what will occur.

Before the shift is filled, both sides are still soft. You can pick a different worker at a different band. You can shift the start time half an hour to dodge a penalty window. You can decide a two-hour shift isn’t worth the travel cost and adjust the visit length instead. You can choose whether this is the kind of shift where a sleepover allowance makes sense or where it doesn’t. Every one of those choices changes the arithmetic, and every one of them is only available while the shift is still an entry on a roster board rather than a worked hour on a timesheet. That’s the actual point of costing a shift early: not to predict, but to catch the moment where the numbers are still adjustable, before they set.

In practice, checking the gross contribution before you assign a worker tends to surface a small number of recurring issues: a shift that only works financially with a particular band of worker, a time slot that quietly triggers a weekend or public holiday loading nobody budgeted for, or a support category where the price cap sits close enough to your standard wage cost that even a short delay or extra travel claim tips it negative.

None of these are dramatic discoveries. They’re the kind of thing that’s obvious in hindsight and invisible in a roster full of shifts you’re trying to fill quickly. Seeing the number before the shift is filled just moves the decision to the point where it’s still cheap to make.

This is a finance and rostering-level view, not something that belongs on a roster board a support worker opens on their phone. It’s scoped to the people making billing and rostering decisions. Whether coordinators can see it is a per-tenant setting, and it is off by default — an organisation turns it on deliberately. Support workers never see it at all. Support workers see their shift, their client, their time and location. They don’t need, and shouldn’t see, what the organisation makes on the hour they’re about to work, and nothing about this capability changes that.

It’s also worth being clear about what this isn’t. It’s a subtraction — a pay-side number taken from a bill-side number, both drawn from rate tables and a price book that already exist. There’s no modelling, no prediction of no-shows or cancellations, no AI making a judgement about whether the shift is a good idea. It tells you what the shift is worth on paper, given the plan as it stands. Whether that plan holds is still up to whoever’s running the roster.

Corella’s rostering board, payroll engine and NDIS price book already sit in the one system, so the pay-side and bill-side numbers for an unfilled shift are the same numbers the platform uses to run payroll and generate invoices — there’s no separate costing tool to wire in or reconcile against. The gross contribution view sits with billing and rostering roles; whether coordinators see it is a per-tenant setting that is off by default, and support workers never see it. It shows what a shift is worth before you fill it, based on the rates you’ve already set — it doesn’t tell you whether to run the shift, and it isn’t profit.