How to reduce NDIS claim rejections: 7 common mistakes (and how to fix them)

Rejected NDIS claims are the silent revenue leak no provider talks about. A 5% monthly rejection rate on a provider doing $400,000 a year in claims is $20,000 quietly walking out the door — and most of it never gets recovered, because by the time you spot a rejection, the resubmission window has eaten the rest of your week.

The good news: NDIS claim rejections aren't random. They cluster around the same seven mistakes. Fix these and you fix the leak.

This guide walks through each one, why it happens, and what to change in your claiming process to stop it.

Why claim rejections matter more than the amount on the rejected line

Every rejection costs you twice. First, the original claim amount you can't bank. Second, the time your finance person spends re-entering the line, chasing supporting evidence, and resubmitting through the portal — usually under deadline pressure when something more important should be getting their attention.

Worse, rejections rarely come back the same day. By the time the NDIA flags a problem and you act on it, the original shift might be a month old. Memories are vague. The support worker has moved on. The participant has had ten more shifts since. The cost of fixing a rejection always exceeds the cost of preventing it.

Below are the seven mistakes that drive most rejections for small-to-mid Australian providers. We've ordered them roughly by how much revenue they tend to leak.

1. Claiming under the wrong service item code

What goes wrong: Each NDIS support has a specific line-item code from the current Pricing Arrangements (e.g. 01_011_0107_1_1 for assistance with self-care, weekday daytime). Providers commonly claim a participant's support under a slightly wrong code — usually a day-of-week or time-of-day variant.

The result: the claim looks valid at first glance, but the price doesn't match the price-list entry the NDIA is checking against. Rejection.

Why it happens: Most providers maintain a hand-curated list of "the codes we use" in a spreadsheet. The official Pricing Arrangements update annually on 1 July through the NDIA's Annual Pricing Review, with occasional mid-year version updates published in between (the 2025-26 arrangements have already had a v1.1 release). The hand-curated spreadsheet doesn't update with them. Old codes silently drift out of validity.

How to fix: Sync your service item codes from the current Pricing Arrangements PDF on ndis.gov.au every time it updates. Better — run pre-flight validation on every claim batch against the live price guide before you submit (see mistake 4 below).

2. Mixing NDIA-managed, plan-managed, and self-managed lines on a single invoice

What goes wrong: A participant's plan can have all three management types active across different funding categories. Their Core funding might be NDIA-managed, their Capacity Building plan-managed, and their Capital Supports self-managed.

Each management type goes through a different channel:

• NDIA-managed → claim via PACE bulk upload
• Plan-managed → invoice the plan manager directly, they claim
• Self-managed → invoice the participant or their nominee directly

Mixing them on one invoice means the wrong receiver gets a line they can't process, and the line gets either rejected or sits in limbo while you sort it out.

Why it happens: Providers default to one-invoice-per-participant-per-period as a habit, then discover too late that the participant's plan has mixed management.

How to fix: Branch invoices by management type at the point of generation, not at the point of submission. The cleanest setup is software that flags the management type of each line as it enters the invoice draft and refuses to combine them. Tendaroo's invoicing flow does this by default — every approved shift maps to the right management channel before an invoice is built.

3. Submitting outside the 2-year claim window

What goes wrong: Since 3 October 2024, providers have 2 years from the support start date to submit a claim — a hard window written into the NDIS Act when it was amended. Submit later than that and the line is rejected outright with no easy appeal. Before that change, there was no time limit at all, so providers who haven't reviewed their claiming process recently may not realise the rule even exists. (See the NDIA's claim time limit guidance for the official wording.)

Why it happens: Providers batch-claim weekly or fortnightly, and one shift slips through unrecorded. By the time the missing claim surfaces in a budget review, the window has closed — or, more painfully, providers assume "we've always had longer than this" and discover the new 2-year rule the hard way.

How to fix: Generate invoice drafts automatically from approved shifts, and run a weekly close-out ritual that reviews every shift in the period — claimed, draft, or unclaimed. Anything sitting unclaimed for more than 30 days deserves an alert before the window becomes a problem. Two years feels generous until you see how fast a missed shift can age out of memory.

4. Skipping pre-flight validation before you upload

What goes wrong: Providers prepare a PACE bulk-upload CSV, submit it, and find out at the rejection-report stage that line items, service dates, or claim references don't match the price guide. By then the whole batch is a clean-up job.

Common pre-flight failures:

• Service item code missing from the active price guide
• Service date outside the participant's plan dates
• Claimed amount above the max permitted unit price
• Duplicate claim reference (already submitted)
• Quantity that exceeds the participant's remaining funding category balance

Why it happens: PACE itself doesn't always pre-validate every row before you submit — by the time you see "rejected," you've already burned a submission window.

How to fix: Validate every row locally before you ever generate the CSV. Software that pre-flights against the current price guide and the participant's live plan budget catches problems before they're problems. (Tendaroo's pre-flight claim validation is built around this — every line is checked before the CSV exports.)

5. Misapplying short-notice cancellation rules

What goes wrong: Two opposite mistakes:

1. Over-claiming: providers claim a cancellation under short-notice rules when the notice given was actually within the 2-business-day window — that line gets rejected as not eligible.
2. Under-claiming: providers don't claim eligible short-notice cancellations at all, because the workflow doesn't make it obvious that they're claimable.

The current rule (per the 2025-26 Pricing Arrangements): a cancellation counts as short-notice if the participant gives less than 2 clear business days' notice (this was harmonised across support types in the 2024-25 update; previously different categories had different windows). When that happens, the provider can claim the previously agreed rate — billed using the "Cancellation" drop-down in PACE — but only if all four conditions are met:

1. The relevant support item permits short-notice claims under the current Pricing Arrangements
2. The Service Agreement with the participant includes cancellation arrangements
3. The provider couldn't find alternative billable work for the worker during that time
4. The provider still pays the worker for the time that would have been worked (if not a sole trader/partnership)

For group supports, a short-notice cancellation is claimable at the agreed rate only if the provider can't find a replacement participant for the session.

Why it happens: Cancellations are an exception flow. Most rostering tools handle them as a manual override rather than a first-class workflow, so the four conditions above get applied inconsistently — usually with the worker-payment condition forgotten entirely.

How to fix: Treat cancellations as part of the shift lifecycle, not a side process. Capture the cancellation reason, notice timestamp, and worker re-allocation status at the moment of cancellation. Let the system decide whether the cancellation is claimable based on the four conditions — humans don't need to remember each rule, the software does.

6. Letting progress notes drift away from the shift

What goes wrong: A claim survives the submission gauntlet, gets paid, and then six months later an audit pulls it. The auditor wants the progress note that supports the claim. The note exists — but it was written four days after the shift, in pencil, by a worker who has since left.

Even if the claim was technically valid, evidence written long after the event undermines its credibility. Worst case, you're looking at a clawback.

Why it happens: Notes feel like admin overhead to support workers. If the system lets them be written later, they will be.

How to fix: Enforce same-day notes at the workflow level. Workers can't start their next shift until the previous shift's note is submitted. This sounds harsh; in practice it takes 60 seconds per shift on a mobile app and prevents 100% of "where's the note" audit findings. (We built this enforcement into Tendaroo's mobile app for exactly this reason.)

For audit timeline questions, refer to the NDIS Quality and Safeguards Commission guidance at ndiscommission.gov.au.

7. Manual NDIS number entry creating typos

What goes wrong: Someone types a participant's NDIS number wrong by one digit when invoicing. The claim references a participant who doesn't exist (or, occasionally, a real participant who isn't yours — a worse problem). Rejection.

Why it happens: Typing a 9-digit number into a portal form, every shift, every fortnight, is a process designed to fail.

How to fix: Never re-enter NDIS numbers manually after the participant is set up. Reference participants by your internal ID, let the system fill the NDIS number on every claim, and validate the number against the original record before any export. One-time entry, ten-thousand-time accuracy.

Build a rejection-free claiming workflow

The seven mistakes above all share one root cause: they happen when the steps from completed shift to submitted claim are disconnected, and humans have to remember the rules between each step.

Connect them, and most rejections disappear:

1. Shift gets approved (with the right service item code attached automatically)
2. Note is submitted same-day (mobile-enforced)
3. Invoice draft generated from approved shift, branched by management type
4. Pre-flight validation runs against the live price guide and budget
5. PACE CSV exports clean
6. Rejection reports get pulled within hours and resubmitted before the participant's next shift

That's the loop Tendaroo is built around. If your current setup is leaking 5% to rejections, fixing this loop is one of the highest-ROI changes you'll make this year.

Try Tendaroo free for 30 days — no credit card, no demo call, no sales follow-up. Get to a clean claim batch in your first week.