Problems
One bank deposit, many invoices in Xero
One deposit is a payment run. The practice software posts one payment per invoice, so Xero holds dozens of small payments behind a single bank credit. Match them in the bank feed with Find and Match, or post each payment into a funder clearing account and match the deposit against that account. Fees, reversals and short pays need a line of their own either way.
Key facts
- What the bank shows
- One credit for a payment run, whatever number of claims the funder settled in it10
- What Xero holds
- One payment record per invoice, pushed across once the practice software allocates that payment1
- How fast those payments arrive
- Cliniko says the Xero API accepts one payment each minute, so a long backlog trickles in rather than landing at once1
- The tool Xero gives you
- Find and Match, which matches a single bank transaction to multiple payments9
- Where the practice software posts them
- Into the clearing account the integration points at, as debits the deposit later credits9
- The document that itemises a run
- The Medicare payment report lists all claims included in the payment run with the total amount to be paid10
- Clearing accounts in the canonical template
- Ten, one per settlement rail, every one of them BAS excluded14
Two sides counting the same money differently
A practice earns money one session at a time and gets paid in lumps. The practice software knows about the sessions. It raises an invoice per appointment and, when a funder settles the claim, allocates a payment against that invoice. The bank knows about the lump: one credit per payment run, whatever number of claims sat behind it. Both records are right. They are counting different things.
Xero sits between them and inherits the mismatch. Cliniko pushes an invoice as soon as it is created and pushes a payment only once that payment has been allocated to an invoice, so a busy fortnight reaches Xero as a long list of small payments. Zanda exports in batches rather than live, so its payments reach Xero when somebody runs the export. Either way, by the time the deposit lands, Xero already holds the invoice level detail and the bank feed holds one line.
Bookkeeping for a speech pathology or allied health group practice is mostly about reconciling money that arrives in bulk against work delivered one session at a time.11
What the deposit actually is
The credit in the bank feed is a payment run rather than a payment. Somebody at the funder decided which approved claims went into this run, struck a total and transferred it. Each of the rails below publishes a document that itemises the run, and that document, not the bank line, is what a reconciliation is against.
Tyro Health puts the Medicare version plainly: a payment report is a summary of completed and approved bulk bill claims, and it lists all claims included in the payment run with the total amount to be paid. The equivalent for the NDIA or a plan manager is the remittance advice, and for a card terminal it is the merchant settlement report.
| Rail | What the single credit covers | The document that itemises it |
|---|---|---|
| Medicare bulk bill and DVA | Every approved claim in one payment run, paid per payee provider number | The payment report, with the processing report carrying the exceptions |
| NDIA and plan managers | One lump sum with the run's claim lines behind it, which can run to hundreds of rows | The remittance advice that comes with the run |
| Card terminals and online payments | A batch of card payments taken over one trading period | The merchant or gateway settlement report |
One deposit, drawn whole
Here is a single remittance settled as one credit. Five paid lines, two revenue accounts, one bank line. The fourth session was paid at less than the amount invoiced, which is the ordinary case that a tick box match cannot close.
Nothing in that run is wrong. The gap on the fourth session is a decision waiting to be made rather than an error to adjust away.
What Find and Match closes, and what it leaves
Xero's answer to a many to one deposit is find and match, which lets one statement line be matched against several transactions already in Xero. Cliniko points its customers straight at it: the function helps you find, and match, a single bank transaction to multiple payments. Where the payments add exactly to the credit, that is the end of it.
Three things break the clean case, and all three are ordinary rather than rare.
- A fee taken before the payout. The rail nets its fee out of the money, so the credit is smaller than the payments behind it. The statement line has to be split, the gross against the settlement account and the fee to merchant and claiming fees, which the canonical template posts at GST on expenses.
- A reversal from an earlier run. The funder takes a claim back by netting it against a later run, so this credit is short by an amount that has nothing to do with the work in front of you. It needs a credit note against the original invoice.
- A claim paid short. The funder paid less than the invoice, so the payment in Xero is smaller than the invoice it sits against and the gap stays open until somebody decides whether to credit it or chase it.
None of the three is a matching problem, which is why forcing the match with an adjustment buries them. Each one is a posting the deposit is asking for.
Three ways practices handle it
Practices settle on one of three patterns, and the choice shows up months later rather than on the day.
- Pay the invoices straight into the bank account in Xero, then match. This is the default when the practice software points at the bank account. The cost is that the Xero bank account fills with small payments that were not bank transactions at all, and anything that does not match cleanly stays there.
- Build a batch deposit for a remittance. Select the invoices one remittance covers, record one deposit dated on the deposit date, and reconcile the statement line against the batch rather than against the individual invoices. The cost is a manual build every run, a documented cap on how many invoices one batch holds whose published figure the sources disagree on, and the rule that the batch has to equal the deposit, so a fee, a reversal or a short pay has to be handled before it will save.
- Post each payment into a clearing account for the funder, then match the deposit against that account. The invoice closes on the date the funder paid, the Xero bank account carries one line per deposit, and the account balance is the money the funder has approved but the bank has not delivered.
Why the clearing account is the backbone
The third pattern is the one that survives a year of month ends, because it separates two jobs the other two run together: closing an invoice, and reconciling a bank line. Cliniko describes its half of it as creating debits in the clearing account, which the deposit then credits. The practice software can close invoices the day the funder approved them without waiting for the bank, and the bank feed still shows one line per deposit.
It also gives the leftovers somewhere to be. A balance in the account is a claim about the near future: money approved and not yet delivered, or a deposit with nothing sitting under it. That balance is the reading a practice can act on, and clearing account will not clear works through what each residue means. If the accounts are not there yet, set up a clearing account covers the chart of accounts side.
The date and the reference do most of the work
Two fields decide whether a deposit matches, and neither is an amount. The first is the payment date. Date it on the funder's paid date from the remittance and the payment falls inside the run that carried it. Date it on the bank date and the run is short by that payment while the next run is long by it, and both look like errors.
The second is the payment reference. Write the payment run number, the payment request number or the lodgement reference into the reference field on every payment in the run. That reference is what lets a person, or a matcher, group the payments back into the run the deposit paid, which an amount alone cannot do when two runs are close in size.
Two legs, and which one reaches the BAS
One deposit produces two legs, and conflating them is how a correcting entry lands on the wrong tax rate. The revenue leg was recognised when the invoice was raised and carries the treatment the service has: for a listed health service delivered as appropriate treatment that leg is GST free, and for a taxable item such as a product sale or room rental it is not.
The settlement leg is a movement between accounts the practice already controls, so it carries no tax consequence of its own. Every clearing account in the canonical templates posts at BAS excluded. Keep the two apart and the same revenue is not counted at G1 twice, once from the invoice and again from the deposit.
Keeping it workable at month end
Whichever pattern a practice picks, four habits keep a bulk deposit from becoming a monthly search.
- Reconcile against the funder's document, not against the balance. The remittance or payment report is the only record of what was in the run, and it arrives on its own schedule.
- One account per settlement rail rather than per funding source. The rail is what produces a bank line, so it is what the balance has to reconcile against, and the funding source stays on the revenue lines where the reporting needs it.
- Decide once, per funder, what happens to a short pay: credited to a funder shortfall account, or left outstanding against the payer. Made once, it stops being a judgement call at month end.
- Keep a list of what is still waiting. Claims approved and not yet banked, and deposits banked with nothing under them, are two different queues with two different owners.
What Ledger Map does with it
Ledger Map reads the funder's own document, posts one balanced document set per deposit, and leaves one exact match in the bank feed. The payments carry the funder's paid date and the run reference, the fee leg and the shortfall leg are posted as their own lines rather than buried in a difference, and a deposit that does not balance becomes a question with the candidate postings shown instead of a silent posting.
Nothing above is a treatment Ledger Map chose. The accounts and the tax types come from the canonical template the practice starts from, and the practice approves its map before an invoice syncs. What the product adds is that the run is reassembled from the document that itemises it, so the Medicare bulk bill run and the plan manager remittance are handled the same way rather than each by a different habit.
Questions
Can one payment cover multiple invoices in Xero?
Yes. A bank statement line can be matched against several transactions already in Xero with Find and Match, and a batch deposit groups the invoices one remittance covers into a single deposit. Both work when the payments add exactly to the credit. When a fee, a reversal or a short pay sits in the run, that difference needs its own posting first.
How do I reconcile one bank deposit against many invoices in Xero?
Start from the funder's own document rather than from the bank line. The payment report or remittance advice lists the claims in the run and the total paid. Receipt each of those claims against its invoice into the funder's clearing account, dated on the day the funder paid, then match the bank line against that account.
Why does my practice software create one payment per invoice?
Because it records what happened at the invoice level. Cliniko pushes a payment to Xero once that payment is allocated to an invoice, and Zanda exports in batches rather than live. Neither knows which payment run the funder will put a claim in, so neither can group them for you.
Why will Find and Match not tick to the deposit total?
Three things break a clean tick: a fee taken out before the payout landed, a reversal netted out of the run from an earlier claim, and a claim the funder paid short of the invoice. Each is a real posting rather than a rounding difference, so an adjustment that forces the match hides work that still has to be done.
Should I batch the payments at the bank instead?
A bookkeeper who works with Halaxy practices describes batching at the bank as looking efficient while often complicating the reconciliation, because somebody has to open the practice software again to see what was inside the deposit. Grouping the payments in the ledger keeps the invoice detail where the reporting needs it.
Read next
Sources
Open questions
- No search result snapshot was captured for this page's own query, so the claim that existing answers stop at the Xero screen is read from two adjacent queries in the same cache rather than from a ranking checked on the day.
- Xero Central refuses automated fetching, so its two articles are cited here from their search result snippets rather than from the article body, and neither carries a load-bearing figure.
- How many invoices one Xero batch deposit holds is disputed in the corpus: one vendor guide states a figure four times the other, and the lower figure rests on a Xero Central question title rather than on an article body. No cap is stated here until it is checked against a live Xero organisation.
- Whether a bank descriptor can be relied on to route a deposit to the right rail is left to the practice's own feed, so the matcher learns descriptor patterns rather than holding a string.
- The lag between a funder paying and the money landing is a working convention in the corpus rather than a published service standard, so this page states no waiting time.
- Medicare digital claiming: payment and processing reports, MDCM07INFO2
Services Australia. Retrieved 29 Aug 2026. Source updated Jul 2024.
primary
- Halaxy Xero integration tips for smooth syncing
My Great Bookkeeper. Retrieved 2 Sep 2026. Source updated 1 Jan 2025.
secondary
- Introduction to Tyro HealthPoint
Tyro Health. Retrieved 2 Sep 2026. Source updated 13 Jan 2026.
primary
- Reconcile in Xero when using the Cliniko integration
Cliniko. Retrieved 3 Sep 2026. Source updated 28 Jul 2026.
primary
- Bookkeeping for speech pathology and allied health practices
True Tally. Retrieved 3 Sep 2026. Source updated Jul 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.