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 — your registration number, participant 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 why one bad row matters twice over. At upload, a format error in any row — a missing field, a date the portal can’t read, both a quantity and hours — stops the whole file, and the portal hands back an error file with each row’s problems in a new first column. Once a file is accepted, each line is assessed on its own against the participant’s plan and service booking, so a rejection on row 40 doesn’t stop row 39 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.

A rejected line comes back with a short code as well as the NDIA's message. The NDIA's December 2025 self-help guide for providers lists 62 of them, and below is each one in our own words: what it means, what to do, and whether the fix is in the file you upload or outside it first — in the portal, or with the participant.

The NDIA’s exact wording is in its guide, linked under Official sources below, and a code missing from this list may be newer than that guide. If you have the outcome file, our free bulk payment checker reads it in your browser and explains every rejected line with these same words.

Corella’s price book carries per-band NDIS item numbers, checked against the national limits on Settings → NDIS prices, 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. 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. Before a batch is built, Corella checks every NDIS number against the NDIA’s format and every support item against the Pricing Schedule for the day it was delivered, naming each line to fix; and a rejected line can be corrected — its item, quantity or unit price, checked against the Pricing Schedule for the day of service — and claimed again in the next batch.

Corella builds the bulk file ready for you to upload in the NDIA’s provider portal, and makes the rejection half of the process as traceable as the claim half.

One scope note, because it is easy to miss: the bulk file is the road for agency-managed supports. Plan-managed and self-managed supports are invoiced instead, and Corella’s invoice run sends each line on its own route — how the invoice actually differs by management type covers where each of those goes.