NDIS claiming without the spreadsheet gymnastics

Claiming feels like a month-end finance task, but it really begins on the shift. If the delivered time, the support item and the proof of support aren’t captured when the work happens, month-end becomes an archaeology project — reconstructing what was delivered from memory, texts and half-finished notes.

The providers who claim fastest are the ones whose approved timesheets already carry everything a claim needs, because the shift screen made capturing it the path of least resistance.

For registered providers, the NDIA bulk payment request is a fixed-format CSV you upload to the myplace provider portal. It looks intimidating, but it’s just a structured list of what you delivered. Each row broadly needs:

• The participant’s NDIS number and your registration number.
• The support item number being claimed against.
• The dates the support was delivered.
• The quantity — hours or units — and the unit price.
• A GST code, since most supports are GST-free but not all.
• A claim type, which is how cancellations, travel and reports are flagged.

The portal is fussy: the columns must be in the right order, the item numbers must be valid, prices must sit within the current caps, and even the file name has to follow a pattern. Miss one and the whole file bounces — which is exactly why hand-built spreadsheets are so painful.

The time cost of claiming rarely shows up in the upload itself. It hides in the preparation:

• Re-keying delivered shifts out of the roster and into a claim spreadsheet.
• Looking up the right support item number for each line, every time.
• Catching price-cap breaches by eye before the portal catches them for you.
• Coding cancellations correctly so short-notice cancellations claim and the rest don’t.
• Chasing the proof-of-support documents separately, in a different system, to satisfy an audit later.

None of that is claiming. It’s the tax you pay for your data living in three places that don’t talk to each other.

When rostering, billing and documents share one system, the spreadsheet in the middle simply disappears:

• Your price bookalready holds each support item number and its current cap, so lines are priced correctly as they’re created.
• An invoice run groups delivered, approved shifts by client and funding lane — NDIA-managed, plan-managed, self-managed, private.
• One export produces the bulk payment request CSV in the exact format the portal expects: item numbers, dates, quantities, GST codes, cancellation and travel claim types, and a portal-ready file name.
• The proof-of-support documents are already attached, and shifts missing a required approved form are held out of the run until the evidence exists — so you aren’t claiming for something you can’t stand behind.

The honest part:Corella generates the file — it does not claim directly through PRODA or PACE. You download the CSV and upload it to the portal. It’s the same file you’d build by hand, without the hand.

Not every claim goes to the NDIA. Invoice runs route plan-managed clients’ invoices to their plan manager with the right bill-to details, and produce plain tax invoices for self-managed and private clients. Plan managers running on Corella get the other side of that — an invoice inbox, provider records, claims with an ABA bank file for payment runs, and participant statements — the same billing engine pointed at their lane.