Problems
Payments in Xero do not close the practice invoice
Because on most of these systems the sync runs one way. Cliniko, Nookal and PracSuite push invoices and payments into Xero and read no payment status back, so a payment you reconcile in Xero leaves the practice system invoice open. Splose reflects a paid invoice back, and Zanda documents a beta that imports reconciled Xero payments. On Cliniko the public API lists no payments resource.
Key facts
- The direction
- Cliniko states that it pushes invoices and allocated payments across to Xero. Its integration article describes no path in the other direction1
- Why an add-on cannot fix it on Cliniko
- The public API reference lists forty four resources, appointments and patients and practitioners and invoices and billable items among them, and carries no payments resource at all6
- The Cliniko invoice resource
- The reference page for the invoice resource publishes get operations only: list invoices, fetch one by id, and list the items on it. No write operation appears on the page7
- Zanda imports reconciled payments
- Zanda's export article documents a beta that brings payments you have reconciled in Xero back into Zanda, matching each one to the invoice it was exported from and recording it there2
- What Zanda's API publishes
- Zanda's API lists invoices and payments among sixteen resource types and documents reading them. The introduction shows no endpoint for writing a payment in8
- Splose
- Splose says invoices created in it sync to Xero, and that when invoices are paid they are automatically reflected back in Splose3
- Nookal
- Nookal's integration page describes invoices going out and Xero being updated when clients pay. It describes nothing arriving from Xero4
- PracSuite is a different shape
- PracSuite does not push each invoice. It creates one Xero invoice per payment method per day, and states that refunds are not considered when syncing9
- What one provider built instead
- A case study describes staff cross referencing budget lines, opening the practice system, finding each invoice and typing the payment in, then a browser robot built to do that typing11
- How a practitioner put it
- A physiotherapist reviewing Cliniko wrote that the Xero integration syncs one way only, so changes made on one side are not reflected on the other10
What is actually happening
You matched the funder deposit in Xero. The Xero invoice closed. You go back to the practice system and the same invoice is still sitting there unpaid, in the aged list, on the client's file, in the outstanding balance the front desk reads out.
Nothing failed. There is no error to find, no failed export list to open, no reconnect button that helps. The payment was created in Xero, and on these products the road runs the other way, so it has nowhere to travel.
On Cliniko, one way is the design
The vendor is open about it. Cliniko's own wording is that it will automatically push all invoices and allocated payments from Cliniko across to Xero. Push, from, across to. Every verb on that page points one way, and no sentence on it describes anything arriving from Xero.
The integration with the accounting software xero isn't fantastic. It syncs one way only so any changes to the invocie in cliniko dojesbt get reflected automatically in xero10
That is a physiotherapist writing a software review, typing errors and all. Her example points at Cliniko changes not reaching Xero, which is the direction that does travel. The phrase carrying the weight is the short one: it syncs one way only. The vendor documentation says as much in calmer language.
The run, drawn out
The gap opens at the fourth hop, and it opens quietly. Everything up to it works, which is why a practice usually finds out weeks later, from a client chased for money already paid.
Which systems write payment status back
Each vendor documents only its own product and none mentions the others, so comparing them means opening six help centres. Here they are side by side, from the page each vendor publishes.
| System | Into Xero | Back from Xero | What the vendor page says |
|---|---|---|---|
| Cliniko | Invoices on creation, allocated payments once allocated | Nothing described | Automatically push all invoices and allocated payments across to Xero |
| Zanda | Invoices in one batch, payments in a second, on export | Reconciled payments, on a beta that has to be enabled | In Beta, you can also import payments you have reconciled in Xero back into Zanda |
| Splose | Invoices, with the chart of accounts, tracking categories and tax rates shared | Payment status on an invoice | When invoices are paid, they are automatically reflected in splose |
| Halaxy | Invoices and payments, continuously | Invoice payments, on an optional mode this page could not read | The two way guide refused an automated read, so it is unverified here |
| Nookal | Invoices, and payments as clients pay | Nothing described | Invoices generated in Nookal are automatically synchronised with your Xero account |
| PracSuite | One Xero invoice per payment method per day, not one per practice invoice | Nothing described | PracSuite will create an invoice per payment method per day |
Read the Halaxy row carefully. Its two way guide returns a refusal to an automated reader, so what the mode covers is taken from the research corpus rather than from the page, and it backs nothing else here. The same caveat sits on the Halaxy system page.
Why no add-on closes the gap on Cliniko
The usual next question is whether some connector on the app store can bridge it. On Cliniko the answer runs into the public API. Its developer portal lists forty four resources, appointments and patients and practitioners and invoices and billable items among them, and there is no payments resource in the list. The invoice resource itself publishes get operations only. Requests are capped at 200 per minute per user.
A connector can only use the doors the API opens. With no payments resource, an outside tool has no supported way to record a payment against a Cliniko invoice, which makes this a product boundary rather than a gap in the market.
Where Zanda sits, and what its beta does
Zanda is the one that moved. Its export article documents a beta that brings payments you have reconciled in Xero back into Zanda, matches each one to the invoice it was exported from, and records the payment against it. Turning it on means choosing a payment method for imported payments first. After that it runs on a button, or once an hour if you switch automatic imports on.
Read the matching rule before you count on it. Zanda matches a reconciled Xero payment to the Zanda invoice it was originally exported from, so a payment sitting against an invoice raised directly in Xero, or against an invoice exported before the beta reached your account, has nothing to match and is skipped. The sync log names what it skipped and why.
The API is a separate question. Zanda's API lists sixteen resource types with invoices and payments among them, documents reading them, and shows no endpoint for writing a payment in, on rate limits of 100 requests in any 60 second period per key. So the import runs inside Zanda's own integration rather than through a door an outside tool can open.
What practices do about it today
There is no clever answer in this list. These are the four things practices actually do, and each one costs something worth knowing before you pick.
- Key the payment in twice. Reconcile in Xero, then open the practice system and mark the same invoices paid. It works and it is the reason the front desk is still doing data entry at six o'clock.
- Key it in once, from the remittance rather than the bank. Work the funder remittance into the practice system first, let the payments push to Xero the normal way, then match one deposit against the clearing entries in Xero. The practice system stays the record of truth.
- Drive the screen. The case study behind this page describes exactly that, a robot opening invoices and typing payments, built because the API had no door.
- Turn on what your own vendor has, or change systems. Splose reflects a paid invoice back, Zanda is running a beta that imports reconciled Xero payments, and Halaxy documents an optional mode. Switching is a large move to solve one workflow, so it usually rides along with a decision made for other reasons.
The second option is the one that scales. Money that arrives in bulk is described by the remittance, not by the bank line: the deposit tells you a total, the remittance tells you which invoices.
What double entry costs while it runs
One invoice keyed twice is nothing. A practice doing it every fortnight for a funder that pays in bulk accumulates four separate problems, and only the first one is obvious.
- Aged receivables in the practice system read high, because paid work is still open there. Nobody trusts the number, so nobody uses it.
- Clients get chased for money they have already paid, because the front desk reads the balance from the practice system.
- Somebody keys a payment into the practice system that then pushes to Xero, where the invoice was already settled, and now there are two payments on one invoice.
- The catch up gets skipped in a busy week and nobody records which one, so the gap has no edges by the time it is found.
The third one is the expensive one. It looks like a duplicate in Xero and it started as a fix, which is a hard thing to trace back a month later.
Finding the invoices nobody keyed
Because there is no error, the check has to be a comparison rather than a list. Run it monthly, before the practice system's aged report goes anywhere near a decision.
- Pull the practice system's outstanding invoices for the funder, as a list rather than a total.
- Pull the same funder's outstanding invoices from Xero on the accounts the map names.
- Compare the two lists by invoice number. Anything open in the practice system and closed in Xero is a payment that was reconciled and not keyed back.
- Work that difference from the funder remittance, not the bank line, so amounts land on the right invoices rather than the right total.
- Note the date you ran it, so the next run only has to cover the period since.
Before you switch systems over this
A two way sync solves the invoice status and leaves the rest of the reconciliation exactly where it was. The funder still pays in bulk, the deposit still covers many invoices, and somebody still has to decide which invoices a deposit settles. Write back moves the tick, not the matching.
PracSuite makes that point from the other side. It pushes no individual invoices at all, so the question of one closing in both places does not arise, and the job of tying a bulk deposit to the work it paid for is exactly where it was.
If the sync itself is refusing writes rather than running one way, that is a different problem with a different fix, and an invoice failed to sync with Xero covers it. Refunds and account credits have their own gaps: see a refund in Cliniko that did not reach Xero and account credit invoices that stay open.
What Ledger Map does with it
Ledger Map does not write into your practice system, and it does not try to reverse the sync. It works the deposit from the remittance, which is the side of the problem that scales: one balanced document set per deposit, posted to the accounts the standing map names, leaving one exact match in the bank feed for the bookkeeper to click.
That removes the reason most practices reconcile in Xero first and key back afterwards. Where a line cannot be placed, it becomes a question with the options laid out rather than a silent gap. See how the map is approved on how it works, or read the rest of this family on the learn hub.
Questions
Does Cliniko have a two way sync with Xero?
Not on the documentation read for this page. Cliniko describes pushing invoices and allocated payments across to Xero, and describes nothing coming the other way. A payment created in Xero stays in Xero, so the Cliniko invoice keeps showing as unpaid until somebody records the payment there as well.
If I reconcile a payment in Xero, will my practice system mark the invoice paid?
On Cliniko, Nookal and PracSuite, no. Those integrations send data into Xero and do not read payment status back. Splose states that when invoices are paid they are automatically reflected back in it. Zanda documents a beta that imports payments reconciled in Xero and records them against the invoice they were exported from. Halaxy documents an optional two way mode, which this page could not read and cites as unverified.
Can an app or automation mark a Cliniko invoice as paid?
Not through the documented public API. Cliniko's developer portal lists forty four resources and no payments resource among them, and the reference page for the invoice resource publishes get operations only, so an outside tool has no supported endpoint to write a payment to. The published workaround is a robot that drives the Cliniko screen and types the payment in, which one provider built for exactly this.
Is it better to enter the payment in the practice system or in Xero?
Entering it in the practice system is the one direction that travels. A payment recorded there pushes to Xero on the normal path, so both sides end up agreeing without a second keystroke. Working from the funder remittance rather than the bank line is what makes that practical when one deposit covers many invoices.
Why does my practice system show a client owing money they have already paid?
Usually because the payment was recorded on the Xero side. The Xero invoice closed, the practice system copy did not, and the balance the front desk reads comes from the practice system. Comparing the two open invoice lists by invoice number finds the ones that were reconciled and not keyed back.
Will switching to a two way sync fix my reconciliation?
It fixes the invoice status and leaves the matching. The funder still pays in bulk, one deposit still covers many invoices, and somebody still has to decide which invoices that deposit settles. Write back moves the tick from one screen to two. It does not tie the deposit to the work it paid for.
Read next
- ProblemsAn invoice failed to sync with Xero
- ProblemsCliniko refund does not show up in Xero
- ProblemsInvoices paid by account credit stay open in Xero
- ProblemsArchived Cliniko invoice is still open in Xero
- Practice systemsCliniko Xero integration: what syncs, what does not
- Practice systemsSplose Xero integration and the NDIS lump sum
- HubProblems
Sources
Open questions
- No search snapshot was captured for this query in this pass, so what the current top results say, and whether an AI overview shows for it, are both untested here.
- Zanda's payment import from Xero is in beta and has to be enabled on an account, and it matches only against invoices Zanda exported, so what a given practice can import is not something this page can state for all of them.
- Halaxy's two way guide returned a refusal to an automated reader, so what its two way mode covers is unverified and backs no key fact on this page.
- Splose states that a paid invoice is reflected back. Whether that covers part payments, refunds, or a payment later unreconciled in Xero is not stated on the page read.
- Five of the six vendor pages behind the direction table carry no calendar last updated date, so the retrieved date is the only firm date on them.
- Guide to two-way syncing between Halaxy and Xero
Halaxy. Retrieved 4 Sep 2026. Source updated 20 Oct 2025.
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.
Every practice starts from a template. Nothing posts until the map is approved.