Problems
Plan manager remittance will not match invoices
A plan manager keys its remittance on its own claim reference, not on your invoice number, so the prefix match that works on an agency run finds nothing. Each plan manager writes its own layout, pays on its own terms, and is its own debtor. Find the column that carries your reference, then check that the approved lines less the negatives equal the deposit.
Key facts
- What keys the row
- The plan manager's own claim reference, often carrying a prefix, which does not tie directly to the invoice number in the Xero ledger1
- How the agency rail differs
- On an NDIA remittance the practice's own invoice number sits in the reference field with a system generated tracking suffix appended after it, which is what makes a prefix match work there3
- How many layouts there are
- One per plan manager. Each plan manager has its own remittance format, so a mapping that reads one file cleanly can miss the next one2
- How big a run gets
- A single run can carry 500 or more rows, past the point where matching line by line is reasonable1
- Why the total is a net figure
- Rejected and clawed back claims appear as negative amounts, so the run total is what is left after the negatives rather than the sum of the claims listed1
- Who owes the money
- The plan manager, paying from the participant's funds. The practice submits nothing to the agency itself4
- Written payment terms
- Common terms of 14, 30 or 45 days from invoice date, with some plan managers faster than that and some slower4
- One plan manager's own cycle
- Most payments completed within 3 to 5 days of the invoice reaching NDSP, with the agency taking 2 to 3 days to release the funds first5
- Where the money lands in the ledger
- A plan manager clearing account at BAS Excluded in both canonical templates that model the rail, with short payments held in 605 Funder shortfalls and write-offs8
An agency run and a plan manager run break differently
The reflex is to treat every NDIS deposit as one rail. It is two. On an agency managed claim the practice lodges with the agency and the agency pays it. On a plan managed one the practice invoices a company, and that company checks the budget, claims, waits for the funds, then pays out of the participant's money. The gap between those two sentences is where the matching goes wrong, because four things change at once.
| What you are matching on | Agency payment run | Plan manager payment run |
|---|---|---|
| Who owes the practice the money | The agency, against a claim the practice lodged itself | The plan manager, as its own debtor |
| What keys a row on the remittance | The reference field, carrying the practice's invoice number with a tracking suffix appended | The plan manager's own claim reference, often carrying a prefix |
| Whether the invoice number survives | Yes, as the leading part of the reference | Not reliably, and not in a fixed position |
| Who decides the layout | One agency, one format | Each plan manager, its own format |
| When the money comes | Days from the claim | The plan manager's own cycle, or whatever its terms say |
Read that way, a run that will not match is not a mystery. It is a run whose key the practice has not found yet. Plan managed NDIS payments in Xero covers the money flow behind it.
The reference on the row belongs to the plan manager
This is the whole problem in one line. A plan manager runs its own claims register, and the remittance is a report out of that register rather than a report about the practice's invoices.
Lines are keyed by a claim reference, often with a prefix, that does not tie directly to the invoice number in your Xero ledger.1
Compare that with the agency rail, where the practice's own invoice number is present and a system generated identifier is appended after it. There the fix is a rule: match on the leading part and ignore the tail. Applied to a plan manager run, the same rule finds nothing, because there is no tail to strip and often no invoice number in that field at all. The NDIS remittance reference that does not match your invoice number works the agency rule through.
One layout per plan manager, not one per rail
Each plan manager has its own remittance format.2
The canonical templates say the same thing from the other side: the plan manager rail carries a note that a column mapping per plan manager is expected rather than one fixed parser. So the work that pays off is not a smarter rule. It is a short written mapping per plan manager, kept where the next person can find it.
- Which column carries the plan manager's claim reference, and what its prefix looks like.
- Whether the practice's own invoice number appears anywhere, and under which header.
- How a rejection is shown: a negative row, a status word, or an absent row.
- Where the run total sits, and whether it is stated before or after the negatives.
- Which cycle this plan manager pays on, and what its written terms say.
A dozen plan managers is a dozen debtors
An agency managed practice reconciles one payer. A plan managed practice reconciles as many payers as its participants have chosen, each with its own run, its own layout and its own clock. Each of those runs is smaller than a single agency batch, and they land on different days, so the work arrives as a trickle rather than as one job with an end to it.
That is why the work feels heavier than the dollar value suggests, and why it goes wrong in a particular way. The failure is rarely a hard judgement. It is losing your place in a long list.
We would spend hours a month reconciling remittances, which while not very taxing requires a certain level of attention to not make mistakes.7
It also changes what the debtor ledger has to look like. One contact per plan manager, rather than one contact for the scheme, is what lets aged receivables answer which payer is slow. Aged receivables by funder sets that up.
Prove the run total before you match a single line
Confirm the net deposit: sum the approved lines, subtract the rejected negatives, and check it equals the amount that hit your bank.1
That check takes a minute and saves the afternoon. If the arithmetic does not land, no amount of line matching will fix it, because something outside this run is in the deposit: a negative from an earlier cycle, a second run paid together, or a credit the plan manager applied. Matching first and checking afterwards is how a practice ends up with a batch that is nearly right.
Volume is the other reason to do the check first. ToTheCent puts a single run at 500 or more rows, well past the point where reading down the list is a method. At that size the arithmetic is the only cheap proof available.
Where a plan manager run posts
Both canonical templates that model this rail split it the same way, into money paid, money approved at a lower figure, and lines that were not approved at all. Only the account code for the settlement leg differs between them.
| Template | Component | Where it posts |
|---|---|---|
| allied-health-by-funding-source | Gross paid | 103 Plan manager clearing, at BAS Excluded |
| allied-health-by-funding-source | Short payments | Needs review: Component short_payments needs a fixed account and tax type; original-invoice matching is not supported yet. |
| allied-health-by-funding-source | Rejected lines | Needs review: Component rejected_lines needs a fixed account and tax type; original-invoice matching is not supported yet. |
| ndis-provider-plan-managed | Gross paid | 101 Plan manager clearing, at BAS Excluded |
| ndis-provider-plan-managed | Short payments | Needs review: Component short_payments needs a fixed account and tax type; original-invoice matching is not supported yet. |
| ndis-provider-plan-managed | Rejected lines | Needs review: Component rejected_lines needs a fixed account and tax type; original-invoice matching is not supported yet. |
The settlement leg is BAS excluded because the revenue was recognised when the invoice was raised, and the deposit only moves money that was already earned. The balance in that account is what the plan manager has approved and the bank has not yet delivered, so it returns to nil once the run has been worked. Anything left is a line nobody finished. A clearing account that will not clear sorts the leftovers by cause.
When the deposit and the run are not the same number
Three things break the one run, one deposit assumption, and each takes a different move.
- A negative from an earlier cycle. A claim paid in a previous run and taken back in this one arrives as a negative row netted into this deposit, so the money is short by an amount that has nothing to do with these invoices.
- A run settled across two bank credits. Each credit reconciles on its own, and nothing on the invoice or the batch payment records that the two belong together. A remittance paid in two bank deposits takes that case on.
- A run too large for one batch. Where a run outruns the batch payment cap it has to be posted as more than one batch, and the deposit then faces several batches rather than one. Batch deposit for a remittance runs the mechanics.
There's no field on a Xero invoice or batch payment that says 'this remittance was settled across these two bank lines.'6
The cap itself is worth treating carefully. ToTheCent states 50 invoices per batch and RemitClear states 200, and no Xero page of record was read to settle the difference, so test it in your own Xero before you build a routine on either number.
A matching order that holds up
- Work one plan manager and one run at a time. Two runs on the desk together is how a short pay gets invented.
- Prove the arithmetic: approved lines less negatives against the money that arrived.
- Find the column that carries the practice's own reference. Where there is not one, group by participant and service dates instead.
- Write the mapping down against that plan manager's name, so the next run is a lookup rather than a puzzle.
- Split the exceptions into two piles: lines paid at less than the claim, and lines with no payment at all. They take opposite entries.
- Post the settled lines, then check the settlement account for that run has come back to nil.
A line paid at less than the claim is settled money with a gap behind it, and a line that was not paid is a claim still owed. The NDIA paid less than I invoiced separates those two on the agency rail, and the distinction holds here.
What Ledger Map does with a plan manager run
Ledger Map holds the column mapping per plan manager rather than per scheme, because that is the level the file actually varies at. A run is posted as one balanced document set against the settlement account for that plan manager, so the bank feed is left with one exact match instead of a page of part payments.
Where a line cannot be resolved to an invoice, it becomes a question with the options laid out rather than a posting nobody chose. The accounts and tax rates come from the canonical template the practice starts from, and the practice approves its map before anything syncs. You can see the shape of that in how it works.
Questions
Why does the plan manager's remittance not match my invoice numbers?
Because the run is keyed on the plan manager's own claim reference, often with a prefix, and that reference does not tie directly to the invoice number in Xero. The plan manager is reporting out of its own claims register, not out of your ledger. Find the column that carries your reference, if the layout has one, and write the mapping down against that plan manager's name.
Is a plan manager remittance the same as an NDIA one?
No. On an agency run your invoice number is in the reference field with a tracking suffix appended, so matching on the leading part works. On a plan manager run the key is the plan manager's own reference, the debtor is the plan manager rather than the agency, the layout is that company's own, and the payment cycle is theirs too. A rule that works on one rail can miss on the other.
Why does the run pay less than the invoices it lists?
Usually because rejected or clawed back claims appear as negative amounts, so the total at the foot of the run is what is left after the negatives. Those negatives can relate to claims paid in an earlier cycle. Check the approved lines less the negatives against the money that arrived before you decide any line in front of you was short paid.
How long should a plan manager take to pay?
It varies by payer, which is the point. One large plan manager describes most payments as completed within 3 to 5 days of receiving the invoice, with the agency taking 2 to 3 days to release funds first. Written commercial terms of 14, 30 or 45 days from invoice date also exist. Track your own by plan manager rather than treating the scheme as one payer.
Do I need a different matching rule for every plan manager?
In practice yes, and it is a short one. Each plan manager has its own remittance format, so what changes is which column carries the reference, how a rejection is shown, and where the total sits. The canonical templates carry the same note on the rail: a column mapping per plan manager rather than one fixed parser.
Where does the deposit post while the lines are being worked?
Both canonical templates that model this rail send the gross payment to a plan manager clearing account at BAS Excluded. Their shortfall and rejected-line rows retain original-invoice tax intent, but that inheritance is not supported for posting yet. Review those rows and choose fixed Xero destinations before approving the mapping; the template intent is not a completed posting rule.
Read next
- FundersPlan-managed NDIS payments in Xero
- ProblemsNDIS remittance references do not match invoices
- ProblemsThe NDIA paid less than I invoiced
- ProblemsOne remittance paid across two bank deposits
- Xero how toRecord a batch deposit from a remittance
- Practice systemsZanda Xero integration: what the batch export carries
- HubProblems
Sources
Open questions
- Xero's batch payment cap is not settled here. ToTheCent states 50 invoices per batch and RemitClear states 200, and no Xero page was read first hand on 3 Sep 2026, so the page states the disagreement rather than a number.
- No named plan manager's own remittance documentation was obtained. Plan Partners and MyIntegra both returned a not found response to an automated fetch on 3 Sep 2026, so the claim that layouts differ rests on two vendor guides and the canonical templates rather than on two real files placed side by side.
- Whether any plan manager writes the practice's invoice number into a dedicated column, rather than only into its own claim reference, is not settled by any source read. The page says to look for that column rather than asserting it is there.
- No SERP snapshot was captured for this query, so the top results, the People also ask questions and whether an answer engine shows an overview are unknown. The FAQ is written from the sources rather than from captured questions.
- Bank narration on a plan manager deposit is recorded as unverified in the research corpus beyond carrying the plan manager's business name, so no descriptor string appears on this page.
- Reconcile NDIS plan manager remittances in Xero
ToTheCent. Retrieved 4 Sep 2026. Source updated 8 Jul 2026.
secondary
- NDIS remittance processing in Xero, a guide
RemitClear. Retrieved 3 Sep 2026. Source updated 15 Apr 2026.
secondary
- NDIS remittance processing in Xero
RemittanceGo. Retrieved 3 Sep 2026. Source updated 2 Jun 2026.
secondary
- How we pay your providers
NDSP Plan Managers. Retrieved 3 Sep 2026. Source updated 27 May 2024.
secondary
- Reconciling a remittance split across two bank deposits in Xero
RemitClear. Retrieved 3 Sep 2026. Source updated 25 May 2026.
secondary
- The canonical configuration templates, allied health by funding source and NDIS provider plan managed
Ledger Map. Retrieved 3 Sep 2026.
primary
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.
Every practice starts from a template. Nothing posts until the map is approved.