Problems
Invoice not of valid status for modification
Xero refused the write because the invoice it was asked to change is not in a status that accepts the change. Two vendors document two different causes under the same sentence: a number already held by another invoice, which can be a voided one, and an invoice exported as Draft when the copy in Xero is at another status. Check which system reported it, then search on the number.
Key facts
- The message
- Invoice not of valid status for modification.4
- What Cliniko says causes it
- A duplicate invoice number already in Xero, put there either by the integration or by someone typing an invoice in by hand4
- Where the number hides
- Cliniko tells you to check voided invoices as well, because the invoice holding the number may have been voided and so is missing from the list you searched4
- What Zanda says causes it
- An invoice exported in Draft status when it is already in Xero at another status2
- The second Zanda case
- A payments batch aimed at an invoice that is still Draft in Xero. Zanda states the invoice has to be set to approved first2
- Once a payment is on it
- Zanda states that once payment is applied, no further changes to that invoice are permitted, so an edit made in the practice system afterwards has nowhere to land3
- Which numbers come back
- The number on a draft or an awaiting approval invoice is free to use again once that invoice is deleted. To reuse the number on an approved invoice, change the number before voiding it5
- What a paid invoice still accepts
- To, Due date, Invoice number, Reference, Branding theme, Description, Account, Tracking and Project can be changed without the payment coming off. The rest need the payment removed first6
- Who numbers the invoice
- The Accounting API schema calls InvoiceNumber a unique code identifying the invoice, and generates one from the organisation's settings only when the field arrives empty. A practice system that sends its own number sets the one Xero then holds7
- The statuses an invoice can hold
- The same schema gives a Xero invoice one of six status values: DRAFT, SUBMITTED, AUTHORISED, PAID, VOIDED or DELETED. The message names none of them, which is why the diagnosis is to open the Xero copy and read the status off it7
- Which write goes first
- Cliniko pushes an invoice to Xero as soon as it is created and pushes a payment only once that payment is allocated to an invoice, so a refused invoice leaves its payment with nothing to attach to1
- The longer form of the same message
- Zanda documents a second version of the sentence, ending in this document cannot be edited as it has a payment or credit note allocated to it, and gives its cause as an invoice already in Xero with payments recorded against it2
What the message is telling you
Nothing is wrong with the invoice you are looking at. The message is about a write that Xero refused, and the reason it gives is a status: the document the practice system asked Xero to change is not in a state where that change is allowed. One invoice is refused and the others in the run still go across, so this reads as a single missing client rather than as a sync that stopped. In Cliniko it sits in the list of synchronised invoices as one line marked Failed with the message beside it.
The sentence withholds the two things you need. It does not say which invoice in Xero it means, and it does not say which status that invoice is in. Both vendors that raise it fill in a different half of the gap, so the first move is to notice which system reported it.
Two vendors, two causes, one sentence
Cliniko and Zanda both document this message in their troubleshooting articles, and they give different causes. Neither is wrong. They describe two ways a write can arrive at an invoice Xero will not modify, and the fix for one does nothing for the other.
| Where you saw it | What the vendor says caused it | Where to look first |
|---|---|---|
| Cliniko, on an invoice sync | An invoice with that number is already in Xero, whether the integration put it there or someone typed it in | Search Xero on the invoice number, with voided invoices included |
| Zanda, on an invoice export | The invoice went across as Draft while the copy in Xero is already at another status | Open the Xero copy and read its status before re-exporting anything |
| Zanda, on a payments export | The payment is aimed at an invoice that is still Draft in Xero, which has to be approved before a payment can go on it | Approve the invoice in Xero, or re-export it as approved, then run the payments batch again |
You have tried to export the invoice in Draft status when it's already in Xero with another Status. Alternatively, this may mean that you're trying to export payments onto an invoice in Draft status (it needs to be set to approved first).2
Status decides which writes Xero accepts
Underneath both causes is one rule. A Xero sales invoice carries a status, and the status decides what can still be done to the document. A draft is soft and can be changed freely. An approved invoice has posted to the ledger and only some of its fields stay open. A paid or voided invoice is closed to almost everything. A practice system export is held to the same rule as a person typing into the file.
The number a voided invoice keeps
This is where the search usually stalls. The message says a document is in the wrong state, you search Xero for the invoice number, nothing comes back, and the message looks wrong. Cliniko's own article heads that off: if the invoice is not in your list of invoices, it might be voided, so check for voided invoices as well.
Voiding reverses the accounting and keeps the record. The number is part of the record, so it stays taken. A practice that voids a mistake in Xero and then reissues the same appointment in the practice system hands Xero a number it is already holding, and the second write is refused. The invoice you are looking for is sitting in the voided list with the number you searched for on it. Xero states the way out on the same page: to reuse the number on an approved invoice, change the number first and then void it. A draft or an awaiting approval invoice needs none of that, because deleting one puts its number back in use.
The draft copy and the payment behind it
Zanda's cause is a different shape. Its export runs in two batches, invoices first and payments second, and an invoice can go across as a draft or as approved. That choice decides what the second batch can do.
- An invoice exported as a draft can still be edited and deleted in Xero, and it cannot take a payment. The payments batch that follows it stops on it.
- An invoice exported as approved is posted and can take a payment. Zanda's own rule for this status is that an approved invoice in Xero cannot be changed.
- An invoice exported again as a draft, when Xero already holds it at another status, is asking the approved copy to become a draft, and that is the write Xero refuses.
So a practice that exports drafts on purpose, to have someone check them in Xero before approving, meets this message on the payments batch rather than on the invoices. The order matters: approve first, then export the payments.
The edit that arrives after the payment
The third case has a message of its own. An invoice syncs, a payment goes onto it, and then something changes in the practice system: a fee corrected, an item swapped, a session moved to another practitioner. The next export carries that change to a document Xero has already closed. Zanda states the rule plainly, that once payment is applied no further changes to that invoice are permitted, and documents a longer version of the same sentence for it, ending in this document cannot be edited as it has a payment or credit note allocated to it.
Neither vendor documents a setting that lifts this. The order that works is to take the payment off the Xero invoice, apply the change, then put the payment back on the same date and reference. Where the invoice sits in a closed month, the payment cannot go back on until the lock moves, which is the case document date cannot be before the lock date covers.
The money is the part the vendor articles leave out. If the Xero copy was already paid, the payment stays on it at the value it carried when it was raised, so the funder clearing account holds the old figure while the funder settled the new one. Correcting the invoice and leaving the payment where it is keeps the two apart, and the gap shows up later as a clearing balance that will not go to zero. That is why the order matters rather than the fix itself.
What it leaves in the ledger while it sits
A refused write is quieter than a failed sync, and it costs more than one invoice. The invoice never landed, so that client's revenue is missing from the period. The payments batch runs after the invoices, so the payment has nothing to attach to and is refused in its turn.
That leaves the funder clearing account short by the amount nobody exported, while the deposit covering it arrives in the bank feed at full value. The bookkeeper matching that deposit finds the clearing entries do not add up to it, and the difference is a session that was billed and treated and never made it across.
Aged receivables carry the same gap from the other side. The practice system shows the invoice raised and paid, Xero shows neither, and the two debtor ledgers disagree by exactly the invoices that were refused.
Clearing it, in order
- Note which system reported it and which batch it was in, invoices or payments. That picks the cause before you open anything.
- Search Xero on the invoice number, with voided and deleted invoices in the search, rather than on the client name.
- Read the status of whatever comes back. Draft, approved, paid and voided each lead somewhere different.
- Decide which copy survives. The Xero copy is the one the ledger has already reported on, so it usually wins unless it was voided.
- Amend the surviving invoice in Xero, or renumber the copy in the practice system, so the two no longer contend for one number.
- Re-export the invoice on its own and confirm it landed in Xero before you run the payments batch again, since the payment cannot go on until the invoice is there and approved.
Where the copy in Xero is a leftover from an invoice deleted in the practice system, the choice is a different one, and a deleted Zanda invoice still in Xero works through it.
Numbering that stops it coming back
Clearing one collision does not stop the next one, because the cause is that the practice system owns the numbering and Xero holds that number as the unique one. Giving each source its own prefix keeps the sequences apart: one prefix for the system in use, another for the one being migrated off, another again for anything raised by hand in Xero.
That single habit answers the migration case, the two systems into one organisation case, and the invoice someone raises directly in Xero for a client the practice system also bills. It is set up once, and it is worth doing before the first export, because renumbering after the fact means touching invoices that are already reported.
What Ledger Map does with it
Ledger Map holds one standing map for the practice, approved before anything syncs, and checks a write against the state of the Xero document before sending it. A write it cannot place becomes a question naming the invoice, its status and the number that is contended, rather than a line in an error log that stops a batch.
On the money side the rule is the same: one balanced document set per deposit, posted to the accounts the map names, leaving one exact match in the bank feed for the bookkeeper to click. You can see how the map is approved on how it works, or read the rest of the sync failures on the learn hub.
Questions
What does invoice not of valid status for modification mean in Xero?
It means Xero was asked to change an invoice that is not in a state where that change is allowed. The write was refused, not the invoice. The two documented causes are a number already held by another invoice in that Xero organisation, and an invoice sent across as a draft when the Xero copy is at another status.
Why does Cliniko show this error when the invoice looks fine?
Because the clash is on the number rather than on the content. Cliniko documents the cause as an invoice with that number already in Xero, put there by the integration or entered by hand. Its article adds that the invoice holding the number may have been voided, so it does not appear in the list you searched.
Does a voided invoice in Xero release its invoice number?
No. The voided document stays in Xero as a record and keeps its number, which is why the number can look free in the invoice list and still be refused. Xero's own instruction is to change the number before voiding where you want it back. A deleted draft or awaiting approval invoice is the opposite case: its number is free to use again.
Why did my Zanda payments batch fail with this message?
Zanda documents this as a payment aimed at an invoice that is still in draft status in Xero, and states the invoice has to be set to approved first. Its export runs invoices before payments, so an invoice that went across as a draft leaves the payment behind it with nothing it can attach to.
Why do help articles give different causes for this error?
Because the message is a generic Xero response and each integration meets it from a different direction. Most of the pages ranking for the string are help articles from software written for other trades: one names a duplicate number, another an invoice already paid, another one that was voided, another a broken link between the two systems. Note which system reported the write and which batch it was in before following any of them.
Can a paid invoice be edited in Xero?
In part, and the part is wider than the practice system allows. Xero lists To, Due date, Invoice number, Reference, Branding theme, Description, Account, Tracking and Project as editable with the payment left on. Anything outside that list needs the payment removed, the change applied, then the payment re-entered on the same date and reference. Zanda's own rule is that once payment is applied it sends no further changes, which is a limit on the export rather than on Xero.
Read next
- ProblemsAn invoice failed to sync with Xero
- ProblemsDocument date cannot be before the lock date
- ProblemsDeleted Zanda invoice is still in Xero
- ProblemsArchived Cliniko invoice is still open in Xero
- ProblemsPayment amount exceeds the amount outstanding
- Practice systemsCliniko Xero integration: what syncs, what does not
- HubProblems
Sources
Open questions
- Whether Xero returns the same short wording for a create carrying a duplicate number and for an export aimed at a draft, or whether Cliniko and Zanda are reporting two different Xero responses under one heading. Neither vendor prints the response code, and no readable Xero source settles it.
- The six status values on this page come from the published Accounting API schema, which names them and stops there. What each status still accepts is drawn from the two vendor articles and from the product's own research, not from Xero. The developer.xero.com pages that would settle it return a page title and no body from here.
- Whether a create that carries a duplicate invoice number updates the existing invoice rather than being refused. The corpus records that distinction from community sources and marks it unverified, so nothing here depends on it.
- Cliniko's article says only that it was updated over three weeks ago and Zanda's shows no date at all, so the date each was read is the only firm date on them.
- The other vendors that document this message were read off the search results page rather than fetched, so they are described here and none is cited. Only the two health software articles behind this page were opened and read.
- Xero Accounting API OpenAPI specification, version 18.0.0, Invoice schema
Xero, XeroAPI on GitHub. Retrieved 3 Sep 2026. Source updated 30 Aug 2026.
primary
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.