How to reconcile Stripe payments in Xero, without a bank rule

Why the payout never matches the invoices

The Stripe Xero integration does exactly what it says: it brings the money across. What it cannot do is decide how the money should be recorded, and that is where files go wrong.

You invoice a customer for the full amount. Stripe collects the full amount, takes its fee, and pays you the difference. Several days of transactions arrive as one deposit.

So a single line hits your bank feed that does not correspond to any invoice, or to any group of invoices, because it is a batch net of fees. Trying to reconcile that line directly against invoices is the point at which most files go wrong, and the wrong fix is usually a bank rule that makes the line disappear.

There are three amounts in play and they are all different: what the customer was invoiced, what Stripe collected, and what landed in your bank. A file that only ever records the third one has quietly lost the first two.

The mistake that costs the most

Coding the payout straight to income.

It reconciles, the bank balance is right, and the file looks clean. What it has actually done is understate your revenue by the fees and understate your expenses by exactly the same amount. Profit happens to come out right, which is why nobody catches it.

Everything derived from those two figures is now wrong. Your revenue line is understated, so any percentage you calculate from it is off. Your merchant fees are invisible, so you cannot see what payment processing costs you or whether it is growing. And if the fee has GST treatment, the GST on purchases has been understated too, which means a BAS figure is wrong rather than merely a management report.

The rule that keeps you out of trouble: the fee is an expense you have incurred. It is not a reduction in what you earned.

What a correct treatment looks like

The shape is always the same, whatever tool you use to get there:

1. Record the income gross. The invoice is the full amount the customer was charged.
2. Record the fee as an expense, to a merchant fees or payment processing account, in the period it was charged.
3. Reconcile the payout as the net of the two, so the bank line is explained by the gross income less the fee rather than being income in its own right.

Which mechanism produces that, whether a Stripe feed, a clearing account, or a third party tool that creates the fee entries for you, is a decision about your volume and how much manual handling you want. The accounting outcome should be identical either way, and if a proposed setup does not produce it, that is the test it has failed.

A clearing account is usually worth the extra step. Payments in, fees out, payout across. When something does not balance, the clearing account tells you which of the three amounts is wrong rather than leaving you to guess.

The cases that need their own decision

Refunds. A refunded payment is not a negative sale, and the fee treatment on a refund is not always symmetrical with the original charge. Left to a bank rule these silently distort both income and fees.

Chargebacks. These arrive with their own fee and often in a later period than the sale. Treating a chargeback as a refund loses the fee and misdates the reversal.

Payouts that straddle a period end. Money collected in one month lands in the next. If income is recognised on the payout rather than on the invoice, revenue moves between periods, and at a year end that becomes a real problem rather than a presentational one.

Multi-currency. If Stripe converts, there is a foreign exchange difference that belongs in its own account. Foreign exchange gains and losses are one of the few profit and loss items that are not GST or GST Free, so this is worth setting up deliberately.

Subscriptions and failed payments. Retries and dunning generate activity that is not new revenue. A rule matching on amount will happily count some of it twice.

Where bank rules help and where they hurt

A bank rule is a good way to handle something that is genuinely identical every time. A Stripe payout is not identical every time: the composition changes with every batch.

A rule that codes the whole payout to one account will reconcile every line and be wrong on every line. It also removes the signal, because the transaction no longer looks like it needs attention. Rules that automate a decision you should be making are worse than no rules, because a file full of them looks maintained.

How to check your own file in ten minutes

1. Pick a Stripe payout and find it in the bank feed. Can you explain the exact amount from your invoices and fees?
2. Run your profit and loss for the last quarter. Is there a merchant fees figure, and is it plausible?
3. Compare total income in Xero with total collected in Stripe for the same period. A difference in roughly the size of the fees means income is being recorded net.
4. Check the GST treatment on the fee account and whether it matches how the fee is actually charged.

If step two comes back empty or step three shows a gap, the fees are being netted off, and the fix is easier the sooner it is done because it is a coding change now and a restatement later.

If the numbers do not line up

Sorting out how the payouts, fees and refunds should flow is usually one session rather than a project. See Stripe and Xero integration for how we set that up, or Book a Call Today and we will look at the file with you.