Skip to main content
Ledger Map
Start your map

Problems

NDIS payment request rejected in the portal

A rejected line means the myplace portal read your bulk payment request row and would not pay it. No money moves and no remittance row appears, so Xero shows nothing at all: the invoice simply stays open and ages. Fix what the results file names, release the line from its old batch, and send it again in a new file.

Key facts

What a rejection actually is
The claim was received and assessed but was not accepted, so nothing is paid for that line1
What a successful upload proves
That the file was read. A successful response does not guarantee that the claim was accepted, so the status on each line has to be read separately1
The unit of rejection
One line. Each item comes back as Successful or Rejected, and a rejected item shows an error message on its own line2
What the reason codes cover
Plan dates, service booking dates, item registration, price limits, duplicates, submission timeframes and available funding, each with its own code1
What the ledger records
Nothing. No money arrived for that line, so the canonical templates carry no posting for it: no receipt, no remittance row and no credit note6
What has to happen before you resubmit
The line has to be removed from the earlier upload. An item included in a previous bulk upload does not appear in new uploads by itself2
What the templates do post
A reversal after payment, as a credit note against the original invoice line on that line's own account and tax type, so the batch total still equals the deposit6
The tax code the corrected row carries
One code per line: P1 for tax claimable at 10 percent, P2 for GST free, or P5 for GST out of scope3
A reason no file check will show
For specialist disability accommodation, home and living supports including SIL, and behaviour supports, the provider has to be recorded as a my provider in the participant's plan whichever way that plan is managed, and not being recorded there can produce automatic rejections5
How rejections are meant to be carried
As a standing weekly queue rather than as incidents handled when noticed, with a documented reason on each one4

What the portal means by rejected

A rejection is not a transmission failure. The file arrived, the portal read the row, and decided the claim would not be paid. That tells you where the answer is: on the line in the payment request results.

An NDIS rejection means the claim was received and assessed but was not accepted.1

Three different events get called rejected in a practice, and each needs a different answer in the ledger.

  • The file did not lodge. Nothing was assessed, so rebuild it and upload it again.
  • A line was refused at assessment, which is the case this page is about. Nothing was paid for it and nothing posts anywhere.
  • A paid line is taken back later. That arrives as a negative row in a later batch, posted as a credit note against the original invoice.

The line is the unit, not the file

A large batch can lodge cleanly and still contain lines that will pay nothing. Each line is assessed on its own and comes back with its own status, so a file marked successful says only that the portal could read it.

each line item will show as either Successful or Rejected. Rejected items will display an error message on the relevant line.2

This is where most practices lose the thread. The upload succeeded, the batch looks done, the results screen is closed. The rejected lines are still in it, and the only other place they exist is an invoice in Xero nobody has a reason to open.

The columns the rejection codes point at

The bulk payment request is a fixed order CSV read by position. Sixteen columns go up, and the published rejection codes point at seven of them. Some of those checks are pure format and the rest are read against the participant's plan, which is why a row can be typed perfectly and still fail.

Bulk payment request, the columns the rejection codes point atSeven columns of the NDIS bulk payment request in portal order with the rule the portal applies to each: NDISNumber, SupportsDeliveredFrom, SupportsDeliveredTo, SupportNumber, Quantity, Hours and UnitPrice, with the notes that the portal reads by position, that the reason for a rejection lives in the results rather than in the uploaded file, and that a file can lodge successfully and still carry rejected rows.NDIS myplace provider portalBulk payment request, the columns therejection codes point atCSV, sixteen columns in fixed order, one rowper claim line. Seven of them carry thechecks the published rejection codes name.NDISNumberThe participant's NDIS number, numbers only:nine digits starting 43.A number can be correctly formatted andstill fail, because the portal reads itagainst a plan. A valid number on an endedplan is a plan rejection, not a formatone.SupportsDeliveredFromThe first service date, written YYYY-MM-DDor DD-MM-YYYY. The portal also takes / \ . :; and || in place of the dash.This is the date the plan and the servicebooking are checked against, so a sessiondelivered a day before the booking startedfails here rather than on the date format.SupportsDeliveredToThe last service date, in the same formatsand never before the from date.A range that spans the end of one plan andthe start of the next is its ownrejection, and it has to be split into tworows.SupportNumberThe support item code from the supportcatalogue, up to 60 characters, for example15_056_0128_1_3.The item has to be one the provider canclaim for. An item code copied fromanother practice can exist in thecatalogue and still be refused.QuantityThe number of units claimed, up to fivedigits. The guide's field table acceptsNNNNN or NNN.NN and its own worked examplepairs Quantity 2.5 with Hours 1, while itserror messages ask for a whole number andreject a row carrying both columns, so awhole number in one column passes on eitherreading.The two duration columns are mutuallyexclusive, so a row carrying both Quantityand Hours breaks the file rule before theplan behind it matters.HoursThe duration written HHH:MM, so two and ahalf hours is 2:30, and never in decimalform. The portal reads either Hours orQuantity on a row, and its error messagesreject a row that carries both.The colon form is the trap. Two and a halfhours is 2:30, and a decimal typed here isa format break rather than anything aboutthe plan.UnitPriceThe price per unit sold, or the hourly priceof the service provided, in dollars andcents with no dollar sign: up to eightdigits and two decimals. Where the amountentered is above the maximum per unitcatalogue price for the item, the portalpays only up to that price.Tax inclusive, so a price that looks rightnet can still sit above the limit. Whenthe same item comes back rejected across abatch, that points at the rate card ratherthan at one claim.Watch forThe portal reads by position, so a filewhose columns are correct but reorderedfails as a whole.The reason lives in the results, not inthe file you uploaded, so the file on yourdesktop still looks right afterwards.A file can lodge successfully and stillcarry rejected rows, because each line isassessed on its own.
Plate 1Seven of the sixteen claim file columns, with the portal's own rule on each.

Two of these checks repeat across a batch rather than landing on one participant: a duration typed as a decimal instead of the colon form, and a unit price above the item's limit after a rate card change. A reason that lands on every line for one item points at the file or the rate card rather than at a plan.

Reason codes, grouped by what they mean

The agency answers with a code and a description. What matters is not the list but the grouping: some codes point at a file you can fix and send again, and some point at a claim the agency will not pay whatever you do to the row.

Rejection code groups, and what each one means for the invoice1
What the code is aboutCodes in that groupWhat it means for the invoice
The plan and the datesC03, C28, V13, V26, V36, V43The service sat outside the plan, the booking or the management type. Splitting the dates may fix it; a service outside a plan, or a category the provider cannot claim under that management type, may not be claimable at all.
The support itemC15The provider is not registered for that support item. Check the registration groups and the item code before re-issuing.
The priceC38, V31The price is above the catalogue or the price limit. The rate card moved, so the same rejection lands on every line for that item.
The funding leftP01, P03, V16, V17, V27The booking, the budget or the funding period does not carry the amount claimed, and V16 is an item with no funding left at all. That is a plan question rather than a file one.
A duplicateP04, V04The line is already lodged. Check what was paid first, or the correction becomes a second duplicate.
TimingC27, C39A future date, or outside the submission window. That window turns a fixable claim into an unpayable one.

These are a claiming API's reject reason codes, published by a claiming vendor rather than by the agency, whose own troubleshooting page refused an automated fetch on the day this page was written. The portal's own results wording may differ from them. Use the grouping to triage, and read the description the portal returned on your own line.

Why your ledger shows nothing at all

Here is the half no rejection guide covers. A rejected line pays nothing, so there is no receipt to record, no remittance row to match and no credit note to raise. The invoice sits in Xero as it did the day it was raised: open, aging, and indistinguishable from a debtor who has not paid yet.

So the ledger carries no signal. Aged receivables shows the amount but not the reason, and the settlement account for the rail balances, because it only ever held the money that arrived. Every report agrees, and every one is missing the refusal.

Compare that with a reversal after payment, which the canonical templates do carry: the NDIA rail posts a credit note against the original invoice line, on that line's own account and tax type, so the later batch still equals its deposit. A claim time rejection has no component, because nothing arrived to post.

Working a results file that has rejections in it

The order matters in one place: the line has to come out of the old batch before the corrected invoice can go into a new one.

  1. Export or screenshot the results before the screen is closed, so each reason survives outside the portal.
  2. List the rejected lines against their invoice numbers. That list is the only record of the rejection outside the portal.
  3. Group them by reason code. One rate card problem usually explains most of a batch.
  4. Delete the rejected item from the bulk upload batch, which is what makes it claimable again.
  5. Revert the invoice to draft, correct the code, the participant number, the dates or the price, and re-issue it.
  6. Build a new bulk upload with the corrected lines and send it.
  7. Leave the Xero invoice open. It stays open until a corrected claim is paid.

Reverting and re-issuing an invoice usually pushes an update to Xero. If the original invoice date sits in a closed period, that update runs into the lock date rather than into anything about the claim, and a document dated before the lock date covers what happens then.

Release the line before you resubmit

This is the most common way a correction fails silently. The invoice is fixed and re-issued, a new upload is built, and the corrected line is not in it. Nothing warns you, because that item already belongs to an earlier batch.

If an item was included in a previous bulk upload, it will not appear in new uploads automatically. You must first remove it from the previous upload before it becomes available again.2

The check is to count. The new file should carry as many corrected lines as the results rejected, and a file that comes out shorter is telling you which ones were left behind.

The line that is not going to be paid

Some rejections are corrections and some are answers. A wrong item code is a correction. A service delivered after the plan ended, or a support with no funding left, is the agency saying it will not pay for that service. Sending the row again produces the same code.

At that point it stops being a claiming question and becomes a debtor question: who carries the amount under the service agreement. That is a practice decision, and where the answer is nobody, the invoice is written off rather than left to age. The canonical templates hold a shortfall account for a funder gap and attach a BAS agent note to it rather than settling the choice. A gap on a line the agency did pay is a different case, worked through in the NDIA paid less than I invoiced.

Whether a support is GST free turns on the support and the plan rather than on the rejection, so a corrected row keeps the code the original supply carried. NDIS listed supports sets out the tests, and nothing here decides a treatment for a practice.

A rejection found after the quarter closed

A rejection that surfaces months later is awkward for a reason worth naming. On an accruals basis the invoice was income and carried its GST when it was raised, and the rejection by itself changes neither.

What changes the position is the decision, not the rejection: writing the invoice off, or crediting and re-raising it under a different item code, is the event with a date and a period. Whether an earlier statement needs an adjustment is a question for the practice's BAS agent, and it turns on cash or accruals reporting. Cash versus accrual BAS sets out that difference.

The queue that keeps rejections visible

Because the ledger carries no signal, the only thing between a rejected line and a silently dead claim is a list somebody owns.

Rejections are not exceptional events to be handled when noticed; they are a standing queue that someone owns weekly.4

A queue row worth keeping carries the invoice number, the reason code, the date it was rejected, who owns the next action, the date it went back out, and the outcome. Until the outcome is known the invoice belongs in receivables rather than written off, and sorting aged receivables by funder is what makes the pile visible before year end does.

What Ledger Map does with it

Ledger Map holds one standing map for the practice, approved before anything syncs. When an agency batch lands, it posts one balanced document set for that deposit and leaves one exact match in the bank feed, on the accounts and tax rates the practice's own template carries.

A line that was claimed and not paid gets no posting, which is the correct entry, and it is raised as a named item against its invoice instead of vanishing. That named item is the piece a spreadsheet carries today, and keeping it attached to its invoice is what lets the batch be finalised without the rejection going quiet. How an NDIA batch lands in Xero covers the deposit side, and how it works shows the map itself.

Questions

  • What does it mean when an NDIS claim is rejected?

    It means the claim reached the portal, was assessed, and was not accepted. It is not a transmission failure and not a delay. Nothing is paid for that line, and the reason sits as an error message against the line in the payment request results. A file can upload successfully and still carry rejected lines, so the file status alone tells you nothing about the claims inside it.

  • How do I find out why a payment request was rejected?

    Open the payment request results in the portal and read the message on the rejected line. Each rejected item shows its own error against its own row, and the agency also returns a code with a description. Export or screenshot the results before closing the screen, because that reason is the only record of the rejection that exists anywhere until you write it down.

  • Do I need to credit note the invoice when a line is rejected?

    No. Nothing was paid, so nothing was posted and there is nothing to reverse. The invoice stays open at its original amount while the corrected claim goes back out. A credit note belongs to the other case, where a line was paid and then taken back in a later batch, which is what the canonical templates post against the original invoice line.

  • Why doesn't the corrected line appear in my new bulk upload?

    Because it is still attached to the earlier upload. An item included in a previous bulk upload does not appear in new uploads by itself, so the line has to be deleted from that batch before it becomes available again. Count the corrected lines against your rejection list before sending the new file, and a short count tells you which ones were left behind.

  • How long should I wait before treating a claim as unpaid?

    Under PACE a valid claim is processed within two to three business days of submission, and a complex or non endorsed claim can take up to ten days. Those figures come from secondary guides to the PACE change rather than from a published service standard, so treat them as typical. Waiting past them on a claim with no payment and no rejection is a reason to open the results rather than to wait longer, because a rejected line does not become paid with time and the submission window closes on it.

Read next

Sources

Open questions

  • The agency's own troubleshooting page, which ranks first for this query, returned HTTP 403 to an automated fetch again on 3 Sep 2026. It is listed as unverified and no key fact rests on it.
  • The two readable sources describe the my provider condition differently. The agency's search snippet frames it as claiming against NDIA managed funding, while the PACE guide this page cites frames it as particular support types whichever way the plan is managed. The key fact follows the guide, because that is the wording that could be read in full.
  • The rejection code groups come from a claiming vendor's wiki rather than from the agency, and that page publishes no last updated date. Whether the list is complete and current was not confirmed against an agency source.
  • The portal's error message strings are not reproduced here. Part 2 of the June 2025 provider guide, which carries the warnings and error messages, could not be fetched because ndis.gov.au refuses automated fetches, so reasons are named by column rule and by code group instead.
  • The column rules come from the June 2025 edition of the provider guide, read through an archived capture. Whether a later edition supersedes it was not confirmed.
  • The tax codes the portal accepts are unsettled in the corpus: the June 2025 guide records three, while a current vendor validator page describes two. This page repeats that open question rather than resolving it.
  • Whether a claim time rejection ever appears on a remittance advice, or only in the portal results, is not established by any source in the corpus. The page reads rejections from the results file and says so.
  • Whether a write off or a re-raised invoice following a rejection needs an adjustment to a lodged activity statement is a practice and BAS agent question that turns on cash or accruals reporting. The page states where the decision sits and does not answer it.
  • The payment timing figures in the FAQ rest on a secondary guide to the PACE change, not on a published service standard. The corpus records the same figures on the NDIA funder page with the same caveat.
  1. NDIS rejection codes

    quickclaim. Retrieved 3 Sep 2026.

    secondary

  2. NDIS bulk upload

    splose. Retrieved 3 Sep 2026. Source updated 2 Aug 2026.

    primary

  3. Bulk payment requests, self help guide for providers, myplace provider portal, June 2025 edition

    National Disability Insurance Agency. Retrieved 1 Oct 2025. Source updated June 2025.

    secondary

  4. NDIS provider bookkeeping

    ScaleSuite. Retrieved 3 Sep 2026. Source updated Jul 2026.

    secondary

  5. PACE providers guide, part 2

    Leap in. Retrieved 29 Aug 2026.

    secondary

  6. The canonical configuration templates, allied health by funding source and NDIS provider

    Ledger Map. Retrieved 3 Sep 2026.

    primary

  7. How to troubleshoot claims and payments

    National Disability Insurance Agency. Retrieved 3 Sep 2026.

    unverified

Review

Last reviewed 3 Sep 2026 by Shane

General information for Australian allied health practices, not tax advice. Confirm a treatment with your BAS agent or accountant before you post it.

Guided onboarding

Run one real month before you go live.

Sign up, connect Zanda and Xero, and replay a month you already closed. The map is reviewed with whoever owns the books, and nothing posts until you approve it.

Start your map

Every practice starts from a template. Nothing posts until the map is approved.