Practice systems
Zanda Xero integration: what the batch export carries
Zanda exports to Xero in two manual batches: the invoices first, then the payments applied to them. Sales accounts are mapped by calendar rather than by service, one payments account takes every payment in a batch, and NDIS participant numbers and support item codes stay behind. Matching the funder deposit is still done in Xero.
Key facts
- Direction
- Into Xero as a batch a person starts rather than a live sync, with a Beta import of reconciled payments coming the other way1
- Batch order
- Invoices first, then payments, because a payment needs an approved invoice to attach to1
- Which payments a batch picks up
- The date the payment was applied to its invoice in Zanda, not the invoice date1
- Sales account mapping
- By calendar, through Map to Diary, not by service and not by tax rate2
- Payments account
- A single account, separate from the sales account, often a payments clearing account1
- Payment methods
- Not mapped to accounts, so each export uses whichever payments account is selected in Xero Settings at the time2
- What comes back
- In Beta, payments reconciled in Xero import against the invoice Zanda exported, and the first import picks up the previous seven days1
- Tracking categories
- Up to two, pre-assigned to the batch before it is exported2
- What the export leaves out
- The NDIS participant number and the NDIS support item code are not in it anywhere2
- Invoice status
- Draft can still be edited in Xero but takes no payment. Approved takes a payment and cannot be changed1
- A tax rate that slips
- A GST free code reaches Xero at the BAS excluded rate where the invoice Tax Usage is set to No Tax3
Why the export runs in two batches
Zanda does not stream data into Xero. Somebody opens the export screen, picks a date range, and sends a batch. Then they do it again for the payments. The order is a rule Xero imposes rather than a preference: a payment has to land on a document Xero has already authorised.
Invoices in Xero must have a status of Approved before a payment can be applied.1
The second batch is filtered on the date the payment was applied to its invoice in Zanda, not on the invoice date. A payment recorded a fortnight after the visit is picked up by the window covering the day it was applied. That is the setting most likely to leave a payment behind, because a narrow window looks correct and quietly misses the late allocations.
Draft or Approved, and what each one costs
The invoice batch asks for a status, and the choice decides what the rest of the month looks like. Draft keeps the door open in Xero and shuts it on payments. Approved does the reverse.
| Status | What you can still do in Xero | What it stops |
|---|---|---|
| Draft | Edit the invoice, delete it, fix a contact | No payment can be applied, so the payment batch fails against it |
| Approved | Apply the payment batch against it | The invoice cannot be changed once a payment is on it |
Practices on a Xero Cashbook or Ledger plan do not get the choice. Those plans cannot take an invoice from a third party app, so only a draft export works until the plan changes.
Sales accounts are mapped by calendar
Map to Diary links a Zanda calendar to a Xero sales account. A calendar is usually a practitioner, so revenue by practitioner is available if every practitioner gets an account. What is not available is revenue by what was actually done.
Service categories in Zanda help organize services, including on the Client Portal, but they do not route invoice line items to different Xero accounts.2
That matters because the thing that decides the account and the tax rate for allied health revenue is not the practitioner. It is who funded the service and what the service was. One psychologist can bill all five of the rows below in a single week, on one calendar, and they post to five accounts at two different Xero tax rates.
Zanda's own FAQ says the same thing from the other side: GST free and GST applicable invoices raised on one calendar go to the same mapped sales account. Separate batches only help where an export filter such as Location already separates the invoices, so a practice whose two tax rates sit on one calendar has no filter to split them on.
One payments account takes the whole batch
The payments batch sends every payment it carries to a single Xero account, chosen before the batch runs. Zanda's own guidance is to make that a payments clearing account rather than the bank account, and then to reconcile the bank deposit against it with a receive money entry coded to that account.
Splitting payment methods is possible, but it is a manual loop: filter the batch to one method, set the account, export, then change the setting and go again. A practice taking card, Medicare, plan manager and bank transfer money in the same week is running four passes, or accepting that they all land together.
Two tracking slots, set before the batch
Up to two Xero tracking categories can be pre-assigned to a batch before it exports, which is how a practice splits reporting by location or by discipline. Because the assignment sits on the batch rather than on the line, a batch that mixes two locations carries one label for both. Multi-site practices end up exporting per site to keep the labels honest.
One documented catch: saving the Xero settings resets the export filters. Set the accounts, the tracking categories and the tax mapping first, save, then load the batch.
What stays behind in Zanda
Contact details, the invoice line items and the invoice reference make the trip. Zanda states plainly that two fields an NDIS provider needs are not in the export anywhere.
the NDIS Participant Number and NDIS Support Item Code are not included anywhere in that export2
- The NDIS participant number, so a Xero invoice cannot be matched back to a plan by the number the funder uses.
- The NDIS support item code, unless the practice writes it into the service name, which is what Xero receives as the line description.
- Any payment method to account mapping, so a batch lands in whichever payments account is selected.
- The service category, which stays in Zanda as an organising label and reaches no Xero account.
- Client names and addresses, where the practice unticks the two export settings and sends a first name, an initial and the client ID instead. That one is a choice, and a good one for a practice minimising what it holds in a second system.
The tax rate that slips
Zanda tax rates map to Xero tax types in the integration settings, and one failure mode is documented by name. A line the practice intends as GST free can arrive in Xero at the BAS excluded rate instead, and Zanda names the cause: the invoice Tax Usage in billing settings is set to No Tax.
The two rates look equally harmless in the account and are not the same thing on the BAS. GST free income belongs at G1 total sales. Revenue sent across at the BAS excluded rate appears nowhere on the statement, so the return understates total sales while the bank account and the profit and loss both look right. Zanda's fix is to set Price Includes Tax or Price Excludes Tax and re-add the line items.
When a batch fails
Zanda's troubleshooting article carries nineteen headings, each a message or a symptom with a cause under it. Most are Xero rules restated: a document Xero has already settled will not take an edit pushed at it, and a contact key that already exists cannot be taken by a second contact.
| What Xero says | What happened |
|---|---|
| Payments can only be made against authorised documents | The invoice went across as Draft, so there is nothing authorised to pay |
| Payment amount exceeds the amount outstanding on this document | A Stripe card processing fee was added after the invoice was exported and approved |
| Invoice not of valid status for modification | The invoice is already in Xero at a different status, or a payment is going onto an invoice still in Draft |
| The Contact Name already exists | A Xero profile already holds the same name combination, so this one cannot be exported |
| Another contact has this contact number | An existing contact, often archived, already holds that account number |
| Bank account status invalid for payment creation | The payments account was deleted, archived or edited in Xero |
| Invoice or Payment is in Xero Locked Period | The invoice date or the payment date falls inside a Xero locked period |
| To update fields on a paid invoice line item, you must supply a LineItemID | A service item code is missing or is not numeric, or the invoice was adjusted and not re-exported as approved |
The month end job the export leaves behind
None of this is a fault in Zanda. It is what happens when a batch export meets funders who pay in lumps, and it settles into the same list every month.
- Run the invoice batch, then run the payment batch over the date applied rather than the invoice date, and check what the second batch did not pick up.
- Take each funder deposit on the bank feed and find the clearing entries behind it, using the funder's own report or remittance rather than the bank narration.
- Code the deposit to the clearing account, so the bank carries one line per deposit and the clearing balance falls back towards nil.
- Chase the balance that will not clear. It is either a claim paid but not exported, or an exported payment the funder did not send.
- Split revenue that the calendar mapping put in one account but the funder and service put in two, before the BAS is prepared.
- Re-run the failures from the error list, then check that nothing was exported twice.
What comes back the other way
The export runs one way and a Beta capability now runs the other. Zanda can import payments reconciled in Xero, matching each one to the invoice it exported, so a payment against an invoice raised in Xero has nothing to match and is skipped. The first import picks up the previous seven days.
Invoices still travel one way. One voided in Xero leaves Zanda showing it as live, so Zanda stays the record of what was billed. The API is a separate thread: the documentation site is live and labelled Beta, with invoice and payment resources and no webhooks, while the marketing integrations page still lists the API as coming soon.
Where Ledger Map fits
Ledger Map holds one standing map for the practice, approved by the practice before anything syncs. A billed line resolves to its account and tax rate through the funding source and the service category, which is the axis the calendar mapping cannot reach, and a line the map cannot resolve becomes a question with the options laid out rather than a silent posting.
For a deposit, it posts one balanced document set per deposit and leaves one exact match in the bank feed. It does not auto reconcile, and it does not choose a treatment: the accounts and tax rates come from the canonical template the practice starts from, and the practice approves the map before it runs. You can read the shape of it on how it works.
Zanda is the system the first release is built against, alongside Xero and Stripe. The deposits it has to reconcile against are the ones described on the NDIS plan managed page, the Medicare bulk bill page and the card and Stripe page.
Questions
Is Zanda the same thing as Power Diary?
Yes. Power Diary was renamed Zanda, and the Xero export described here is the same one. Older articles, forum posts and bookkeeper notes written about the Power Diary to Xero export still describe this integration. The support URLs moved too, from support.zandahealth.com to zandahealth.com/support/integrations, and the old addresses redirect.
Why does my Zanda payment batch fail with an authorised documents error?
The invoices went across as Draft. Xero only accepts a payment against an authorised document, so a draft invoice has nothing to pay. Re-export those invoices as Approved, then run the payment batch again. Approving them also closes the door on editing them, so fix anything that is wrong before the payment goes on.
Can Zanda send different payment methods to different Xero accounts?
Yes, but not in one pass. One payments account takes an entire export, and Zanda does not map a payment method to an account on its own. Separating card money from Medicare money means filtering the batch to one method, setting the account in Xero Settings, exporting, then changing the setting and running the next batch.
Does the Zanda export carry NDIS participant numbers into Xero?
No. Zanda states that the NDIS participant number and the NDIS support item code are not included anywhere in the export. What travels is the client's contact details, the invoice line items and the invoice reference. To get a support item code onto a Xero line, practices write it into the Zanda service name, because the service name is what Xero receives as the line description.
Why did a GST free line arrive in Xero at the BAS excluded rate?
Zanda documents this one by name. It happens where the invoice Tax Usage in billing settings is set to No Tax. Set Price Includes Tax or Price Excludes Tax instead, then re-add the line items so the rate is recalculated, and check the affected invoices before the BAS rather than after it.
Can Xero send anything back to Zanda?
Payments can, in a Beta capability. Zanda matches a payment you reconciled in Xero to the invoice it exported and records it against that invoice, so a payment on an invoice raised in Xero is skipped instead. Invoices do not travel back: one voided in Xero leaves Zanda showing it as live. The separate Zanda API documentation site is live and labelled Beta, while the marketing page still calls the API coming soon.
Read next
- FundersPlan-managed NDIS payments in Xero
- FundersHow Medicare bulk bill payments land in Xero
- FundersPrivate patients: card, EFTPOS and Stripe
- FundersHow NDIA agency-managed payments land in Xero
- Practice systemsCliniko Xero integration: what syncs, what does not
- FundersMedicare patient claims: who gets the rebate
- HubPractice systems
Sources
Open questions
- No article in Zanda's support centre carries a last updated date, so every source date on this page is the date the page was read.
- Every Zanda support URL moved to a new path between 29 Aug 2026 and 3 Sep 2026. Whether the article wording changed with the move was checked against the facts on this page rather than line by line.
- What happens in Xero to an invoice deleted in Zanda after it was exported. Earlier research recorded that the invoice leaves the Zanda export screen and nothing voids the Xero copy, and no current vendor article states it, so check it on your own file.
- What the export does with a refund or a credit note. Credit notes are named only inside Xero error causes, so what reaches Xero is unconfirmed.
- Whether the Beta import of reconciled payments is enabled on a given account. Zanda states the options stay hidden until the Beta is turned on, and that accounts holding it see Tools then Xero rather than Tools then Xero Export.
- Whether the Zanda API beta is open to a new signup today. The documentation site is live and labelled a beta while the features page still says the API is coming soon.
- There is no Xero App Store listing for Zanda and no bookkeeper write up of this export that the research found, so nothing here rests on a practitioner describing it in their own words.
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.