Why doesn't the NDIS remittance reference match my invoice number?

Because the agency returns your reference with a system generated tracking identifier appended to it. The invoice number you claimed on is still there, at the front of the string, so the two are not equal but one opens the other. An invoice claimed as INV-29802 comes back as INV-29802 followed by an agency identifier.

Should I split the reference on the last hyphen?

It works until your own invoice numbers contain a hyphen, and then it quietly takes part of the invoice number away with the suffix. Testing whether a known invoice number opens the returned reference holds either way, and where two invoice numbers both open it, the longer one is the match.

The reference field is empty on some rows. What happened?

ClaimReference is optional to the portal, so a bulk payment request that leaves it blank is accepted and assessed on its other fields, and the money can arrive with nothing on the row pointing back at an invoice. Those rows have to be matched on participant and service date for this run, and the fix is in the practice system's claim export before the next upload.

Can I match on the participant number instead?

Only if your invoices carry it. Participant numbers and claim identifiers are not on a Xero invoice by default, so the match screen finds nothing when you search for one. Practices that reconcile this way put the participant number on the invoice first, then search it like any other reference.

Why does my plan manager remittance look different again?

Because it is a different payer. The plan manager claims from the agency and pays you from its own system, and its lines are keyed on its own claim reference, often carrying a prefix rather than a suffix. Each plan manager writes its own format, so the procedure is per plan manager.

Do I have to fix the references to reconcile the deposit?

No. The deposit reconciles against the total at the foot of the remittance, held through the NDIA clearing account, so the bank line closes once the batch is posted. The references decide which invoices the batch closes, which is worth getting right, but it is not what holds up the bank feed.

Problems

NDIS remittance references do not match invoices

Because the NDIA sends your reference back with a system identifier added to the end of it. The invoice number you claimed on is still in there, at the front, so the returned string starts with it rather than equalling it. Match on that prefix. Four other causes produce the same symptom, and each takes a different fix.

Key facts

The field your invoice number leaves in: ClaimReference on the bulk payment request, up to fifty characters of letters, numbers, spaces, forward slash, underscore and hyphen. The portal calls the field optional.¹
The field it comes back in: Your Reference on the payee payment remittance advice, carrying the original invoice number with a system generated tracking suffix after it.³
What the canonical templates record about it: The NDIA deposit rail says the advice is one row per claim line and appends a system suffix to the practice's own invoice reference, which the matcher has to strip.²
Why a prefix test works: The returned reference starts with the number that went out, so the invoice number is a prefix of it rather than equal to it.³
What Xero searches on the match screen: Name or invoice number, and amount, reference or cheque number⁷
What is not on a Xero invoice by default: Participant numbers and claim identifiers, so searching the match screen for either finds nothing until the practice puts them on the invoice itself.⁴
What one practice system writes there: Zanda's bulk upload report puts its own invoice number in Claim Reference, and writes one report row per invoice line item, so several rows can share one reference.⁶
How a plan manager differs: Plan manager lines are keyed on the plan manager's claim reference, often carrying a prefix, which does not tie directly to the invoice number in the ledger.⁵
Where the deposit sits while the rows are worked: Account 102, NDIA clearing, posted at the BAS excluded tax type²

Where the reference on a remittance line comes from

One field carries the invoice number out and one field carries it back. On the bulk payment request the practice uploads, the column is ClaimReference: the provider's own invoice reference, up to fifty characters of letters, numbers, spaces, forward slash, underscore and hyphen. The portal treats it as optional, which matters more than it sounds. On the payee payment remittance advice that comes back, the same value appears in Your Reference.

So a reference that will not match has one of two histories. Either something changed the value between the two files, or the value that went out was not the invoice number in the first place. Working out which one you have takes about a minute, and it decides everything that follows.

includes the Provider's own Invoice reference for the payment. It is the Zanda invoice number.⁶

The suffix the agency adds on the way back

The common case is the first history. The agency puts your original invoice number in Your Reference and appends a system generated tracking identifier after it, so an invoice claimed as INV-29802 returns as INV-29802-zt99134862m5540177. The trailing block belongs to the agency's payment system, and the practice ledger holds no field it could have come from.

That is enough to defeat an exact match on its own. An exact match compares two strings for equality, and these two strings are not equal, so a file of several hundred rows can fail row after row while each one names an invoice you are holding. The reference is not wrong. It is longer.

Match on the prefix, not on the last hyphen

The rule people reach for first is to split the returned reference on its last hyphen and keep what is in front. That works until a practice numbers its invoices with hyphens of its own, or adds a location or practitioner code, at which point the split takes a piece of the invoice number away with the suffix and the row stops matching for a new reason.

Take the invoice numbers you are trying to close, from the debtor ledger rather than from the remittance.
For each remittance row, ask whether the row's reference starts with one of those invoice numbers. The test is the beginning of the string, not the whole of it.
Where exactly one invoice number matches the start, that is the invoice. Where several do, the longest one is the invoice, because a shorter number can be the opening of a longer one.
Where none match the start, stop treating it as a suffix problem. It is one of the four causes below.

The other fields that look like a reference

A remittance line carries several identifiers, and only one of them came from the practice. The rest are the agency's own keys, which is why matching on the wrong one produces a search that returns nothing at all rather than a wrong answer.

Plate 1The identifiers on one remittance line, and which of them came from the practice.

Four causes that are not the suffix

When the prefix test finds nothing, the suffix is not your problem. These four produce the same symptom and take different work, and the first is the one most often missed because the portal accepts the file without complaint.

What you are looking at, what caused it, and where the fix sits¹⁶⁵

What the row shows	What caused it	Where the fix sits
Your Reference is empty	ClaimReference is optional to the portal, so a file that leaves it out is accepted and the claim is assessed on its other fields	The practice system's claim export, before the next upload. Match this run on participant and service date
A reference you do not recognise at all	The practice system wrote its own booking or claim identifier there rather than the invoice number	The export settings. One run has to be matched by hand first
A reference for an invoice number that no longer exists	The invoice was voided and reissued, or renumbered, after the claim went out	The ledger. The old number is the key to the money, so keep it findable on the replacement
A reference with something in front of it, not behind it	The payer is a plan manager rather than the agency, and the line is keyed on the plan manager's own claim reference	A different procedure. Plan manager formats vary by plan manager

Check what your practice software wrote

The practice management system fills ClaimReference, and the two systems that document it fill it differently enough to be worth reading. Zanda's bulk upload report puts the Zanda invoice number in Claim Reference and writes one report row per invoice line item, so a single invoice number can appear on several rows of the file before the agency has touched it.

Open the last file you uploaded rather than the remittance. It is the only place the outbound value is visible.
Read the reference column against the invoice numbers in Xero for the same participants. If they differ there, the agency did not cause this.
Check the length. The field takes fifty characters, so a long composite reference can arrive truncated rather than suffixed.
Check whether the column is populated at all, because a blank one is accepted by the portal and leaves the row with nothing to match on.

Plan manager references are a different shape

A plan managed participant is not an agency claim, so the suffix above is not what you are looking at. The practice invoices the plan manager, the plan manager claims from the agency, and the remittance that comes back is the plan manager's document written in the plan manager's format.

lines are keyed by a claim reference, often with a prefix, that does not tie directly to the invoice number in your Xero ledger⁵

A prefix in front of the number is not the same shape as an identifier behind it, and each plan manager writes its own. How a plan managed deposit lands covers that side, including why every plan manager is its own debtor with its own format.

What Xero can search, and why matching on reference fails

The match screen searches on name or invoice number, and on amount, reference or cheque number. Every one of those is a field the practice controls, and the suffixed string is not in any of them, so the search returns nothing and the row reads as unmatched rather than as different.

Participant numbers and claim identifiers are not on a Xero invoice by default either, which closes the other obvious search. That leaves the invoice number, the amount and the contact as the fields worth searching, and the amount is only unique inside a batch until two participants have the same support on the same day. Find and match on a funder deposit runs that screen properly.

Reconcile the batch, not the row

The reference problem shrinks once the deposit stops depending on it. The canonical templates land an agency batch in account 102, NDIA clearing, at the BAS excluded tax type, because the revenue was recognised when the invoice was raised and the deposit only moves money that was already earned.

With the batch held in one account, the check is the total at the foot of the advice against the credit in the bank feed, and the references only have to identify invoices, not reconcile a bank line. Post a batch deposit for a remittance and reconcile a clearing account are the two procedures that hold it together. If the row count is your problem rather than the reference, a remittance with more lines than invoices takes that one.

What Ledger Map does with a suffixed reference

Ledger Map takes the agency's trailing identifier off the reference before it compares anything, so a row is read against the invoice number the practice sent rather than against the longer string the agency returned. The reference is one signal. The amount claimed and paid, the service date, the support item code and the participant name are scored beside it, so a row that came back with a blank reference still has something to be matched on.

Rows that score too low, and rows where two invoices score the same, are not guessed at. They leave the deposit as a named list with the reason on each one, which is the list a person can act on: a blank reference to fix in the export, a renumbered invoice to point at, a plan manager line that landed in the wrong pile. Ledger Map posts one balanced document set per deposit and leaves one exact match in the bank feed, with the accounts and tax rates taken from the canonical template the practice approved. How Ledger Map works shows the map that decides the rest.

Questions

Why doesn't the NDIS remittance reference match my invoice number?
Because the agency returns your reference with a system generated tracking identifier appended to it. The invoice number you claimed on is still there, at the front of the string, so the two are not equal but one opens the other. An invoice claimed as INV-29802 comes back as INV-29802 followed by an agency identifier.
Should I split the reference on the last hyphen?
It works until your own invoice numbers contain a hyphen, and then it quietly takes part of the invoice number away with the suffix. Testing whether a known invoice number opens the returned reference holds either way, and where two invoice numbers both open it, the longer one is the match.
The reference field is empty on some rows. What happened?
ClaimReference is optional to the portal, so a bulk payment request that leaves it blank is accepted and assessed on its other fields, and the money can arrive with nothing on the row pointing back at an invoice. Those rows have to be matched on participant and service date for this run, and the fix is in the practice system's claim export before the next upload.
Can I match on the participant number instead?
Only if your invoices carry it. Participant numbers and claim identifiers are not on a Xero invoice by default, so the match screen finds nothing when you search for one. Practices that reconcile this way put the participant number on the invoice first, then search it like any other reference.
Why does my plan manager remittance look different again?
Because it is a different payer. The plan manager claims from the agency and pays you from its own system, and its lines are keyed on its own claim reference, often carrying a prefix rather than a suffix. Each plan manager writes its own format, so the procedure is per plan manager.
Do I have to fix the references to reconcile the deposit?
No. The deposit reconciles against the total at the foot of the remittance, held through the NDIA clearing account, so the bank line closes once the batch is posted. The references decide which invoices the batch closes, which is worth getting right, but it is not what holds up the bank feed.

Sources

Open questions

The suffix pattern rests on one vendor's worked example. No agency document read for this page states the append rule or the shape of the identifier, so whether the separator is a hyphen in every case is not settled here.
Whether the June 2025 edition of the portal guide is still current was not confirmed. The agency's site refuses automated fetches, and the copy behind the ClaimReference rule is an archived capture taken 1 Oct 2025.
Xero's match screen search fields come from a republication of Xero help, because central.xero.com returns an empty document to a fetch. Whether the live screen searches any further field was not verified against Xero itself.
The identifiers named on the drawn remittance come from two vendor guides and the research corpus rather than a published agency layout, so the field names, and whether one clearing number covers every line in a deposit, should be checked against a practice's own file.
Plan manager reference formats were not surveyed. One guide describes a prefix rather than a suffix, and each plan manager writes its own document, so this page states the difference in shape and goes no further.
No search results snapshot exists for this page's target query. The answer landscape in the brief is inferred from the captured snapshot for the adjacent row count query and from the vendor pages fetched directly, and should be replaced with a real capture before publication.

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.
primary
The canonical configuration templates, allied health by funding source and NDIS provider
Ledger Map. Retrieved 3 Sep 2026.
primary
NDIS remittance processing in Xero, a guide for providers
Remittance Go. Retrieved 3 Sep 2026. Source updated 2 Jun 2026.
secondary
How to process NDIS remittances in Xero, provider guide
RemitClear. Retrieved 3 Sep 2026. Source updated 15 Apr 2026.
secondary
Reconcile NDIS plan manager remittances in Xero
ToTheCent. Retrieved 3 Sep 2026. Source updated 8 Jul 2026.
secondary
NDIS bulk upload report
Zanda Health. Retrieved 3 Sep 2026.
secondary
Find transactions to match to bank statement lines
No Stress Accounting knowledge base. Retrieved 3 Sep 2026.
secondary

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.