How to Submit an NDIS Bulk Payment Request Without Rejections

An NDIS bulk payment request is the CSV a registered provider uploads to the myplace portal to claim for many supports at once. Each row carries the participant's NDIS number, the support item number, service dates, quantity and price. The NDIA validates the file on upload and returns a result for every line — and lines fail for a small, repeatable set of reasons.

The useful distinction, and the one that decides what you do next, is between a file that was rejected and lines that were not paid. They look similar in a portal and they have nothing to do with each other.

Why a whole NDIS bulk payment request gets rejected

Structural problems fail the upload before any line is assessed. The file is not partially processed — it is refused.

• Column count or order does not match what the portal expects
• Date format differs from the required format
• Registration number or ABN wrong in the header
• Encoding or delimiter problems, usually from opening and re-saving the file in a spreadsheet
• Trailing blank rows, or stray characters in a numeric column

That last one deserves emphasis. Opening a claim CSV in Excel to "just check it" is the single most common way a valid file becomes invalid — Excel reformats dates, strips leading zeros from NDIS numbers, and adds its own encoding on save.

Why individual lines fail

A file can upload cleanly and still not pay. These are the reasons, and none of them are file problems:

Line failure	What it actually means
Insufficient funds	The budget category is exhausted, or the money is in a different category
Service date outside plan	The plan ended, or had not started, on the date of service
Price exceeds limit	The claimed rate is above the cap — the claim is refused, not trimmed
Invalid support item	Item number retired or not valid for that date of service
Plan management type changed	The participant moved to plan-managed or self-managed; you are claiming the wrong way
Not endorsed (PACE)	The participant has not nominated you for that support type

That last row is worth knowing about specifically. Under PACE, participants endorse providers for particular support types. Where you are not endorsed, claiming can fail even though funding exists and everything about your file is correct. Claim failures that begin right after a participant transitions to PACE are usually an endorsement problem, and rebuilding the file will not fix them.

What to validate before you upload

Everything below can be checked before the file leaves your system, which is the point — a rejection you could have predicted is a week of cash flow you did not need to lose.

1. Every line has a valid support item for its service date. Items are retired and replaced; a catalogue loaded at go-live and never refreshed is a slow source of failures.
2. No line exceeds the price limit for its item, region and date.
3. Service dates fall inside an active plan.
4. Remaining funds cover the claim in the correct budget category, not just overall.
5. Day-of-week and time-of-day match the item. A Sunday shift claimed on a weekday item will pay and draw down wrongly, which surfaces later at review.
6. No duplicates. Same participant, same item, same date, same quantity — usually a re-claim after a failed upload.

Record the result of every line

This is the practice that separates providers who resolve claim problems from providers who accumulate them.

When results come back, store them against the originating invoice line — not as a batch summary. A batch summary tells you 12 lines failed. Line-level results tell you which 12, for which participants, for what reason, so that six are re-claimed today and six are recognised as an endorsement issue to resolve with the participant.

The same applies to payment. Reconcile the remittance against what you claimed, line by line. A line that paid at a lower amount than submitted, or for fewer units, is only visible if you compare — and if you never compare, partial payment looks exactly like full payment in a bank feed.

The habit that prevents most of this

Validate at the point of invoicing, not at the point of claiming. If an invoice line cannot be claimed — wrong item, over the cap, no funding left — the best time to know is when it is raised and someone can still do something about it, not three weeks later in a batch of rejections that now needs unpicking against a closed period.