Can a Xero bank rule allocate a deposit to invoices?

No. A rule codes a statement line: the contact, the account and the tax rate. Deciding which invoices a deposit paid is done against the funder's own report, in the practice system or through Find and Match, and a rule has no access to that report.

What tax rate should a bank rule use for a funder deposit?

BAS Excluded. Every clearing account in the canonical templates carries that rate, and the settlement account method sets the same rate when the deposit is coded by hand. The GST treatment of the income belongs to the revenue leg on the invoice, which was decided when the service was billed.

Should I key the rule on the bank feed description?

Key it on wording you have read on your own settled deposits, across several runs, rather than on a string from an article. Bank feed narration for funder rails is not confirmed by any primary source in our research files, so a rule keyed on a guess either sits idle or fires on the wrong line.

What happens when the deposit comes in short?

The rule codes whatever arrived, because it reads the statement line and nothing else. The shortfall shows up as a clearing balance that will not return to nil, which is the signal to go back to the funder's exception report and find the claims that were declined.

Does a bank rule work for a Stripe payout?

A Stripe payout arrives net of fees, so the amount that lands and the amount invoiced differ by the fee. The canonical template splits that deposit into a gross leg on the clearing account and a fee leg on a merchant fee expense account. Whether one bank rule can make that split was not confirmed here, so code those payouts with the payout report in front of you.

Xero how to

Xero bank rules for funder deposits

A Xero bank rule can code a funder deposit. It cannot allocate it. Set one rule per funder that posts the whole bank line to that funder's clearing account at BAS Excluded, with conditions read off your own feed rather than a borrowed descriptor. Which invoices the deposit paid is settled against the funder's report in your practice system, before the bank line arrives.

Key facts

What a rule sets: The contact and the account on a statement line, on the bank accounts you point it at³
What a rule leaves alone: Which invoices the deposit paid, which is settled against the funder's report⁴
Tax rate on the coded line: BAS Excluded, the rate every clearing account carries in the canonical templates⁷
Where the conditions come from: Wording you read off your own settled deposits, not a string from an article³
The one element a vendor supports: The Medicare payment run number, which the payment report says corresponds to the payment identifier Medicare put on the deposit⁶
The object a rule produces: A receive money transaction, the same object the settlement account method codes by hand⁵
Where a rule sits in Xero: One of the four methods Xero names behind its JAX automation, beside a match and two kinds of suggestion¹

What a bank rule can do to a funder deposit

Xero describes a bank rule as a way to treat groups of similar transactions the same way every time, and names a rule as one of the four methods behind its JAX automation, beside a match against a record already in Xero, memory of how you coded similar lines and a prediction drawn from how other Xero users coded theirs. On a funder deposit the first distinction is the whole answer. The rule owns the coding. The match owns the allocation.

A funder deposit is one credit covering many claims. Its coding is the same every run: the same contact, the same clearing account, the same tax rate. Its allocation changes every run, because a different set of claims was paid and some of them were not paid at all. A rule fits the first half and does not fit the second half.

One funder deposit, split into the part a rule codes and the part it does not⁴⁷

Piece of work	Where it happens	Why there
Choosing the account and tax rate for the bank line	The bank rule, set once per funder	The coding is identical every run, which is what a rule is for
Choosing which invoices the deposit paid	The practice system, against the funder's report	The answer changes every run and comes off a report the bank line does not carry
Dating the receipt	The practice system, on the funder's paid date	Aged receivables and cash basis GST both read the payment date
Handling a claim the funder declined	The exception queue, before the deposit is coded	A rule codes the deposit whatever arrived, so a declined claim leaves a residue behind

Build the conditions from your own feed

The tempting shortcut is to copy a bank feed description out of an article and key the rule on it. Our research files flag the narration for Medicare, DVA, NDIA, HICAPS, Tyro and WorkCover Queensland as unconfirmed from any primary source, and the EFTPOS clearing account in the canonical allied health template carries the same note written against it. So this page prints no descriptor string, and a rule should not be built on one you have not read yourself.

Open the last few settled deposits from that funder in the reconcile tab and read what the feed actually prints, rather than what you remember it printing.
Take the part that repeats across all of them. The parts that change between runs are data, not conditions.
Leave the amount out. A funder deposit is a different figure every run, so an amount condition is the fastest way to build a rule that does not fire.
Check the same wording does not also appear on a refund, a fee direct debit or a transfer, because a rule cannot tell those apart from a settlement.

One element does have vendor support. Zanda's payment report documentation says the run number on a Medicare payment report corresponds to the payment identifier Medicare put on the deposit into your bank account, which is why the run number is worth carrying into the payment reference when claims are receipted. That is a number you look up on your own report, not a string this page can hand you.

What to set on the rule

SimpleClinic's settlement account method is the closest published pattern to a funder deposit, and it teaches the coding by hand first: pick a contact, pick the settlement account in the what field, confirm the tax rate. The rule is the same three choices, made once. It then names the bank accounts the rule may act on.

Contact: the funder, so the clearing account's transactions read as a funder ledger rather than as a pile of unnamed credits.
Account: that funder's clearing account, which in the canonical templates is a bank type asset account.
Tax rate: BAS Excluded. The clearing leg carries no GST consequence of its own, because the supply was already recorded on the invoice.
Bank accounts: the operating account only, so a deposit landing anywhere else still gets a person's attention.

The GST treatment of the income sits on the revenue leg, on the invoice, decided by the service and the practitioner rather than by who paid. A deposit coded here moves money between two asset accounts and changes no GST figure, which is exactly why the rate is set the way it is.

One rule per funder, one clearing account per rail

A single rule pointing at one shared clearing account undoes the reason for having the account. The point of the pattern is that each funder's balance is a list of claims that funder has approved but not yet banked, and a shared account mixes those lists together. The allied health canonical template carries a separate account per rail, codes 100 to 109, each a bank type asset account at the BAS Excluded rate.

The account each rule codes to, from the allied health canonical template, leaving out the two rails that settle net of a fee⁷

Rail	Clearing account
Medicare bulk bill	100 Medicare clearing
DVA	101 DVA clearing
NDIA	102 NDIA clearing
Plan managers	103 Plan manager clearing
HICAPS	104 HICAPS clearing
Tyro Health	105 Tyro Health clearing
WorkCover Queensland	108 WorkCover clearing
Insurers paying direct	109 Insurer clearing (TAC, CTP, icare direct)

If the accounts are not there yet, that is a different job: see set up a clearing account first, and reconcile a clearing account for the month end read.

What the ledger looks like on either side of the rule

The change a rule makes is narrow and worth seeing plainly. It does not close an invoice, it does not date a receipt, and it does not decide a tax treatment for revenue. It removes one repeated decision from the reconcile screen and makes that decision once rather than on every deposit.

Plate 1The same funder deposit before and after a rule takes over the coding.

Where a rule quietly goes wrong

A rule is confident. It codes what arrived and moves on, and every failure mode below produces a plausible looking reconciled line rather than an error.

The deposit came in short because whole claims were declined. The rule codes the amount that arrived, and the difference sits in the clearing balance until somebody reads the funder's exception report.
The deposit covers two payee provider numbers or two locations. The rule codes both the same way, which is correct, but the allocation has to be grouped the way the funder paid.
The wording also appears on a refund or a clawback. The rule codes a debit into an account that should only be holding credits.
The rule was applied to every bank account. A deposit into a savings or trust account is coded as though it were the operating account.
Nobody receipted the claims. The clearing account swings negative, which is a real signal that the rule has now hidden.

The deposits to leave off a rule

One rail does not settle the gross amount. The canonical template gives the Stripe payout a fee leg of its own, coded to a merchant fee expense account, because Stripe takes its cut before the money lands. Coding the whole line to a clearing account then leaves that account short by the fee on every payout. EFTPOS is the other shape in the same template: the settlement lands gross and the merchant fee arrives as its own monthly debit, a timing the template asks you to confirm against the practice's merchant agreement.

Whether one rule can split a single statement line across the clearing account and the fee account is not settled by anything read for this page. Either way the Stripe fee is a different amount and a different share on every payout, so code those with the payout report open rather than from a rule. The rails the template settles gross are the ones the rule fits: Medicare, DVA, NDIA, plan managers, HICAPS, Tyro Health, EFTPOS, WorkCover and insurers paying direct.

The order of work that keeps the rule honest

Receipt each claim in the practice system on the date the funder paid it, into that funder's clearing account, with the run or batch reference on the payment.
Let those payments sync into Xero, where they sit as debits against the clearing account.
When the bank line arrives, the rule codes it to the same clearing account and the balance nets off.
Where the practice system posts payments into the bank account instead, the bank line is tied to them with Find and Match and a rule is not the right instrument.
Read the clearing balance at month end and chase whatever will not clear.

Cliniko's integration guidance does not reach for a rule at all and sends the reader to Find and Match, which is the right answer for the pattern it describes. The two answers differ because the payment landed in a different account, not because one vendor is wrong.

Checking the rule worked

Give a new rule a fortnight before trusting it. Read the coded lines against the funder's own report, confirm the contact and account came out as intended, and confirm no line was coded that should have gone somewhere else. A rule that fires on the wrong line is easier to spot in the first two weeks than in the following year.

The funder pages carry what each report holds and when it turns up, which is what the allocation half of the work depends on. Medicare bulk bill is the worked one.

What Ledger Map does instead

Ledger Map works the other side of the same line. It reads the funder's report, posts one balanced document set per deposit against the standing map the practice approved, and leaves one exact match waiting in the bank feed. The coding and the allocation both come from the map rather than from a rule keyed on wording.

Anything the map cannot resolve becomes a question with the options laid out, rather than a silent posting. A bank rule has no equivalent, which is the honest reason to keep its job small.

Questions

Can a Xero bank rule allocate a deposit to invoices?
No. A rule codes a statement line: the contact, the account and the tax rate. Deciding which invoices a deposit paid is done against the funder's own report, in the practice system or through Find and Match, and a rule has no access to that report.
What tax rate should a bank rule use for a funder deposit?
BAS Excluded. Every clearing account in the canonical templates carries that rate, and the settlement account method sets the same rate when the deposit is coded by hand. The GST treatment of the income belongs to the revenue leg on the invoice, which was decided when the service was billed.
Should I key the rule on the bank feed description?
Key it on wording you have read on your own settled deposits, across several runs, rather than on a string from an article. Bank feed narration for funder rails is not confirmed by any primary source in our research files, so a rule keyed on a guess either sits idle or fires on the wrong line.
What happens when the deposit comes in short?
The rule codes whatever arrived, because it reads the statement line and nothing else. The shortfall shows up as a clearing balance that will not return to nil, which is the signal to go back to the funder's exception report and find the claims that were declined.
Does a bank rule work for a Stripe payout?
A Stripe payout arrives net of fees, so the amount that lands and the amount invoiced differ by the fee. The canonical template splits that deposit into a gross leg on the clearing account and a fee leg on a merchant fee expense account. Whether one bank rule can make that split was not confirmed here, so code those payouts with the payout report in front of you.

Sources

Open questions

Xero Central settles where a bank rule is created and where a rule can be started from a statement line. The exact set of conditions a rule matches on, and the exact set of fields it sets, are not stated here: those claims rest on Xero's own product page and on a vendor method article.
Whether one bank rule can split a single statement line across a clearing account and a merchant fee expense line, and on what basis, was not confirmed. That is why netted rails are left off the rule here rather than handled by it.
Bank feed narration for every funder rail is unconfirmed in our research files, so no descriptor string appears on this page and the conditions are built from the reader's own feed.
The current top results and the live AI answer for this query were not observed, in drafting or in review, because the session's web search budget was spent both times. The differentiator rests on the vendor articles that were read rather than on the ranked set.

Bank reconciliation software
Xero. Retrieved 3 Sep 2026.
primary
Create a bank rule
Xero Central. Retrieved 4 Sep 2026.
primary
Reconciling in Xero using a settlement account
SimpleClinic. Retrieved 3 Sep 2026. Source updated 6 Jan 2021.
secondary
Reconcile in Xero when using the Cliniko integration
Cliniko. Retrieved 3 Sep 2026. Source updated 28 Jul 2026.
secondary
Exporting to Xero
Zanda Health. Retrieved 3 Sep 2026.
secondary
Medicare and DVA payment reports
Zanda Health. Retrieved 3 Sep 2026.
secondary
Allied health by funding source, the canonical template
Ledger Map. Retrieved 3 Sep 2026.
primary
Account Transactions report
Xero Central. Retrieved 4 Sep 2026.
primary
Reconcile your bank account
Xero Central. Retrieved 4 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.

Start your map

Every practice starts from a template. Nothing posts until the map is approved.