Problems
Duplicate patient contacts in Xero
Xero holds one contact per name, and the practice management system creates that contact from the client name on the first invoice it pushes. Change the name in one system and not the other and the next sync writes a second contact rather than renaming the first. Merging tidies the ledger. Which contact you keep decides whether the next sync works.
Key facts
- What creates the contact
- Zanda creates it on the first export for a new client: that client is created as a contact in Xero, under the name carried on the invoice3
- What creates the second one
- A patient name changed in Cliniko without also updating it in Xero, so the next push writes a new contact under the new name1
- The identifier under the name
- A contact id Cliniko's article describes as something only Xero can see, which is how one patient ends up behind two names1
- The error that surfaces it
- The existing contact with name cannot be updated to use new name, there is an existing contact with that name1
- Which contact to keep with Cliniko
- The contact the integration already writes to. Cliniko's own fix restores that contact and renames it rather than adopting the newer one1
- Which contact to keep with Zanda
- Either one. Zanda holds a Xero Contact ID on the client profile under Admin and Manage, and it can be pointed at the contact that survived2
- The other trigger
- A company name on the client record, which Zanda uses as the Xero contact name until the company name is removed2
- The number Zanda writes
- A Zanda created contact carries a Contact Code equal to the client number from Zanda, and Xero does not let a user edit that number2
- Archiving is not the fix
- A contact archived in Xero stops the next invoice until it is restored, so archiving the spare copy moves the problem rather than closing it1
Why one patient ends up with two contacts
Zanda states it plainly: the first time an invoice is exported for a new client, that client is created as a contact in Xero. Cliniko does not document contact creation in its integration article at all. It surfaces only on the troubleshooting page, where a name change is described as producing a new contact in Xero. Neither integration asks you to map a patient to a contact first, which is what makes the setup painless and what makes the failure quiet.
The handle in that arrangement is the name. Xero will hold one contact under a given contact name, and the name on the invoice is the only thing the integration has to go on. So a patient is not really a patient to Xero. A patient is a string, and two strings are two people.
That is why the duplicate does not look like a bug. A spelling was corrected, a company was added for an insurer billed client, a contact was archived during a tidy up. Each is reasonable in one system, and each changes the string the other one matches on.
What creates the second contact
Four triggers account for most of them, all four documented by the vendors rather than inferred. Read them as a set: the fix differs by which one you had.
- The client name was changed in the practice management system and not in Xero. Cliniko's article says so directly: the name was changed on its side without also updating it in Xero, which means a new contact with the new name was created in Xero.
- A company name was entered on the client record in Zanda, so the Xero contact was created under the company name. Removing the company name later makes Xero attempt to rename that contact to the client name, and where a contact already sits under that name the export fails.
- The Xero contact was archived. Cliniko surfaces this as the contact with the specified contact details has been archived, and the contact must be un-archived before creating new invoices or credit notes, so a contact archived during a clean up blocks the next invoice instead of quietly reappearing.
- The export setting changed. Zanda's export settings include one for the client's full name, and with it unticked the export carries the first name and the first letter of the last name rather than the whole name, which is a different string from the one a manually created contact carries.
If you use the Company Name field ... Xero will create a new contact using the Company Name as the Contact Name. If you later remove the company name ... Xero will attempt to rename the contact to the Client Name.2
The fourth reaches furthest, because a practice flips that setting once, for a privacy reason, and then forgets it. From that day the contact list holds two naming conventions.
The key you cannot see
Underneath the name, Xero identifies a contact by an id. Cliniko's explanation of the mismatch error is the clearest statement of it a vendor puts in writing.
this mysterious 'John' has the same unique 'Contact ID number' (something that only Xero can see), the name isn't 'Jon' anymore1
So there are two identities in play. The one you can see is the name, and it is the one that collides. The one you cannot see is the id, and it is the one the integration is bound to. A merge chosen without knowing which contact carries the id the integration writes to is a coin toss, and the losing side of the toss is the next failed sync.
Zanda is the exception worth knowing about, and it is the reason this page splits the answer by system. Zanda keeps that id where a person can reach it: the client profile carries a Xero Contact ID field under Admin and Manage, and a contact id copied out of a Xero contact URL can be pasted straight into it. Third party billing contacts work the same way. Cliniko exposes no equivalent field, so the binding on that side is not something a practice can move.
Which contact to keep
This is the part the vendor articles leave to the reader. Both tell you how to clear the error in front of you. Neither says which contact should be standing afterwards, and that choice decides whether the fix holds for one invoice or for good.
| Practice system | Can the link be repointed | Contact to keep | What to do after the merge |
|---|---|---|---|
| Cliniko | No field is exposed for it | The contact the integration already writes to | Rename the surviving contact to match the client name in Cliniko, then resync the invoice that failed |
| Zanda | Yes, the Xero Contact ID on the client profile | Either one, chosen for the history it carries | Paste the surviving contact id into the client's Xero Contact ID field under Admin and Manage, and clear any company name you are not using |
| A contact created by hand in Xero | Only from the practice management system side | The one the sync created, unless the hand made contact holds the longer history | Check the client name matches character for character before the next invoice goes out |
The Cliniko row is the one that surprises people. The instinct is to keep the contact carrying the correct spelling, because that is the contact a person would choose. Cliniko's documented sequence does the opposite: archive the contact carrying the correct name, find the original contact in the archived list, restore it, rename it to match, and resync. The contact you keep is the one the integration knows, and the name is what you change to fit it.
What the merge changes in the ledger
Until the merge, the ledger tells a bookkeeper something untrue about the patient. Two contacts split one person's invoices, so aged receivables shows two part balances and a statement sent from either contact is incomplete.
The last row is the one to check before the merge rather than after it. A tidy contact list that the practice management system cannot write to has moved the problem from the receivables report to the sync log, and the sync log is the place a bookkeeper looks last.
Merging without breaking the next sync
The order below settles the binding before it touches the names. Xero's own merge behaviour, including what it does with the history on the contact that goes, is left as an open question here, so read Xero Central for the mechanic and treat these steps as the wrapper around it.
- Find both contacts in Xero and check the archived list as well as the active one, because a contact archived earlier is the usual reason a duplicate appeared at all.
- Decide which contact the practice management system is bound to. With Zanda, read the Xero Contact ID on the client profile. With Cliniko, treat the older contact as the bound one, since that is the contact its documented fix restores.
- Restore the contact you are keeping if it is archived, before anything else, because an archived contact stops new invoices and credit notes.
- Merge the spare contact into the one you are keeping, so the invoices and payments end up on one record.
- Rename the surviving contact so it matches the client name in the practice management system character for character, including the email address where the sync carries one.
- With Zanda, paste the surviving contact id into the client's Xero Contact ID field, and clear the company name if the practice is not using it.
- Resync the invoice that failed, and confirm it landed on the contact you kept rather than creating a third one.
Stopping it happening again
A merge is a repair, and repairs recur unless the habit changes. Four house rules cover the triggers above.
- Change a client name in the practice management system only, and let the change flow. Editing the name on both sides at once is what produces two contacts that each think they are right.
- Leave the company name field alone unless the payer really is a company, and decide once, at setup, rather than part way through a patient's history.
- Archive contacts in Xero only for people the practice has finished with, and check the practice management system has no active client pointing at them.
- Set the name and address export settings before the first export, and treat a later change to them as a project rather than a toggle, because it changes the string every future contact is created under.
What a merge does not fix
Contacts are one of two things the practice management system numbers on your behalf. The other is the invoice number, and a merge does nothing for it. A number reused after a void produces its own error, which the invoice not of valid status for modification page covers.
Two pages sit either side of this one. The contact name already exists error sorts the error strings the exports return, which is the page to read when you have a message in front of you rather than a duplicate in the list. The system hubs for Cliniko and Zanda carry what each integration does and does not send.
What Ledger Map does with it
Ledger Map does not resolve a patient by name. A client carries its identifier from the practice management system, and that identifier is what the standing map holds, so a spelling correction is a change to a label rather than a new party. Where a name change would produce a second contact, the reader gets a question naming both contacts and what sits on each, rather than a posting made on a guess.
The rest follows the same shape as every page here. One balanced document set per deposit, posted against the accounts the practice approved in its map before anything synced, leaving one exact match in the bank feed. A line the map cannot resolve waits in the questions queue. The how it works page shows the whole flow.
Questions
Which duplicate contact should I keep in Xero?
The one the practice management system is bound to. With Cliniko that is the older contact, which is why its documented fix restores that contact and renames it rather than adopting the newer one. With Zanda you can keep either, because the client profile holds a Xero Contact ID field that can be pointed at whichever contact survived.
Why did changing a patient name create a new contact?
Because the name is the handle. Cliniko's article puts the cause plainly: the name was changed on its side without also updating it in Xero, so the next push created a new contact under the new name. Xero holds one contact per contact name, so a new string reads as a new party.
Can I just archive the duplicate instead of merging it?
Archiving moves the problem. Cliniko returns an error saying the contact with the specified contact details has been archived and must be un-archived before creating new invoices or credit notes, so an archived contact the integration is still bound to stops the next invoice rather than stepping aside.
Why do I have a Xero contact under a company name?
Because a company name was entered on the client record. Zanda creates the Xero contact under the company name while that field is filled. Removing the company name later makes Xero attempt to rename that contact to the client name, which collides with any contact already sitting under it.
Can I merge two contacts in Xero?
Yes. Xero lets you merge duplicate contacts into a single contact record, and its help centre carries the steps. What that article leaves open is which of the two should be the one still standing. Where a practice management system writes to one of them, keep the contact it is bound to, or repoint the system at the survivor where it gives you a field for that.
Does the merge fix the split receivables balance?
It brings the invoices onto one contact, so the balance reads as one patient again. What it does not settle is the binding: check that the practice management system points at the contact you kept before the next invoice goes out, or the next sync writes a fresh duplicate.
Read next
- ProblemsThe Contact Name already exists error in Xero
- ProblemsInvoice not of valid status for modification
- ProblemsArchived Cliniko invoice is still open in Xero
- Practice systemsCliniko Xero integration: what syncs, what does not
- Practice systemsZanda Xero integration: what the batch export carries
- ProblemsInvoices paid by account credit stay open in Xero
- HubProblems
Sources
Open questions
- What Xero's merge does with the history on the contact that goes, and whether a merge can be reversed. Xero Central's merge contacts article returned an empty body to three fetch attempts on 3 Sep 2026, so it is cited here as unverified, no key fact rests on it, and the mechanic is left to Xero's own page.
- What happens to contacts already in Xero when a practice turns the client full name export setting off part way through. The setting and its two states are documented; its effect on contacts created before the change is not.
- Whether a Zanda contact code can be cleared or reused once the contact it sits on has been merged away. Zanda states the code is the client number and that Xero does not let a user edit it, and neither vendor says what a merge leaves behind.
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.