What does it mean when an invoice fails to sync with Xero?

It usually means the write reached Xero and Xero refused it. The connection is working. The invoice on the Xero side is in a state that will not take the change, most often because a payment is already allocated to it or its date sits inside a locked period. The error string names which constraint applied.

Is there currently a problem with Xero, or is it my invoice?

Tell the two apart by scope. Where every write fails at once, the connection or Xero itself is the suspect, and Zanda's list names that case as an unexpected response received from Xero. Where one invoice fails and the rest land, the fault is that document, and the error string says which constraint Xero applied.

What is the limit of invoices you can approve in Xero?

It is a ceiling on the Xero subscription rather than anything in the practice system. Xero's Australian pricing page says invoice limits for the Ignite plan apply to both approving and sending invoices, and that transactions initiated by app partners may count towards the limit. Zanda states a Xero trial allows ten invoices of each kind to be approved. The figure for the paid entry level plan is not stated on either page, so it sits in this page's open questions.

Can a Xero Cashbook or Ledger organisation receive invoices from a sync?

No. Cliniko states that Xero no longer supports invoicing integrations with Xero Cashbook and Ledger organisations, and Zanda reports the same refusal as an export that cannot send invoices as approved or send payments. A standard Xero organisation is what the sync needs to write into.

Do invoices catch up on their own after the integration reconnects?

Not on their own. Reconnecting restores the link, and a separate catch up resends everything from a date you pick. Payments move at one per minute through the Xero API, so a gap of a few weeks in a busy practice takes hours to close.

Why did the payment fail when only the invoice was refused?

Because the payment depends on the invoice. Zanda exports invoices and payments as two batches, and Cliniko sends an allocated payment only once its invoice is in Xero. One refused invoice therefore leaves two gaps: missing revenue, and a settlement with nothing to attach to.

Problems

An invoice failed to sync with Xero

It usually means the write reached Xero and Xero refused it. The connection is working. The document on the Xero side is in a state that will not take the change: already paid, inside a locked period, past a plan limit, or holding a name that is taken. Read the error string, clear that constraint in Xero, then run the catch up.

Key facts

What the phrase covers: Cliniko indexes ten different Xero error messages under the one heading, so a failed sync is a category rather than a single fault³
The other vendor's list: Zanda's troubleshooting page carries twenty entries for the same export, sixteen of them Xero error strings, and most name the same constraints under different wording⁴
The paid then edited case: A paid invoice edited in the practice system after it synced. Xero answers with Payments can only be made against Authorised documents, and Cliniko says to leave it where the two systems still balance³
The plan limit: You have reached the limit of invoices you can approve is a Xero subscription ceiling, and both vendors list it. Xero's Australian pricing page says invoice limits for the Ignite plan apply to both approving and sending invoices⁷
The sync spends the limit: The same footnote says transactions initiated by app partners may automatically contribute to your invoice limit, and a practice management sync is an app partner⁷
The one published number: Zanda states a Xero trial allows ten accounts receivable and ten accounts payable invoices to be set to Approved, and points at Xero's pricing for the paid plans⁴
Cashbook and Ledger: Cliniko states that Xero no longer supports invoicing integrations with Xero Cashbook and Ledger organisations, and Zanda reports the same refusal from its side⁶
Why it disconnects: Cliniko drops the connection when it speaks to Xero and Xero cannot answer, so the disconnection is a safety stop rather than an expired login⁵
The catch up throttle: A backfill sends payments at one per minute through the Xero API, so a large gap takes hours to close⁵
Order matters: Zanda exports invoices in one batch and payments in a second, so an invoice that never landed leaves its payment with nothing to attach to²
How a practice describes it: A practice running this daily put it plainly: once an invoice is paid or a financial period is closed in Xero, the record effectively locks to ensure accounting integrity⁸

What a failed sync actually is

The wording sends most people the wrong way. Failed to sync reads like a transport problem, so the first move is usually to reconnect and try again. That clears the few entries about the connection itself, and leaves every other one exactly where it was.

In most of the published cases the connection was fine. The practice system built the invoice, sent it, and Xero refused to write it. Xero hands back a sentence saying why, and the practice system shows you that sentence more or less verbatim. The error string is not noise around the failure. It is the diagnosis.

Why the refusal comes from Xero

Xero protects documents that have already been acted on. Once a payment is allocated to an invoice, or its period has been locked, the invoice stops accepting edits. That is deliberate, and it is why a correction made in the practice system a week later has nowhere to land.

Once an invoice is paid or a financial period is closed in Xero, the record effectively locks to ensure accounting integrity⁸

That single line explains most of both vendors' troubleshooting lists. The practice system is a live record that people keep tidying. Xero is an accounting ledger that hardens behind you. The sync sits between the two, and it fails at the moment the two disagree about whether a document is still editable.

Every error string the two integrations publish

Cliniko and Zanda each keep a public list, neither mentions the other, and the same constraint appears on both under different wording. Here they are together, with the constraint each one names.

Plate 1The published error strings from both native integrations, with what Xero is refusing in each case.

Which of the five constraints you hit

Group the string first, then act. The five groups have different fixes, and three of them have a page of their own here because the fix is long enough to need one.

The five constraints, and where each one is answered in full³⁴

The constraint	The strings that name it	Where the fix lives
The document has already been acted on	Payments can only be made against Authorised documents; this document cannot be edited as it has a payment or credit note allocated	Fix it in Xero, not in the practice system
The period is locked	The document date cannot be before the period lock date; the end of year version; Invoice or Payment is in Xero Locked Period	The lock date page
The organisation will not take the write	You have reached the limit of invoices you can approve; unable to export invoices as Approved or export payments	Answered on this page, below
An identity value is already taken	The Contact Name already exists, the account number and archived contact errors beside it, and Invoice not of valid status for modification	The contact name and invoice status pages
The connection is pointed wrong or gone	Export failed, an unexpected response was received from Xero; you have connected to a different Xero organisation	Answered on this page, below

For the two groups this page does not own, go straight to the lock date page, the contact name page, the invoice status page or the overpayment page. The rest of this page covers the three nobody else does.

You have reached the limit of invoices you can approve

This one has nothing to do with the invoice. The Xero subscription has a ceiling on how many invoices can be approved, and a practice syncing every appointment reaches it faster than a business that raises a handful of invoices a month. Xero's Australian pricing page carries the ceiling as a footnote against the Ignite plan, says it applies to both approving and sending invoices, and adds that transactions initiated by app partners may count towards it. A practice management sync is an app partner.

One number is published. Zanda states that a Xero trial allows 10 accounts receivable and 10 accounts payable invoices to be set to Approved, and sends you to Xero's pricing for the paid plans. The figure for the paid entry level plan did not come through when that page was read, so it sits in the open questions below rather than on this page.

Two things follow. The invoices that failed are not lost, they were refused, and they land once the ceiling moves. And the failure is silent in the ledger: revenue for those appointments is missing until someone notices.

Cashbook and Ledger organisations will not take invoices

Cliniko puts it flatly: Xero no longer supports invoicing integrations with Xero Cashbook and Ledger organisations. Zanda reports the same wall from its own side, as an export that cannot send invoices as Approved or send payments at all.

Cashbook and Ledger are the files an accountant sets up for a client whose books they keep. Zanda puts the boundary in one line: those plans cannot receive invoices or bills from third party apps. Two vendors hitting the same wall is the tell that it is a Xero product boundary, so changing practice systems does not move it.

My Xero integration got disconnected

Cliniko keeps a separate article for this one. The cause it gives is that Cliniko tried to talk to Xero, Xero could not answer, and the integration was disconnected to avoid any mishaps. The disconnection is the safety behaviour, not the fault.

The reconnection is short: open the integration settings, connect to Xero, sign in, grant access, check the default accounts, and save. The part people miss is what happens to the gap. Cliniko answers it with a separate catch up control, which is the tell that reconnecting on its own does not resend what was missed.

Catching up after a gap

Cliniko's catch up control is a synchronise from a previous date, which resends everything from the date you choose. It runs in the background, and payments go across at one per minute because that is what the Xero API allows, so a gap of a few weeks in a busy practice runs for hours rather than minutes.

Pick a date safely before the gap started. A little overlap is cheaper than a second run.
Clear the constraint that caused the failure first, or the catch up refuses the same documents again.
Let it finish before judging it. A run that looks stuck is often just working through payments at the throttle.
Check the clearing balance for each rail afterwards, where a missing payment shows as a difference rather than an error.
Where the gap crossed a period you have since locked, unlock, run the catch up, then lock again, which is covered on the lock date page.

Invoices first, payments second

There is an ordering trap that turns one refused write into two problems. Zanda exports in two batches, invoices and then payments, and Cliniko pushes an allocated payment only once its invoice is there. Either way the payment depends on the invoice.

So an invoice that was refused takes its payment with it. The practice sees one error, and the ledger is short by two documents: revenue missing from the period, and a settlement that never reached its account. The bank line for that day then matches nothing, which is usually how it gets noticed, days later and by the wrong person.

Checking a month landed before you reconcile

A refused write is loud on the day and silent a month later. The error sits on a list nobody opens and the ledger simply reads low. So the check that matters is a count, not an error message.

Pull the month from the practice system as an invoice count and a total.
Pull the same month from Xero on the sales accounts the map names, drafts included.
Compare counts before totals. One missing invoice shows in the count and hides in the total.
Where totals differ and counts match, look for an edited invoice rather than a missing one.
Run it before the bank reconciliation, while the error is still on the failure list.

What a stuck invoice costs while it sits there

One refused write is small. A habit of them is not, because each leaves a gap somebody has to find later without the error message in front of them.

Revenue for those appointments is missing from the period, so the profit and loss reads low and nobody knows by how much.
The balance the settlement should have landed in is short, so the bank deposit for that day has nothing clean to match against.
Aged receivables in the practice system and in Xero disagree, and the difference is not a list anyone can pull.

Keeping it from coming back

None of these are Xero settings. They are habits about which system owns a document once money has touched it.

Correct paid invoices in Xero, not in the practice system. Once a payment is on it, the practice system copy is the one that cannot travel.
Set the lock date after the sync has caught up, not before, and treat unlocking as a scheduled job rather than an emergency.
Watch the approval ceiling ahead of the busy months rather than discovering it mid week.
Give the sync one Xero organisation and check which one it is pointed at after any reconnection.

If the lock date is the recurring one for your practice, lock dates and sync works through the scheduling side of it.

What Ledger Map does with it

Ledger Map holds one standing map for the practice, approved before anything is written, so the account and tax treatment for a line are settled in advance rather than discovered when Xero refuses the write. A document it cannot place becomes a question with the options laid out, not a silent gap.

On the money side the rule is the same one this page keeps coming back to: 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 it mean when an invoice fails to sync with Xero?
It usually means the write reached Xero and Xero refused it. The connection is working. The invoice on the Xero side is in a state that will not take the change, most often because a payment is already allocated to it or its date sits inside a locked period. The error string names which constraint applied.
Is there currently a problem with Xero, or is it my invoice?
Tell the two apart by scope. Where every write fails at once, the connection or Xero itself is the suspect, and Zanda's list names that case as an unexpected response received from Xero. Where one invoice fails and the rest land, the fault is that document, and the error string says which constraint Xero applied.
What is the limit of invoices you can approve in Xero?
It is a ceiling on the Xero subscription rather than anything in the practice system. Xero's Australian pricing page says invoice limits for the Ignite plan apply to both approving and sending invoices, and that transactions initiated by app partners may count towards the limit. Zanda states a Xero trial allows ten invoices of each kind to be approved. The figure for the paid entry level plan is not stated on either page, so it sits in this page's open questions.
Can a Xero Cashbook or Ledger organisation receive invoices from a sync?
No. Cliniko states that Xero no longer supports invoicing integrations with Xero Cashbook and Ledger organisations, and Zanda reports the same refusal as an export that cannot send invoices as approved or send payments. A standard Xero organisation is what the sync needs to write into.
Do invoices catch up on their own after the integration reconnects?
Not on their own. Reconnecting restores the link, and a separate catch up resends everything from a date you pick. Payments move at one per minute through the Xero API, so a gap of a few weeks in a busy practice takes hours to close.
Why did the payment fail when only the invoice was refused?
Because the payment depends on the invoice. Zanda exports invoices and payments as two batches, and Cliniko sends an allocated payment only once its invoice is in Xero. One refused invoice therefore leaves two gaps: missing revenue, and a settlement with nothing to attach to.

Sources

Open questions

The numeric invoice approval limit on Xero's paid entry level Australian plan. The pricing page carries the footnote naming the Ignite plan, but the figure did not come through when the page was read on 3 Sep 2026. The only published number on either vendor page is Zanda's trial figure, so nothing is stated here for a paid plan.
Whether that approval limit counts a calendar month or a billing month, which decides whether a practice waits or changes plan. Neither vendor page says.
Whether a real time push retries a refused write by itself, or waits for a person to run the catch up. Cliniko documents the catch up control and does not say what happens without it.
Neither vendor page carries a calendar last updated date, only a relative one, so the retrieved date is the only firm date on all four of them.
Whether either vendor lists its failed writes somewhere a practice can subscribe to, so a gap is noticed on the day rather than at month end. Neither page describes an alert.

Integrate Cliniko with your Xero account
Cliniko. Retrieved 29 Aug 2026.
primary
Exporting to Xero
Zanda. Retrieved 3 Sep 2026.
primary
An invoice failed to sync with Xero
Cliniko. Retrieved 4 Sep 2026.
primary
Troubleshooting Xero exports
Zanda. Retrieved 3 Sep 2026.
primary
My Xero integration got disconnected, help
Cliniko. Retrieved 3 Sep 2026.
primary
Set up Xero for use with Cliniko
Cliniko. Retrieved 3 Sep 2026.
primary
Pricing plans, Australia
Xero. Retrieved 3 Sep 2026.
primary
How Cared automated Cliniko to Xero reconciliation
Airtop. Retrieved 3 Sep 2026. Source updated 23 Jan 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.