Problems
One remittance paid across two bank deposits
The funder settled one payment run in two bank credits, and nothing in Xero ties them together. Post each invoice payment into the funder's clearing account on the date the funder paid, then clear each bank line against that account for the amount that line carries. Two credits, two matches, and the balance still returns to nil.
Key facts
- What Xero ties a bank line to
- One reconcilable line at a time. The vendor guide on this exact case puts it plainly: there is no field on an invoice or a batch payment saying a remittance was settled across two bank lines5
- Why the second credit has nothing to match
- Xero reconciles every bank deposit as its own separate line, so the second credit arrives with no document of its own to point at and the link back to the first has to be written by hand5
- What ties a paid line back to your invoice
- ClaimReference, the provider's own reference on the bulk payment request. The portal calls it optional, and it is the reference the remittance comes back on1
- How large a payment run gets
- One plan manager guide describes splitting a 500 line run into many batches, so a single credit can sit behind hundreds of invoices3
- Where a plan manager settlement posts
- Account 103, Plan manager clearing, at the BAS excluded tax type in the allied health canonical template, taking the paid amount gross8
- What a split does to that balance
- Nothing, once each credit is cleared for the amount it carries. The account holds the unpaid remainder of the run until the second credit lands, and returns to nil when it does8
- What the manual route costs
- The vendor whose product solves this publishes roughly 25 minutes to match the invoices on a mid sized remittance and a further 40 minutes on the remainder, which adds to about 65 minutes. Treat it as an upper bound5
- Which leg carries the tax treatment
- The invoice does. A settlement moves money that was already earned, so the treatment stays on the revenue account the service was billed to4
What you are actually looking at
The remittance says one number. The bank feed shows two credits, neither of which is that number, and the two of them add up to it. Nothing is missing and nothing has been short paid. The funder paid one payment run in two goes, and the ledger has no way of knowing that the second credit belongs to the first.
This is worth separating from the cases that look like it. A short payment leaves a total smaller than the remittance and it stays smaller. A rejection turns up as its own line. A split is the case where the arithmetic still works, and only the timing and the count are different.
Why the second credit has nothing to match against
A batch payment groups the invoices one remittance pays into a single item to reconcile. That is what makes it useful when a remittance arrives whole, and what fails when it does not: the first bank line takes the batch, and the second arrives with the batch already gone. Xero's own article on batch payments could not be read for this page, so that behaviour is described here from the ledger's side rather than quoted.
There's no field on a Xero invoice or batch payment that says 'this remittance was settled across these two bank lines.'5
The same guide describes the ledger's view of the bank feed as each deposit being an independent reconcilable line. That is the whole problem in one sentence. The link between the two credits exists on the remittance the funder sent and nowhere else, so whatever route you take has to put it somewhere a person can read later.
The assumption a split breaks
A reviewer on the Xero App Store describes the state most practices are aiming for: their largest remittance covered 130 invoices and posted as one batch payment, so there was one bank line to reconcile instead of 130. One remittance, one line, minutes rather than an afternoon.
A split deposit breaks that in the smallest possible way. The matching work was already done. What is left is one credit with no home, and the temptation to force it somewhere just to clear the reconcile screen. That is where the damage happens, because a forced match is invisible three months later.
One remittance, two credits, drawn whole
Here is one plan manager remittance covering six invoices, paid as two credits two days apart. The two plates below are the same run, read from the bank's side.
The four routes, and what each leaves behind
The one guide written on this problem lists four ways through it: three ledger routes, and buying a tool that does the matching. The table sets those three beside the clearing account route, because all four rows clear the bank feed and differ only in what a person finds in the ledger a month later. That is the part worth choosing on.
| Route | What you do | What it leaves behind |
|---|---|---|
| Two batch payments | Split the remittance into the invoices each credit covers, and record one batch per credit. | Two batches that no longer match the document the funder sent, so the audit trail is yours rather than theirs. |
| One batch, the difference held | Post the whole remittance against the first credit and hold the shortfall in a holding account until the second lands. | A holding balance that belongs to nobody unless someone reads it weekly. |
| A credit on the funder's contact | Receive each credit as a prepayment or customer credit, then allocate it across invoices. | Allocation work that repeats every cycle, and a stray credit balance when a line is later reversed. |
| A clearing account per funder | Post each invoice payment into the funder's clearing account on the date the funder paid, then clear each bank line against that account. | One balance that is the money claimed and not yet banked, which returns to nil when the last credit lands. |
The route that survives a split without splitting the batch
The fourth route is the one that does not care how many credits arrive, because the invoice side and the bank side stop being the same event. The invoice is closed when the funder paid it. The bank line is cleared when the money lands. Between those two moments the amount sits in the funder's own account, and a split is just a longer gap.
In the allied health canonical template the plan manager settlement posts to account 103, Plan manager clearing, at the BAS excluded tax type, and the rail carries two more components for the cases that are not splits.
| Component | What the template posts | Tax type |
|---|---|---|
| Gross paid | 103, Plan manager clearing | BAS Excluded |
| Short payments | Needs review: Component short_payments needs a fixed account and tax type; original-invoice matching is not supported yet. | Template intent only; choose a supported tax rate before posting |
| Rejected lines | Needs review: Component rejected_lines needs a fixed account and tax type; original-invoice matching is not supported yet. | Template intent only; choose a supported tax rate before posting |
Read that table next to the split. A short payment has its own account, and a rejected line goes back against the invoice it came from. Neither of those is what a split is, which is why a split needs no posting of its own: the money is coming, and the account is already holding it. Setting up a clearing account covers the account type and tax rate settings.
Working the two credits, in order
The evidence is the remittance itself and the payment references on the invoices. Nothing here needs the bank to tell you anything it does not already show.
- Total the remittance and compare it to the two credits added together. If they agree, this is a split rather than a short payment, and the rest is bookkeeping.
- Check the run reference on the remittance, and put it in the payment reference on every payment it covers, so both credits can be traced back to one document later.
- Post the invoice payments into the funder's clearing account, dated on the funder's paid date, not on the bank date.
- Clear the first bank line against that account for the amount the line carries.
- Leave the remainder in the account. It is money the funder has told you it owes and has not finished sending.
- Clear the second bank line the same way when it arrives, and check the balance for that run is back at nil.
If you would rather stay with batch payments, recording a batch deposit for a remittance and reconciling a part payment are the two mechanics that route needs, and splitting a bank statement line covers the case where one credit carries two runs.
Differences that are not a split
Four other shapes get mistaken for a split, and each has its own answer. Ruling them out first saves rebuilding a batch that was correct.
- The credits add to less than the remittance. That is a short payment or a reversal rather than a split, and why the NDIA paid less than you invoiced works through the difference.
- The remittance has more lines than you have invoices. Claim lines are not invoices, and one invoice can appear on the remittance several times.
- One credit covers two funders or two runs. That is the opposite problem, and it is solved by splitting the statement line rather than by splitting the batch.
- The clearing balance stays behind after both credits landed. Something else is in there, and why a clearing account will not clear lists the usual causes.
What the balance tells you between the two credits
The point of holding the remainder in the funder's own account is that the balance means one thing: money this funder has approved and not yet banked. Between a Tuesday credit and a Thursday credit it is a normal working balance. A fortnight later, the same balance is a question for the funder.
That is the report a practice owner actually wants, and it is why the split is worth handling this way rather than by forcing the numbers to agree on the reconcile screen. The NDIS plan managed funder page sets out the lodgement route, the lag and the remittance behind these credits.
Which leg carries the tax treatment
Splitting the money across two credits does not touch the treatment. The invoice carried it already, on the revenue account the service was billed to, and the settlement legs post at the BAS excluded tax type because they move money that was earned when the invoice was raised.
A plan manager paying on a participant's behalf does not change who the supply was made to either. The ATO separates a third party a service is supplied to from a third party that only pays the practitioner on the patient's behalf. Where the third party is paying on the patient's behalf, the supply is still made to the patient, and it is GST free where it falls under the definition of a medical or other health service. Whether a given service falls there is a question for the revenue line, not for the credit that settles it.
What Ledger Map does with two credits
Ledger Map holds one standing map for the practice, approved before anything syncs. Each arriving credit is posted as one balanced document set against the funder's account for the amount that credit carries, leaving one exact match in the bank feed for a person to accept. Two credits produce two document sets and two exact matches.
The remainder stays visible as a balance with the run reference on it rather than being absorbed, and a line the map cannot resolve becomes a question with the options laid out instead of a quiet posting. How it works walks through the map and the approval in front of it.
Questions
Why did one remittance arrive as two bank deposits?
The funder settled the payment run in two goes. The remittance is one document, the payment is not, and no source read for this page documents why a given run is split. Add the two credits together first: if they equal the remittance total, nothing is missing and the work is bookkeeping rather than chasing.
Does Xero link two bank lines to one remittance?
Not by itself. The vendor guide written on this case says there is no field on an invoice or a batch payment recording that a remittance was settled across two bank lines, and that each deposit is an independent reconcilable line. The link lives on the remittance the funder sent, so it has to be written into the payment reference to survive.
Should I split the remittance into two batch payments?
It clears the bank feed, and the cost is that neither batch matches the document the funder sent, so the audit trail becomes yours rather than theirs. Posting the payments into the funder's clearing account and clearing each bank line for the amount it carries leaves the remittance intact and the remainder visible. The practice picks the route.
What happens to my clearing account while half the remittance is unpaid?
It holds the unpaid remainder, which is the point of it. The balance between the two credits is money the funder has approved and not finished sending. In the allied health canonical template a plan manager settlement posts to account 103, Plan manager clearing, at the BAS excluded tax type, and the balance for that run returns to nil when the second credit lands.
How do I tell a split deposit from a short payment?
By the arithmetic, and then by waiting. Add every credit that relates to the run: a split adds up to the remittance total and a short payment does not. If the total is still short after the funder's usual gap between credits, treat it as a short payment or a reversal and go to the invoice that is missing money.
Read next
Sources
Open questions
- Why a funder settles one payment run in two credits is not documented by any source read for this page. The remittance and the practice's own feed are the authority on which credits belong to which run.
- The batch payment cap is disputed between the two vendor guides read on 3 Sep 2026: RemitClear says a single batch cannot cover more than 200 invoices, ToTheCent describes a 50 invoice cap, and the allied health canonical template records 50. The page that owns that question resolves it against Xero directly.
- Xero Central refused an automated fetch on 3 Sep 2026 and returned an empty page, so Xero's own wording on batch payments and on splitting a statement line is cited unverified here and carries no key fact.
- The 65 minute manual estimate is published by the vendor whose product removes the work, so it is carried as an upper bound and attributed rather than stated as a practice average.
- No search result snapshot was captured for this query, so the answer landscape in the brief is inferred from the pages that were fetched rather than from a captured result set.
- No bank narration is published for either credit, so this page names no descriptor string and the matcher learns it from the practice's own feed.
- Bulk payment requests, self help guide for providers, myplace provider portal, June 2025 edition
National Disability Insurance Agency. Retrieved 1 Oct 2025. Source updated June 2025.
primary
- Split payment reconciliation in Xero
RemitClear. Retrieved 3 Sep 2026. Source updated 25 May 2026.
secondary
- The Xero batch payment invoice limit
RemitClear. Retrieved 3 Sep 2026. Source updated 23 Apr 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.