Problems
Aged receivables will not split by funder
Xero ages receivables by contact. Its own API calls the report aged receivables by contact and marks the contact id required, so funder buckets appear only where the funder is the contact on the invoice. Bill each plan manager, insurer and employee assistance program as the payer, keep the patient in the reference field, and leave patient billed funders, agency managed NDIS among them, to the practice software.
Key facts
- How Xero groups the report
- By contact. The Accounting API report is AgedReceivablesByContact, and the contact id is the parameter the specification marks required1
- The contact on a funder invoice
- The payer, for NDIS plan managed, WorkCover, CTP or TAC, employee assistance and other third party work, in every canonical template that models the funding source5
- Where the patient goes
- The invoice reference field, which the API specification describes on a sales invoice as an additional reference number1
- Billed to the client instead
- Private, Medicare bulk bill, DVA, health fund, NDIS agency managed and NDIS self managed, in the allied health template4
- Where the payer is chosen
- In the practice software: Bill To on the client profile, or Payable By on a single invoice2
- What stays with the practice software
- Patient level ageing for patient billed funders, chased on statements3
- Where the funder still shows
- On the revenue line, one account per funding source, which is a different report from the debtor list4
What the report is keyed on
The aged receivables report lists what each contact owes, sorted into ageing periods. The grouping is not a setting. In Xero's own Accounting API the report is called aged receivables by contact, it sits at a path with that name, and the contact id is the one parameter the specification marks required. A report date and a from and to date sit beside it, and nothing else does.
So whether a practice can read its debtors by funder is settled long before anybody opens the report. It is settled by whichever name went on the invoice.
- What the report varies: the date it is run at, and the window the transactions are read from.
- What it does not vary: the thing it groups on, which is the contact.
- What sits on the line rather than on the invoice: the tracking option, which is why a tracking category does not rescue this report either.
What a practice sees instead
A practice whose software bills every appointment to the patient gets exactly what it asked for: one row per patient, hundreds of them, ordered by age. The funders behind those rows are not a column, because the funder did not reach Xero as anything the report reads. The practice software creates the Xero contact the first time it exports an invoice for a new client, so the default is a contact per patient unless somebody changed it.
The list the bookkeeper wants is shorter: what each plan manager owes, what each insurer owes, what each corporate program owes, and how old each of those balances is. That list is one decision away.
The contact rule that decides the report
The canonical templates make the choice per funding source rather than per practice. Where a third party pays, that payer is the Xero contact. Where the patient is the debtor, the patient is the contact. Every template that models a funding source makes the same call for it, and the allied health template states the reason on the policy itself.
Xero ages receivables by contact, so any invoice billed to a third-party payer needs that payer as the Xero contact, with the patient kept in the reference field, or aged receivables by funder cannot be produced.4
| Funding source | Contact on the Xero invoice |
|---|---|
| CTP or TAC | The payer |
| DVA | The client |
| Employee assistance program | The payer |
| Health fund | The client |
| Medicare bulk bill | The client |
| NDIS agency managed | The client |
| NDIS plan managed | The payer |
| NDIS self managed | The client |
| Other third party | The payer |
| Private | The client |
| WorkCover | The payer |
Read down the second column and the funder view falls out of it. Every row that says the payer becomes its own line on the aged receivables report, with its own ageing. Every row that says the client stays inside the patient list.
Where the patient goes when the payer takes the contact
The patient does not disappear from the invoice. Xero carries a reference field on a sales invoice, described in the API specification as an additional reference number, and the invoices endpoint takes a where filter the same specification describes as filtering by any element. The canonical templates put the practice software's own invoice id there, plus the claim or remittance reference once the funder supplies one, so a line in Xero can be traced back without opening anything else.
Naming the patient on a payer's invoice is a privacy decision as much as a bookkeeping one, so the templates differ on the default and say so rather than assuming.
- Allied health, revenue by funding source: full name.
- NDIS provider, plan-managed: initials plus Zanda id.
- Psychology practice with booking deposits: initials plus Zanda id.
The funders that stay with the patient
More than half the table keeps the patient as the contact, and for good reason: the patient is the person the practice would chase. A private patient owes the fee. A self managed NDIS participant is invoiced directly and pays from the plan. A health fund benefit and a Medicare bulk bill claim are approved on the practice's side and land as a settlement rather than as a debtor balance.
The allied health template's note on Medicare bulk bill is the honest version of this: most practices record the payment against the client rather than against a Medicare payee, either is possible in the practice software, and it is a choice to confirm per practice rather than a rule.
For those funders the practice software stays the source of patient level ageing, which is what a front desk needs anyway. The Medicare bulk bill page covers what happens on the settlement side instead.
Ageing buckets do not mean the same thing per funder
Once the funders are their own rows, the columns still need reading with the funder in mind. A payer working to written terms is not late in the way a patient with an unpaid invoice is late, and the same bucket carries both.
| Who pays | How the wait behaves |
|---|---|
| The agency, for agency managed claims | Typically paid within days where the claim was lodged correctly |
| A plan manager | Commonly several days to a couple of weeks, on the plan manager's own processing |
| A self managed participant | The longest and least predictable cycle, and genuine consumer credit |
That is one funder family. Add workers compensation, compulsory third party and employee assistance work and the spread widens again, which is the argument for reading the report per payer rather than as one ageing curve. The plan managed funder page has the payment mechanics behind the middle row.
The debtor queue and the clearing queue are different
A funder balance can be waiting in two different places, and only one of them is a receivable. An invoice the payer has not paid yet is a receivable, aged from its due date. A claim the funder has approved and receipted into a clearing account has left receivables, and what it is waiting for is a bank line.
- Aged receivables answers: which payers owe us money, and how long have they owed it.
- The clearing account answers: what has been approved or paid but not yet matched to a deposit.
- An agency managed NDIS claim is billed to the participant and claimed in the portal, so the NDIA balance shows up in the clearing queue rather than as a debtor row.
- The templates hold one clearing account per settlement rail rather than one per funding source, so the clearing view is not a funder view either.
Reading one for the other is how a practice concludes a funder is slow when the money is already in the bank. The clearing account that will not clear page works the other side of that.
Revenue by funder is a different question
None of this stops a practice reading revenue by funder, because the funder decides the revenue account rather than the contact. In the allied health template plan managed work posts to 405, WorkCover to 407 and private work to 400, so the profit and loss splits by payer whether or not the debtor list does.
So the two reports answer different questions from different fields. Revenue by funder comes off the account on the line. Debtors by funder come off the contact on the invoice. The page on all revenue landing in one sales account takes the first of those.
Changing the contact later
Invoices already in Xero keep the contact they were issued to. Changing the policy changes what happens next, so the report reads one way for the old invoices and another for the new ones until the old ones are paid. That is survivable, and it is easier than repairing a year of history.
It is also why the decision is worth making before the first sync rather than after the first month end. The practice software carries the same decision in two places: Bill To on the client profile sets the default, and Payable By on a single invoice overrides it, so a practice can move one funder at a time.
What Ledger Map does with it
Ledger Map holds the contact policy in the standing map, one line per funding source, approved by the practice before anything syncs. The payer is the Xero contact where the practice chose that, the patient identifier goes in the reference field with the claim reference beside it once the funder supplies one, and the naming card decides how much of a patient's name reaches Xero at all.
When the funder pays, the deposit is posted as one balanced document set, which leaves one exact match in the bank feed, so the payer's balance falls by the amount that actually arrived. A line the map cannot place becomes a question with the options laid out rather than a silent posting. The bookkeeper's view shows what that leaves on a month end desk.
Questions
How do I get an aged receivables report by funder in Xero?
By making the funder the contact on the invoices it pays, then running the standard aged receivables report. There is no funder filter to switch on: the report groups by contact, so each payer with its own Xero contact becomes its own line with its own ageing.
Who should be the contact on an invoice a plan manager pays?
The plan manager. All three canonical templates bill plan managed work to the payer, with the participant kept in the invoice reference, so one contact carries every invoice that plan manager is due to pay. Which plan manager it is comes from the practice software's Bill To or Payable By field.
Can a tracking category split receivables by funder instead?
Probably not, and the contact is the reliable split. A tracking option sits on the invoice line, and the accounting API's aged receivables report is keyed on the contact and takes no tracking parameter. The filter set on the report screen itself could not be read for this page, so check your own report layout before ruling it out. Tracking splits the profit and loss by practitioner or location, which is a different report from the debtor list.
How do I reconcile the aged receivables report to the balance sheet?
Run both at the same date and on the same basis. The report totals what is still owed on unpaid sales invoices at that date. A claim already receipted into a clearing account has left receivables, so it belongs in the clearing balance instead, and a difference is usually one of those postings sitting on the wrong day.
What happens to patient level ageing if the payer is the contact?
It moves to the practice software, which still holds the invoice against the patient. For funders billed to the payer that is the trade: Xero answers who owes the practice money, and the practice software answers which patient each of those invoices belongs to.
Read next
- ProblemsAll practice revenue lands in one Xero account
- ProblemsClearing account will not clear in Xero
- FundersPlan-managed NDIS payments in Xero
- Xero how toXero tracking categories for a clinic
- TemplatesAllied health chart of accounts, by funder
- Practice systemsZanda Xero integration: what the batch export carries
- HubProblems
Sources
Open questions
- Whether the Xero report screen offers any grouping beyond contact. The Accounting API specification is clear about the API report, and central.xero.com served an empty document for both aged receivables articles on 3 Sep 2026, so the filter set on the screen itself is unread.
- How best to repair invoices already issued to the wrong contact. Xero's own guidance on changing the contact on an approved invoice could not be read this session, so this page states the decision rather than a repair procedure.
- Whether a practice can hold both views at once without keying invoices twice. The corpus records no practice doing it cleanly, and the de-identified billing options change what the payer sees on the invoice.
- Whether one Xero contact per plan manager holds where a plan manager pays through several trading entities. The corpus records only that a clearing account per plan manager is optional and driven by volume.
- Xero Accounting API specification, xero_accounting.yaml
Xero, XeroAPI on GitHub. Retrieved 3 Sep 2026.
primary
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.