Problems
Stripe payout does not match the invoices
A Stripe payout is a batch, not a payment. Stripe pays out the net of the transactions that settled together, so the fee has already come off each charge, and a refund or a dispute in the same batch takes more out again. The invoices are right and the payout is right. The difference has parts, and each part has a name.
Key facts
- What the bank line is
- One automatic payout, sent from the Stripe balance on the account's payout schedule, and it can include funds from several transactions6
- What a payout is made of
- Balance transactions, because every funds movement in or out of the account creates one, and the batch is found by filtering on the payout id6
- The kinds of transaction inside one
- A charge, a refund, a Stripe fee, and the payout itself6
- Where the fee is taken
- Per transaction, since the itemised report carries a gross, a fee and a net on every row rather than one fee on the payout2
- Payout schedule
- Manual, daily, or weekly and monthly on nominated days, which is an account setting rather than a fixed rule1
- Initial settlement timing for Australia
- Two business days, before whatever schedule the account then runs on1
- The file that names the batch
- The itemised payout reconciliation report, whose payout id groups a batch and whose charge id ties a row back to the payment2
- When that file is ready
- A day of activity is normally available in reports by midday the next day2
- What Stripe says about tax inside the fee
- Withheld tax is sales tax, VAT or GST withheld, and that amount is already included within the fee column2
- Where the charges sit in the allied health template
- Account 107, online payments clearing, at the BAS excluded tax type, holding the gross until the payout8
- Where the fee posts
- Account 604, merchant and claiming fees, at the GST on expenses tax type8
- Why one payment per invoice reaches Xero
- Payments are pushed across only once they are allocated to an invoice in the practice system, so Xero holds the list and the bank holds the total4
Two numbers, and neither of them is wrong
The practice system recorded a payment against each invoice at the amount the patient was charged. The bank shows one credit for a batch of transactions the processor settled together. Both are correct. The useful question is which parts of the difference sit between them.
Cliniko explains one half of it plainly: payments are pushed across to Xero only once they are allocated to an invoice, so Xero ends up holding a list of payments while the bank feed holds a single total. Stripe explains the other half.
Sending funds from your Stripe available balance to your bank account generates a payout object. Automatic payouts occur routinely according to your payout schedule and can include funds from multiple transactions.6
A payout is the net of a list
Stripe's reconciliation guide describes every funds movement in or out of the account as a balance transaction, and the way to see inside a payout is to filter those transactions on the payout id. The types it names in one batch include a charge, a refund, a Stripe fee and the payout itself. That is why matching a payout against an invoice total is the wrong comparison.
The itemised payout reconciliation report is the same list in a file, with a gross, a fee and a net on every row. The fee column sits on the transaction, not on the payout, so a batch covering five consultations is short by five separate fees rather than by one deduction at the end.
The parts a difference can be made of
The allied health canonical template models the Stripe rail as five parts, each with its own posting. Reading a difference against this list is faster than working from the bank line.
| Part of the payout | How it shows up | Posts to |
|---|---|---|
| Gross charges | The payments the practice system already recorded against invoices | 107, Online payments clearing (Stripe) |
| Stripe fees | One fee per charge, taken before the batch is paid out | 604, Merchant and claiming fees |
| Refunds | A negative transaction in whichever batch it settled in, not in the original one | Needs review: Component refunds needs a fixed account and tax type; original-invoice matching is not supported yet. |
| Disputes and chargebacks | The charge pulled back plus a dispute fee, on the date the dispute landed | 604, Merchant and claiming fees |
| Payout rounding | A cents level variance between the parts and the payout total | 604, Merchant and claiming fees |
The refund row retains the template's intention to use the original invoice line's account and tax type. That inheritance is not supported for posting yet, so Ledger Map marks the row Needs attention until a supported fixed destination is reviewed and selected. Treat the retained template explanation as context, not as an automatic refund posting rule.
One payout drawn whole
Here is an illustrative payout at a physiotherapy practice, with the amounts chosen so the arithmetic is visible. Every charge was receipted against its invoice before the payout existed.
Nothing on that plate needs writing off. The clearing account holds the charges from the moment the practice system records them, the payout is a transfer out of it, and the fee leaves on its own expense line.
When the difference is not the fee
A fee explains a small, steady shortfall. It does not explain a payout that is out by a large round amount, or one that arrived on the wrong day, or one that did not arrive at all. Four other things move a payout, and each leaves a different mark.
- The schedule swept more than one day. The payout schedule is an account setting, so a weekly or monthly setting groups several days of charges into one credit and a daily setting does not.
- A refund settled in this batch and belongs to an invoice from an earlier one, which pulls the credit down without touching any invoice in the current batch.
- A dispute landed, which reverses the charge on the date the dispute arrived rather than the date of the consultation, and the canonical templates model a dispute fee alongside the reversal.
- A payout failed and was retried. Stripe reports failed payouts separately and the itemised file names the payout that retried the transactions, so a missing credit can be traced rather than guessed at.
- The payout was manual or instant, in which case Stripe states that it cannot identify which transactions are inside it, and the practice matches those against its own transaction history.
The last one matters most. The itemised file covers automatic payouts, so an account paying itself out on demand is matching by hand whatever it posts to.
The file that settles it
Stripe publishes a report whose stated purpose is this exact match: it helps you match the payouts you receive in your bank account with the batches of payments and other transactions that they relate to. It is the document to work from.
- The payout id groups a batch of transactions into the credit that actually reached the bank.
- The charge id ties a row back to the payment the patient made, which is the field a practice invoicing from its own system matches on.
- The invoice number is filled only where the charge sits against a Stripe Billing invoice, so it is usually empty for a practice that invoices from its practice management system.
- Gross, fee and net appear on every row, so the fee total is read off the file rather than worked out by hand.
- Withheld tax is described as sales tax, VAT or GST withheld, and Stripe says that amount is already included within the fee column.
- The trace id is the reference the bank generates for the payout, which banks use to locate a specific transfer.
One timing point is worth knowing. Stripe computes each day's data daily and says it is normally available in reports by midday the next day, so the bank line can appear before the file that explains it.
The fix that breaks the Xero payment
The tempting repair is to add the processing fee to the invoice so the invoice total equals the payment that was taken. Where the invoice has already gone to Xero and been approved, Xero holds it at its old total and refuses the larger payment. Zanda names the cause directly.
This happens when the payment you are exporting is worth more than the invoice's total already recorded in Xero. The most common cause is a Stripe card processing fee added to the payment after the invoice was already exported and approved in Xero.3
- For an invoice already approved in Xero, export the payment at the invoice's own recorded value, excluding the fee.
- Record the processing fee separately as a bank or processing fee expense, reconciled through the same payments clearing account the card payments run through.
- Going forward, export invoices as late as possible, after the payment and its fee have both been taken, so the invoice and the payment reach Xero at the same total.
Payment exceeds the amount outstanding covers that error on its own, including the invoices that are already stuck.
Where the rail posts across the canonical templates
All three canonical templates carry a Stripe rail and none of them gives the clearing account the same code, because each starts from a different chart of accounts. They agree on the fee account. The charges leg is BAS excluded in every one of them, and the revenue keeps whatever treatment the invoice carried, because a payout moves money that was already earned. Which treatment that is depends on the supply rather than on the rail it settled through.
| Template | Charges post to | Fee posts to | Parts modelled |
|---|---|---|---|
| Allied health by funding source | 107, Online payments clearing (Stripe) | 604, Merchant and claiming fees | 5 |
| NDIS provider, plan managed | 103, Online payments clearing (Stripe) | 604, Merchant and claiming fees | 3 |
| Psychology with booking deposits | 102, Online payments clearing (Stripe) | 604, Merchant and claiming fees | 5 |
A check that names the part
Work in this order and most differences have a name by the third step. The itemised report is the only record of what was inside the batch.
- Download the itemised payout reconciliation file for the period the credit falls in, and filter it to the payout id that matches the bank line.
- Add the gross column for that payout and compare it with the payments the practice system pushed for the same charges. Equal means nothing is missing from the batch.
- Add the fee column. Gross less fee should equal the credit, and if it does, the whole difference is the fee.
- If it does not, read the reporting category column for refunds and disputes, which are the rows that belong to invoices from another day.
- Check whether an earlier payout failed and was retried, because the retried payout carries transactions the practice was looking for in a different week.
- Anything still unexplained beyond the cents the templates treat as rounding is a question for the processor.
The cleaner approach is to run everything through a clearing account, so you reconcile one lump sum instead of chasing individual payments.7
What Ledger Map does with a payout
Ledger Map does not reconcile the bank feed for you. The practice approves one standing map first, and a payout is then posted as one balanced document set built from the charges in that batch and the accounts the map names: the receipts against the clearing account, the fee against the merchant fee expense, and the transfer that leaves one exact match in the bank feed.
Where a line cannot be resolved it becomes a question with the options laid out, rather than a quiet posting to a default account. A payout short by more than its fees is that kind of question. How it works walks through the map and the approval in front of it, the private card and Stripe hub carries the published fee rate and compares the two private rails, and reconciling Stripe payments in Xero is the step by step for the credit itself.
Questions
Why is my Stripe payout less than my invoices?
Because the payout is the net of a batch of transactions rather than a payment against invoices. The processing fee comes off each charge before the batch is paid out, so a payout covering five consultations is short by five fees. A refund or a dispute that settled in the same batch takes it down further, and both belong to invoices from other days.
How do I find out which invoices are inside a Stripe payout?
Use the itemised payout reconciliation report and filter it on the payout id, which groups the transactions that made up the credit. Each row carries a gross, a fee and a net, plus the charge id that ties it back to the payment. The invoice number column is filled only for charges raised against a Stripe Billing invoice, so a practice invoicing from its own system matches on the charge id.
Can I add the Stripe fee to the invoice so the totals agree?
Xero holds an approved invoice at the total it already has and refuses a payment worth more than that, which is the error Zanda attributes to a processing fee added after the invoice was exported. Post the payment at the invoice's own recorded value and put the fee on its own expense line instead.
Why did a payout arrive that has no invoices behind it at all?
Two common reasons. An earlier payout failed and was retried, and the itemised file names the payout that retried those transactions. Or the payout was created manually or as an instant payout, and Stripe states it cannot identify which transactions are included in one of those, so it has to be matched against the account's own transaction history.
Is there GST in the Stripe fee?
Stripe describes the withheld tax column as sales tax, VAT or GST withheld, and says that amount is already included within the fee column. The canonical templates post the fee to account 604, merchant and claiming fees, at the GST on expenses tax type. What that produces on a particular activity statement is a question for the practice's BAS agent on its own figures.
Should the payout be coded straight to revenue?
That records the money twice where the practice system already pushed a payment for each invoice. The charges belong in a clearing account at the BAS excluded tax type, the payout is a transfer out of it, and what is left behind is the money the processor is still holding, which can be checked against the processor's own balance.
Read next
- FundersPrivate patients: card, EFTPOS and Stripe
- Xero how toHow to reconcile Stripe payments in Xero
- ProblemsPayment amount exceeds the amount outstanding
- ProblemsClearing account will not clear in Xero
- Practice systemsCliniko Xero integration: what syncs, what does not
- Practice systemsHalaxy Xero integration: sync, fees, duplicates
- HubProblems
Sources
Open questions
- No google.com.au results page, People also ask list or AI Overview could be observed for this query on 3 Sep 2026. The session's search budget was exhausted and the SERP cache holds no snapshot for this page, so the answer landscape in the brief is assembled from the corpus rather than measured, and what this page adds has not been tested against a named top five.
- This page states no processing fee rate. The rate on a practice's own account is what the arithmetic has to use, and the published Australian rate read on 2 Sep 2026 sits on the private card and Stripe page rather than here.
- Stripe's Australian pricing page was not re-read on 3 Sep 2026. As read on 2 Sep 2026 for the private card and Stripe page, it carried a note that lower pricing applies from 1 Oct 2026 without publishing the new rates.
- The dispute and chargeback posting and the cents level payout rounding line are conventions in the canonical templates rather than sourced rules, and the templates carry that note for a BAS agent themselves.
- The NDIS plan managed template models three parts of the Stripe rail where the other two model five. Whether that is deliberate scope or an omission is a template question rather than a page question.
- Stripe states that withheld tax is already included within the fee column. Whether that accounts for the whole of the GST on the fee for an Australian practice is a question for the practice's BAS agent on its own statements.
- The Zanda troubleshooting article carries no last updated date, so its wording could move without notice.
- No bank narration is published for a payout, so this page names no descriptor string and the matcher learns it from the practice's own feed.
- The worked payout is illustrative. The amounts are chosen so the arithmetic is visible, not taken from a real practice's feed.
- Halaxy batch payments and Xero reconciliation
Time Well Spent Bookkeeping. Retrieved 3 Sep 2026. Source updated 20 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.