How do I get rid of a credit sitting in Xero?

In this case there is usually no credit in Xero to get rid of, which is why the generic advice fails. The credit lives in the practice management system, and the receipt behind it was an unallocated payment that was not sent across. What Xero has is an open invoice and an unmatched bank deposit, and the two are joined by posting the receipt to the customer deposits account and paying the invoice from it.

Why did the invoice sync but the payment did not?

Because only payments allocated to an invoice in Cliniko are pushed. A credit allocation is a different object and Cliniko states it will not appear in Xero, so the invoice arrives with nothing paying it. Cliniko's own instruction is to record the payment against that invoice in Xero by hand.

Can I just mark the invoice as paid from the bank account?

It closes the invoice, and it puts the receipt in Xero on the wrong date and often twice, because the client's money is already sitting in the bank feed from the day they paid. Post the receipt once to the customer deposits liability account, then pay the invoice from that account on the date the credit was applied.

Is a booking deposit income when we take it?

The three canonical templates hold a booking deposit as a liability on receipt, at the BAS Excluded tax rate, and release it to revenue when the session happens or the fee is forfeited. A block of sessions sold as a named set is the exception, and the psychology and allied health templates default that to a part payment instead. Whether the practice's own deposit policy is better read as a part payment for a named session is a treatment choice the psychology template offers as an option and sends to the practice's BAS agent.

Does the same thing happen in Zanda?

The Zanda article read for this page covers a neighbouring failure rather than this one: a payment larger than the invoice fails on export with the message that the payment amount exceeds the amount outstanding on this document. It does not say what Zanda's export does with a credit allocation, and Halaxy, Nookal, splose and coreplus were not checked on this pass, so the credit allocation behaviour on this page is claimed for Cliniko only.

Problems

Invoices paid by account credit stay open in Xero

Cliniko sends invoices and allocated payments to Xero, and a credit allocation is neither, so the invoice arrives with nothing paying it and sits in Awaiting Payment. The receipt behind the credit was an unallocated payment, which Cliniko states will not be seen in Xero. Post that receipt to the customer deposits account, then apply it to the invoice in Xero.

Key facts

What Cliniko sends: Invoices when they are created, and payments once they are allocated to an invoice in Cliniko¹
What it holds back: Unallocated payments, which Cliniko states will not be seen in Xero, and credit allocations, which it states will not appear in Xero either¹
What you see in Xero: The invoice syncs and stays open, even though the same invoice is closed in Cliniko¹
Where the credit came from: Cliniko applies any unallocated payment as account credit on a patient's file²
The fix Cliniko names: Record the payment against that invoice in Xero by hand¹
Where the held money belongs: 245 Customer deposits and booking fees held, a liability account, where the template posts an unallocated payment at the BAS Excluded tax rate on receipt⁴
How the templates release it: A "Less deposit applied" line on the session invoice, so the invoice shows the full fee and the money already held against it⁴
The neighbouring Zanda error: A payment larger than the invoice fails on export with the message that the payment amount exceeds the amount outstanding on this document³

What you are looking at

Two systems disagree about one invoice. In the practice software the session is settled: the client had money on their file, that money was applied, the invoice is closed and nobody is chasing it. In Xero the same invoice sits in Awaiting Payment with the full amount outstanding, and it will still be sitting there at the end of the quarter unless somebody touches it.

The sync did not fail. Cliniko states the credit allocation is not sent, so the integration has nothing to raise an error about. That is what makes this one expensive: the ledger is wrong in a way that looks like ordinary unpaid work, so it gets found at year end by an accountant asking why receivables are so high.

Why the invoice stays open

The integration pushes two things: invoices, and payments that are allocated to an invoice. A credit allocation is a third kind of object, and it is not on the list. So the invoice travels and the thing that closed it does not.

Payments made using account credit in Cliniko are not accepted by Xero. The invoices will sync over from Cliniko, but they will remain as open invoices in Xero (even though they would be closed in Cliniko). You will need to manually record the payment against that invoice in Xero if it was paid using account credit in Cliniko.¹

That is the vendor stating the behaviour as a design decision rather than a fault. It is worth reading twice, because the last sentence is the whole fix for a single invoice, and it is buried in an integration setup article most bookkeepers meet once and close.

The credit and the receipt behind it

Account credit is not money that appeared from nowhere. It is a payment the practice took and did not attach to an invoice: a booking deposit, a client who paid a round number, a session that was moved and left the money sitting on the file. Cliniko turns that leftover into credit on the patient's file.

Cliniko will apply any unallocated payments as account credit on a patient's file.²

So one client transaction produces two gaps rather than one, and they show up at different times. On the day the money arrived, Xero got nothing at all, because an unallocated payment is not sent. Weeks later the session happens, the credit closes the invoice in Cliniko, and Xero gets an invoice with no payment against it. Fixing the second gap without the first one leaves the receipt posted twice.

One credit balance, and the two gaps it opens¹²⁴

What happened in the practice software	What Xero has	What is missing
A payment was taken and not allocated to an invoice	Nothing at all	The receipt, and the bank line it will arrive on
The unallocated payment became account credit on the file	Nothing at all	A liability for money the practice holds and has not earned
The credit was allocated to a session invoice	The invoice, open, for the full amount	The payment that closed it in the practice software

The money did arrive, so where is it

This is the part the generic credit note advice skips. The client's money is real. It went through a terminal or a card page or a bank transfer, and it is sitting in the bank feed as a deposit with no document in Xero to match it against.

That unmatched deposit is the diagnostic. When an invoice is open in Xero and closed in the practice software, look for the receipt on the day the client actually paid rather than the day the session happened. If it is in the feed unmatched, or worse, if somebody has already coded it straight to a revenue account to make the feed go quiet, you have found both halves of the problem.

The same session, posted twice

Held client money has a place to sit, and it is not a revenue account and not the invoice. The canonical templates put it on the balance sheet as a liability until it is applied to a session, forfeited as a cancellation fee, or refunded.

Plate 1One prepaid session, as Xero has it after a credit allocation and as the templates post it.

All three canonical templates carry that liability account at the same code, 245, post an unallocated payment held as account credit there at the BAS Excluded tax rate on receipt, and release it with a "Less deposit applied" line on the session invoice. Keeping the receipt out of the activity statement until the session happens is the point of that tax rate: the money is held, not yet earned.

A block of sessions sold as a named set is the case the templates read differently. The psychology and allied health templates default a session block to a part payment, so revenue is taken when the money arrives rather than held against a session that has not happened, and both flag that default as unproven pending the practice's BAS agent. GST on prepaid session packages carries that reading.

Closing one invoice today

For a single invoice, Cliniko's instruction is the short path, with one step added in front of it so the receipt is not posted twice.

Find the date the client actually paid, in the practice software's payment list rather than on the invoice.
Find that deposit in the bank feed and check what was done with it. If it was already coded to revenue, that posting is the one to undo.
Post the receipt to the customer deposits liability account, dated the day it arrived, and match the bank line to it.
Open the invoice in Xero and record the payment against it from the same liability account, dated the day the credit was applied in the practice software.
Check the liability balance afterwards. It should equal the credit the practice management system says clients still hold.

Doing that once takes a few minutes. Doing it for every prepaid session in a quarter is the reason practices go looking for this page, and the reason a standing rule beats a monthly clean up.

What it does to your reports

Left alone, the gap is not one wrong number. It moves four of them, and only one is visible on the invoice list.

Aged receivables overstate what clients owe by the value of every invoice a credit closed, which makes debtor chasing unreliable and makes the practice look owed money it already has.
The balance sheet says nothing about money held for future sessions, so a liability the practice genuinely owes in service is invisible until somebody asks for a refund.
Revenue is understated while the invoices sit open on a cash basis, then overstated later if the same receipt is coded to income when the bank feed is cleared.
The bank feed carries deposits with nothing to match, which is the pressure that produces the wrong posting in the first place.

The last two are why this is worth fixing at the source rather than at year end. A bank feed with unexplained deposits rarely stays that way. The line gets coded to something, and the something is often revenue.

Telling held money from a sync gap

Two situations look identical on the invoice list and need different postings. One is money the practice holds for a session that has not happened. The other is a session that has happened and been paid, where only the paperwork is missing.

A balance on the client's file with no session against it yet is held money. It belongs on the balance sheet until the session happens, and it is refundable if it does not.
An invoice closed in the practice software by a credit is earned revenue with a missing payment record. The receipt was taken earlier and belongs on the liability account until the day the credit was applied.
A payment larger than the invoice is a different problem with its own error message, which Zanda's export raises as the payment amount exceeding the amount outstanding. That one is covered on the overpayment page.
A refunded credit is money out, not a credit note against an invoice, unless the credit had already been applied to one. Cliniko refunds that do not reach Xero are their own case.

Why a standing rule beats a monthly clean up

Every fix above is a judgement about one transaction: is this held money or earned money, and which day does it belong on. Made once and written down, it is a rule. Made from memory every week, it is a source of drift, and two people doing it are unlikely to do it the same way.

The practice management system already knows which payments are unallocated, which invoices a credit closed, and on what date. The information is not missing. It is on the wrong side of an integration that was built to push invoices and allocated payments, and stops there.

What Ledger Map does with it

Ledger Map holds one standing map for the practice, approved before anything syncs. An unallocated receipt resolves through that map to the customer deposits account the practice's template carries, and the credit allocation that later closes a session invoice resolves to a payment out of the same account on the date the practice software applied it. The deposit in the bank is posted as one balanced document set, and one exact match is left in the feed.

Where a receipt cannot be read as held money or as payment for an identified session, it becomes a question with both candidate postings shown rather than a silent guess. The templates take the same line on a refund that spans held and applied money. The learn hub carries the rest of the sync gaps a practice meets, and how it works shows the map itself.

Questions

How do I get rid of a credit sitting in Xero?
In this case there is usually no credit in Xero to get rid of, which is why the generic advice fails. The credit lives in the practice management system, and the receipt behind it was an unallocated payment that was not sent across. What Xero has is an open invoice and an unmatched bank deposit, and the two are joined by posting the receipt to the customer deposits account and paying the invoice from it.
Why did the invoice sync but the payment did not?
Because only payments allocated to an invoice in Cliniko are pushed. A credit allocation is a different object and Cliniko states it will not appear in Xero, so the invoice arrives with nothing paying it. Cliniko's own instruction is to record the payment against that invoice in Xero by hand.
Can I just mark the invoice as paid from the bank account?
It closes the invoice, and it puts the receipt in Xero on the wrong date and often twice, because the client's money is already sitting in the bank feed from the day they paid. Post the receipt once to the customer deposits liability account, then pay the invoice from that account on the date the credit was applied.
Is a booking deposit income when we take it?
The three canonical templates hold a booking deposit as a liability on receipt, at the BAS Excluded tax rate, and release it to revenue when the session happens or the fee is forfeited. A block of sessions sold as a named set is the exception, and the psychology and allied health templates default that to a part payment instead. Whether the practice's own deposit policy is better read as a part payment for a named session is a treatment choice the psychology template offers as an option and sends to the practice's BAS agent.
Does the same thing happen in Zanda?
The Zanda article read for this page covers a neighbouring failure rather than this one: a payment larger than the invoice fails on export with the message that the payment amount exceeds the amount outstanding on this document. It does not say what Zanda's export does with a credit allocation, and Halaxy, Nookal, splose and coreplus were not checked on this pass, so the credit allocation behaviour on this page is claimed for Cliniko only.

Sources

Open questions

Every central.xero.com article on the first page of results returned no readable body to an automated fetch on 3 Sep 2026. The Xero side of the fix rests on Cliniko's instruction to its own users and on the canonical templates, and the Xero Central entry is listed unverified with no key fact resting on it.
Whether money taken before a session is a refundable security deposit or a part payment for an identified session is a treatment choice, and it changes when GST is attributed. The psychology template defaults to the security deposit reading, offers the part payment reading as an option, and its own note sends the choice to the practice's BAS agent and to a paid Xero test organisation.
Gift voucher treatment under ATO Division 100 is not covered by the research behind the canonical templates, and the template says so. A voucher balance sitting in the same client credit ledger is out of scope on this page.
The templates hold client money in a liability account with a released line on the session invoice rather than through Xero's native prepayment objects, because the template states native prepayments are not enabled in v1.
Cliniko is the vendor whose documentation states this behaviour in these words. The Zanda article read for this page documents the neighbouring overpayment error and does not say what its export does with a credit allocation, and Halaxy, Nookal, splose and coreplus were not checked on this pass.
A block of sessions sold as a named set sits in the same client credit ledger and the templates read it differently: the psychology and allied health templates default it to a part payment, and both flag that default as unproven pending the practice's BAS agent and a paid Xero test organisation. This page covers the unallocated payment and the booking deposit rather than the session block.

Integrate Cliniko with your Xero account
Cliniko. Retrieved 3 Sep 2026. Source updated 28 Jul 2026.
primary
Delete or refund a patient's account credit
Cliniko. Retrieved 3 Sep 2026. Source updated 3 Jan 2025.
primary
Troubleshooting Xero exports
Zanda. Retrieved 3 Sep 2026.
primary
Psychology with booking deposits, the canonical template
Ledger Map. Retrieved 3 Sep 2026.
primary
Credit notes explained
Xero Central. Retrieved 3 Sep 2026.
unverified

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.