Why NDIA bulk payment requests get rejected (and how to stop it)

This is for whoever pushes the button on bulk claims — the finance officer or coordinator who’s just watched a file bounce back from the provider portal and needs to know why, without wading through the NDIA’s own documentation.

The NDIA’s bulk payment request format is a CSV with sixteen fixed columns — participant number, plan number, support item number, quantity, unit price, dates of support, claim reference, and so on. It’s built to let a provider claim for many participants and many shifts in one upload rather than one claim at a time. That’s also exactly why one bad row can sink the batch, or at least sink itself: the file is processed line by line against the participant’s plan, so an error in row 40 doesn’t necessarily void row 39, but it will stop row 40 from paying.

Get the structure right and most of what follows is just data accuracy. Get it wrong and you’ll be troubleshooting a rejection without knowing which of sixteen fields caused it.

This catches more files than anything else, and it’s the most avoidable. The header row isn’t a label for humans — the portal reads it to map your columns to its own fields. If a column is renamed, reordered, given extra whitespace, or exported by a system that quietly changes capitalisation, the whole file can be rejected before a single claim line is even assessed against a plan.

If you’re building this file by hand or exporting it from a spreadsheet someone’s edited, treat the header row as read-only. Don’t “tidy it up.” Don’t add a column for your own reference numbers in the middle of the sixteen. If you need to track something internally, do it in a separate column outside the sixteen or in your own system, not inside the file you’re uploading.

Every support item number in the file has to correspond to a registration group your organisation actually holds, and to a category that’s active in the participant’s plan. This is the second most common rejection, and it’s rarely a typo — it’s usually a genuine mismatch between what was delivered, what was billed, and what the provider is actually registered to claim against.

It shows up most often when:

• a support item sits in a registration group the provider hasn’t been approved for
• the item is being claimed against the wrong support category for that participant’s plan
• the participant’s plan doesn’t have that category funded at all, or the funding has been exhausted

None of this is visible from the CSV file itself — you need the plan and the registration status sitting next to the price book you’re billing from, which is why keeping those two things reconciled (rather than treating billing and plan management as separate jobs done by separate people) prevents most of it before the file is even generated.

Support item catalogues change every year, and each change quietly retires or replaces some item numbers. If your price book or your export template is running last year’s list, you’ll generate perfectly well-formed claim lines against item numbers the NDIA no longer accepts. The file uploads fine; the rejection only shows up on the outcome side, often days later, by which point the shift is long finished and the story behind the claim has gone cold for whoever’s now trying to fix it.

The practical fix is boring but effective: before the start of a new catalogue year, check every recurring or templated support item you bill against the new item list, not just the ones you remember changing. Retirements aren’t always the obvious high-volume items.

What moved in the current schedule — including the caps that went down — is set out here: the 2026-27 NDIS Pricing Schedule, and what it means for your claims.

The claim reference field is where most of the long-term pain lives. It’s easy to generate a reference number that satisfies the portal on the way in and means nothing to anyone six weeks later when a rejection needs investigating. If your claim reference doesn’t map cleanly back to a specific shift, timesheet or invoice line in your own records, you’re stuck manually cross-referencing dates, participants and item numbers to work out what the rejected line was even for — usually under time pressure, because rejected claims don’t get younger while you investigate.

The fix is to treat the claim reference as a lookup key, not a formality. Whatever your billing system generates, it should let you go from “this reference was rejected” back to “this was Thursday’s shift for this participant, billed under this item number” in one step, not a spreadsheet search.

The NDIA returns an outcome for each claim line — paid, part-paid, or rejected, usually with a reason code attached. The single most useful discipline here is separating the file you submitted from the file that comes back: don’t just note “some of it got rejected” and move on. Go through the outcome line by line, work out which of the causes above (or a plan-specific one, like exhausted funding) applied to each rejected line, fix the actual cause — not just the number — and re-claim it under a fresh reference. Re-submitting a rejected line under its original reference is asking for the same rejection twice.

Corella’s price book carries per-band NDIS items and current caps, and its NDIA 16-column bulk payment CSV is generated from the same claim data as your invoices, so header exactness and item-number mapping aren’t manual steps. Since August 2026, Corella also reads the outcome file you get back from the portal and records what was actually paid, part-paid or rejected against each claim line — carrying the NDIA’s own rejection reason — and lets you release just the rejected lines to re-claim under a fresh reference, without re-keying the rest of the batch.

The bulk file still goes into the provider portal by hand; nothing here submits directly to the NDIA or claims to be automatic — it’s there to make the rejection half of the process as traceable as the claim half.