Skip to main content

Problems

NDIS payments recorded as invoices with items

An item on a Xero invoice supplies a default. The line copies the item's account and tax rate once, at the moment it is created, so editing the item now leaves every posted line exactly where it is. Change the mapping from a date forward, send each NDIS payment to the funder's clearing account rather than straight to the bank, and treat the history as its own decision.

Key facts

What an item hands to a line
A default account code and tax rate. The Xero API describes an item's sales account as the default account code to be used for a purchase or a sale, and the invoice line carries its own account code and tax type beside the item code.1
When a mapping change takes effect
From the change onward. Cliniko states that all new invoices and invoices not yet synced to Xero will send those billable items to their set account, which leaves everything already synced where it is.2
What a sync gets back on a paid invoice
This document cannot be edited as it has a payment or credit note allocated to it, which is the refusal the integration receives when it tries to change a settled document.3
What Xero still accepts on a paid invoice
To, Due date, Invoice number, Reference, Branding theme, Description, Account, Tracking and Project can be changed without removing the payment, and other fields need the payment removed first.4
What a renamed item code causes
A sync failure reading Item Code is not valid, raised when the item code in the practice system no longer matches the one saved in Xero.3
Where a payment lands instead
A setting rather than a rewrite. Each payment type points at its own account, and that specific setting overrides the default payment account.5
The account the NDIA rail settles through
Account 102, NDIA clearing, at the BAS excluded tax type, with revenue sitting on its own account for the funding source that paid.7
The field the remittance comes back on
ClaimReference, the provider's own invoice reference. The portal treats it as optional, so a claim sent without one leaves the paid line with nothing to match against.8
What the ATO asks of a mixed set of supplies
If you make a mix of taxable and GST-free supplies, you may need to review your accounting systems to ensure the correct GST treatment of your supplies.6

What an item on a Xero invoice actually supplies

An item in Xero is a saved set of defaults: a code, a description, a unit price, a sales account and a tax rate. The API calls the item's sales account the default account code to be used for a purchase or a sale, and default is the word doing the work. A line created from an item takes a copy of those values and then owns them, carrying its own account code and tax type beside the item code.

That one fact explains the confusion behind this question. A practice that points the item at a different account sees nothing move, so it feels as though the change did not save. It saved. It applies to lines not yet written, and every posted line still holds the copy it took the day it was raised.

An invoice with item lines is not a receive money with item lines

Be precise about which document exists, because two things get described the same way. A sales invoice carries line items. So does a bank transaction of the receive money kind, which holds the same line array and can carry item codes too. Practices arrive at both.

  • Invoices with item lines. Revenue was recognised when the claim was raised, receivables are real, and the question is which account and which payer each line landed on.
  • A receive money with item lines. No receivable was created, money and revenue were recorded in one stroke, and there is nothing for a remittance to match against.
  • Both against the same money, which counts the revenue twice and leaves the invoice open. Rule this one out first, by looking in the revenue account for a deposit sized entry beside a run of claim sized ones.

Whether the item lines are the problem at all

Items are not the villain. An item that belongs to one payer at one tax rate maps cleanly, and the per support breakdown is useful when a claim comes back short. What an item cannot express is who paid. The same consult is billed to a plan manager, to the agency, to a self managed participant and to a private patient, and those resolve to different accounts.

So the question is not whether to use items. It is whether the split that matters is carried by something that can express it. Why all revenue lands in one sales account works that through. Here the answer is assumed: for NDIS work the split that matters is by payer, and it belongs in the account code.

The shape the entries move to

The canonical template holds the destination. NDIS revenue sits on its own account for the funding source that paid, agency managed work on account 404 and plan managed work on account 405. Settlement runs through that payer's own clearing account, 102 NDIA clearing for an agency batch and 103 plan manager clearing for a plan manager, both at the BAS excluded tax type. A gap between what was claimed and what was approved has account 605 waiting for it.

Item coded invoices paid straight into the bank account beside Revenue by payer, settled through the NDIA clearing accountA ledger comparison in two columns. On the left, NDIS work recorded as item coded invoices paid straight into the bank account: revenue split by item, no clearing account in use, one payment in the bank for every invoice, nowhere for a short payment to sit, and receivables closed on the day somebody keyed the payment. On the right, the same practice with revenue split by who is paying, an NDIA clearing account holding each approved claim until the batch lands, one bank line per deposit, a named account for a written off gap, and receivables closed on the funder's paid date.Item codedinvoices paidstraight intothe bankaccountRevenue bypayer,settledthrough theNDIA clearingaccountRevenueOne line peritem, eachcarryingwhateverdefault thatitem heldOne accountper fundingsource,chosen bywho ispaying102 NDIAclearingNot in use, soan approvedclaim hasnowhere towaitHolds eachapprovedclaim fromthe funder'spaid dateuntil thebatch landsBank accountA payment forevery invoice,none of whichis a realstatement lineOne line perdeposit,matched tothe batchthat paid it605 FundershortfallsA short paidlinedisappearsinto thedifferenceThe gap hasa home, andwriting itoff becomesa decisionAgedreceivablesClosed on theday somebodykeyed thepaymentClosed onthe funder'spaid date,as theremittancestates it
Plate 1The same NDIS work in both shapes, account by account: what item coded invoices paid to the bank leave behind, and what the settlement account shape leaves instead.

The right hand column is not more work per claim. It is the same entries pointed somewhere useful: the invoice closes when the funder approved it, the bank carries one line per deposit, and the settlement balance is a list of claims approved but not yet banked. Set up a clearing account covers the accounts, and how an NDIA batch lands in Xero the batch it reconciles against.

Changing the mapping changes what comes next

The practice system side is small and worth doing first, because it stops the pile growing while the history is sorted out. Point each billable item at the account it belongs on, and point the NDIS payment type at the clearing account rather than the bank. Cliniko is explicit about the reach of the first change.

From now on, all new invoices and invoices not yet synced to Xero will send those billable items to their set account.2

Anything sitting in a failed sync queue picks up the new mapping when it is retried. Everything that already crossed is untouched. The payment side behaves the same way: the destination is a setting on the payment type, and that specific setting overrides the default payment account, so the next payment lands in the clearing account with no existing entry rewritten.

What a payment closes off, and what it does not

This is the wall most practices hit first, and it is lower than it looks. Once a payment is allocated the practice system stops pushing changes into the document. Xero itself still accepts some of them.

What a sync is refused once a payment is allocated, and what has to happen first31
What is attemptedWhat comes backWhat has to happen first
Syncing a change into a paid invoiceThis document cannot be edited as it has a payment or credit note allocated to it.Make the change in Xero, where Account and Tracking stay open
Resyncing a paid invoicePayments can only be made against Authorised documents.Make the change in Xero, because the sync is locked out
Re-raising a used invoice numberInvoice not of valid status for modification.Find the document that already uses that number in Xero
Syncing a renamed item codeItem Code is not valid.Match the item code in Xero to the one now sent
Allocating more than is owedThe API rule: the payment must be less than or equal to the outstanding amount owing on the invoiceSplit the receipt, or hold the excess separately

The pattern in the first four is the same: the sync will not carry a change into a settled document, so the correction is made in Xero. Account and Tracking are on the list Xero accepts with the payment still on, which is what a recode needs. Amounts, quantities and the tax rate need the payment off first, and that is the expensive path.

History, lock dates and a lodged activity statement

There are three honest answers to what happens to the entries already posted, and the right one depends on how far back the shape goes and whether those periods were reported.

  1. Change from a date forward and leave the history. The cleanest choice when the periods behind you are lodged and the totals were right even though the split was not.
  2. Restate from the start of the current period. Suitable when the shape started recently and nothing has been lodged. Each line is recoded with the payment left in place, and only a line whose tax rate moves needs the payment off first.
  3. Reclassify with a journal. It moves totals between accounts without reopening an invoice, and leaves the invoice level detail on the old accounts, so the reports agree and the drill down does not.

Two constraints narrow the choice. A lock date blocks a document dated before it, which puts restatement out of reach for a closed year. And where a period sits inside a lodged activity statement, whether to restate it is a question for the practice's BAS agent, because a recode that moves amounts between tax rates changes what was reported.

Where the claim reference has to end up

One detail is worth fixing while the mapping changes, because it decides whether the next remittance can be worked at all. A bulk payment request carries ClaimReference, the provider's own invoice reference. The portal treats it as optional, and it is the reference the paid line comes back on, so a file sent without it produces a remittance whose rows cannot find the documents they paid.

  • Put the Xero invoice number in ClaimReference when the claim is built, not a booking id or a participant name.
  • Keep one claim line per invoice line where you can, so a partly approved claim maps to a part payment.
  • Expect the reference back with a suffix on it, and strip the suffix when matching rather than editing the invoice number to match.

The GST question sitting under the item

An item also carries a tax rate, so a remapping quietly touches the activity statement. The treatment follows the supply rather than the item name: the ATO's test for an NDIS supply is a plan in effect, reasonable and necessary supports specified in the statement of supports, a written agreement with the participant or another person, and a supply covered by one of the tables in the NDIS Determination.

The ATO also asks a practice making a mix of taxable and GST-free supplies to review its accounting systems, which is what this migration is. NDIS listed supports sets out the tests. Two cautions. The settlement leg is a separate question from the revenue leg, because settlement postings sit outside the activity statement in every canonical template. Several NDIS adjacent supplies are also unsettled in this corpus, and they are listed as open questions below.

An order that works

  1. Confirm which document you have: invoices with item lines, a receive money with item lines, or both against the same money.
  2. Create the accounts you are moving to: revenue by funding source, and one clearing account for the funder.
  3. Point the billable items at those revenue accounts and the NDIS payment type at the clearing account.
  4. Put the invoice number into ClaimReference on the next claim file.
  5. Decide the history question with the practice's BAS agent, and write the decision down with the date it applies from.
  6. Reconcile the next deposit through the clearing account and check the balance returns to nil once every remittance line is allocated.

The last step tells you the change took. A settlement account that will not return to nil is the standing report on this shape, and a clearing account that will not clear sorts the leftovers by cause.

What Ledger Map does with an NDIS claim

Ledger Map keeps the decision in one place instead of on each item. A standing map says which account and tax rate a line takes, resolved from the funding source and the service category rather than from the item somebody picked, and the practice approves that map before an invoice syncs. The item can stay as it is, because it no longer carries the answer.

On the money side it posts one balanced document set per deposit and leaves one exact match in the bank feed, with the payment dated on the funder's paid date and the claim reference written where the next batch can find it. A line paid short leaves the deposit as a named item rather than as a difference.

Questions

  • Can I change the item in Xero and fix the invoices already posted?

    No. An item supplies a default that the line copies when it is created, and the line then carries its own account code and tax type. Editing the item applies to lines not yet written. Cliniko puts the same rule on its side: from the change onward, new invoices and invoices not yet synced go to the set account, and everything already synced stays where it is.

  • How should NDIS work be invoiced in Xero?

    One invoice per claim, coded to the revenue account for the funding source that is paying, with the invoice number written into ClaimReference on the payment request. The payment then posts to the funder's clearing account on the date the funder paid, and the bank deposit reconciles against that batch as a single line.

  • Do I have to restate invoices that sit in a lodged activity statement?

    That is a question for the practice's BAS agent, because a recode that moves amounts between tax rates changes what was reported. Many practices change the mapping from a date forward and leave lodged periods alone with a note on the account. A lock date will also block a document dated before it, which rules restatement out for a closed year.

  • Can I change where the payment lands without touching the invoice?

    Yes, and it is the cheapest half of the job. The destination of a synced payment is a setting on the payment type rather than a property of the invoice, and the specific setting overrides the default payment account. New payments land in the clearing account from that point, with no existing document reopened.

  • Should the Xero contact be the participant or the plan manager?

    Practices do both and this page does not settle it. The ATO's written agreement test allows the agreement to be with the participant or with another person, so the choice is about who the debt sits against and how the remittance is worked rather than about the tax treatment. Whichever is chosen, keeping it consistent is what makes the receivables report readable.

Sources

Open questions

  • Xero's Edit an invoice article was read on 4 Sep 2026 and gives the fields a paid invoice still accepts. The second Xero Central article ranking for this query is about payment services rather than about recording an NDIS payment, so nothing on this page rests on it.
  • The Xero Central thread that carries this question in the asker's own words now redirects to the ideas board, so only the question title is citable and the accepted answer, if there was one, cannot be read.
  • Whether a period already inside a lodged activity statement is restated or left alone with a note is a decision for the practice's BAS agent. This page sets out what each choice costs and settles neither.
  • The ClaimReference behaviour is cited through the product's own column module, because ndis.gov.au refuses automated fetches and the June 2025 guide could not be read directly in this session.
  • Whether the Xero contact on an NDIS invoice is the participant or the plan manager is a practice decision. The written agreement test allows either, so the page states both.
  • Whether NDIS report writing, supervision and therapy assistant time are GST free is unsettled in the research corpus, so no treatment for those is stated here.
  1. An invoice failed to sync with Xero

    Cliniko. Retrieved 3 Sep 2026.

    primary

  2. Edit an invoice

    Xero Central. Retrieved 4 Sep 2026.

    primary

  3. Sync payment types in Cliniko to specific clearing accounts in Xero

    Cliniko. Retrieved 3 Sep 2026. Source updated 18 May 2026.

    primary

  4. GST and health, National Disability Insurance Scheme

    Australian Taxation Office. Retrieved 3 Sep 2026. Source updated 13 Jun 2024.

    primary

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

    National Disability Insurance Agency. Retrieved 3 Sep 2026. Source updated June 2025.

    secondary

  6. Customer pain point evidence, entry P2

    Ledger Map. Retrieved 3 Sep 2026. Source updated 29 Aug 2026.

    secondary

  7. Processing NDIS remittances in Xero, a guide for Australian providers

    RemitClear. Retrieved 3 Sep 2026. Source updated 15 Apr 2026.

    secondary

Review

Last reviewed 4 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.