Why does my Xero bank rule stop working when nothing has changed on my end?

Bank rules match on exact text from your bank's export — description, payee name, or reference. If your bank changes the format it sends that field, or a supplier updates their payment reference, the rule no longer finds a match. The transaction still imports; it just sits unreconciled. Check your inactive lines regularly and update the rule's condition to match the new wording.

Can Xero's JAX automatically reconcile a Stripe or PayPal payout?

Not reliably. JAX sees one bank line — the net payout amount — but a Stripe or PayPal payout typically bundles dozens of charges, refunds, and platform fees. JAX may suggest matching the line to your largest open invoice, which is plausible but usually wrong. Payout reconciliation requires the platform's settlement report to decompose the line before it can be posted correctly.

What is cash coding in Xero and when should I avoid it?

Cash coding is a bulk-entry grid that lets you assign account codes to multiple unreconciled bank lines at once. Avoid it when a Xero invoice or bill already exists for the transaction — cash coding creates a new transaction rather than matching the existing one, leaving the original bill permanently outstanding and inflating your creditor balance. Use it only on lines with no prior footprint in Xero.

How do I reconcile a partial payment in Xero where a customer has paid less than the invoice total?

In the reconciliation screen, match the bank line to the invoice and enter the amount received rather than the full invoice value. Xero will leave the remaining balance outstanding on the invoice so you can track what is still owed. Do not mark the invoice as fully paid or use cash coding for partial payments — either approach will show the debt as cleared when it is not.

What percentage of bank transactions does Xero typically reconcile automatically?

Xero's internal target for JAX, its AI reconciliation layer, is to auto-reconcile over 80% of bank statement lines at high confidence. The remaining 20% tends to cluster around payout settlements, partial payments, split transactions, and contra entries — cases where the bank line alone does not carry enough information to post correctly without additional context from invoices or platform reports.

Is there a done-for-you option for Xero reconciliation beyond the native bank rules?

Yes. If your month-end regularly involves unreconciled payout lines or edge cases that JAX flags but cannot resolve, a service such as TheBookkeeper.ai fetches settlement data directly from payment platforms, composes the correct Xero postings, and only surfaces the handful of decisions that genuinely need a human — rather than queuing every low-confidence suggestion for you to click through.

How to Automate Bank Reconciliation in Xero

Your Xero bank feed is already doing more than most founders give it credit for. Direct debits line up with bills. Standing orders match invoices. Stripe descriptions hit the bank rules you created in 2023, and roughly eighty percent of the month clicks through without you touching it.

The problem is the other twenty percent. That’s where the rules run dry, the suggested matches mislead, and the cash coding grid starts to feel like a manual job in a slightly more organised spreadsheet. Automation in Xero is real — but every lever Xero gives you has a ceiling, and the ceiling is lower than the marketing suggests.

This post walks through each lever, where it actually stops, and what needs to happen after it does.

The Three Levers Xero Gives You

Xero has three native tools for automating bank reconciliation. They are layered: each one covers a narrower band of transactions, and each one requires more human judgement as you work down the list.

Bank rules

Bank rules are condition-based auto-coders. You define a condition — “if description contains SLACK, code to 7800, VAT rate 20%” — and whenever Xero imports a bank line that matches, the rule pre-fills the transaction. You still click to confirm, but the classification is done. Rules work well on subscriptions, utilities, and recurring supplier payments where the description is stable and the amount is predictable.

Cash coding

Cash coding is a bulk-entry grid. On the bank account screen, alongside the Reconcile tab, sits a Cash Coding tab that presents your unreconciled lines in a spreadsheet view. You can select multiple rows and assign the same account code and VAT rate in a single action. Cash coding is most useful when you have a backlog of similar transactions — daily card receipts, regular supplier payments — and you want to work through them without opening each one individually. The constraint: cash coding creates new transactions against those bank lines, it does not match them against existing invoices or bills. If an invoice is already raised in Xero for a transaction you cash-code, you will end up with a duplicate unless you reconcile them manually afterwards.

Suggested matches and JAX

Suggested matches and JAX are Xero’s automated matching layer. When a bank line imports, Xero’s system looks for an existing invoice, bill, or spend money transaction that matches by amount and approximate date. If it finds one, it surfaces the suggestion in the reconciliation screen. JAX — Xero’s AI reconciliation layer, rolled out in beta to UK organisations on Grow plan and above in 2026 — goes further: it learns from your own reconciliation history and from anonymised patterns across the Xero user base. Xero’s internal target for JAX is to reconcile more than 80% of bank statement lines in real time at high confidence. Lines where confidence is lower still receive a suggestion, but they land on your screen for manual review rather than being auto-posted.

Together, these three tools cover a lot of ground. For a founder with predictable revenue, a small supplier list, and clean payment descriptions, they may handle most of the month. The ceiling arrives when reality gets untidy.

Exactly Where Each Lever Stops

When bank rules go stale

Rules go stale. The most common cause of a bank rule silently failing is a change in the bank’s export schema or a supplier’s payment reference format. A rule that matches on “SLACK.COM/BILL” breaks the day Slack changes to “SLACK TECHNOLOGY INC”. A rule built on exact-match payee breaks when your bank starts exporting the payee in a new format. Xero’s own help articles acknowledge this directly — rules stop working when one of the condition fields changes. The transaction still imports; it just sits unreconciled until someone notices. Nobody notices for three weeks, and by the end of the quarter you have thirty unmatched lines and a growing sense that your books are unreliable.

Rules also cannot reason. A rule that says “if description contains LAPTOP, code to 0020 fixed assets” will fire correctly on a £2,400 capital purchase. It will also fire on a £29 laptop charger that should go to office supplies. The rule doesn’t know the difference. A human would.

Cash coding and duplicate transactions

Cash coding falls over on anything that already has a footprint in Xero. If you have raised a purchase bill for a supplier payment, cash coding that line creates a duplicate transaction rather than clearing the bill. You end up with a reconciled bank line and an outstanding bill sitting permanently in “awaiting payment” — which inflates your apparent creditor balance, distorts your profit and loss, and will be the first thing your accountant queries at year-end. Cash coding is powerful in the right situation; in the wrong one, it quietly corrupts the books.

JAX and payout settlements

Suggested matches and JAX mislead on complex lines. JAX is excellent at matching a £45.00 direct debit to a £45.00 bill for the same contact at roughly the same date. The confidence is high and the auto-reconciliation is correct. The problem is a line like a Shopify payout — a single deposit that represents gross sales minus fees, refunds, and returns across dozens of transactions. Xero sees one bank line. It may suggest matching it to the largest open invoice. That match is technically plausible. It is also wrong. The payout needs to decompose before it can be matched, and JAX has no way to fetch the underlying settlement data from Shopify to understand what the line actually represents.

The same ceiling applies to a partial payment, a contra entry, or any transaction where the bank line amount does not equal any single outstanding item in Xero. JAX surfaces a suggestion; the suggestion may be confidently wrong; the founder clicks confirm and moves on; the books accumulate a slow-burn error.

Where Automation Runs Out

Transaction types that need more context

The 20% that doesn’t click through on its own is not random noise. It clusters around a handful of transaction types that all share one characteristic: the bank line alone does not contain enough information to reconcile correctly.

Payout settlements from Stripe or Shopify require the platform’s settlement report to decompose correctly. A single bank line maps to dozens of underlying transactions — charges, refunds, platform fees — that each need to post to different accounts. See how Stripe payouts specifically need to be handled in Xero for the full breakdown.

Partial payments, where a customer has paid part of an invoice and left a balance, require the bookkeeper to split the receipt correctly and leave the right amount outstanding — not mark the invoice paid and hope no one notices the gap.

Split transactions, where a single payment covers multiple accounts or tax codes, require the bank line to be divided into components that post separately. See what a split transaction actually involves in Xero for why the bank feed treats these as one line when they are really several.

Contra entries, where a supplier is also a customer, need to net off against each other rather than post gross. A rule cannot express that logic.

In each case, the automation stops because the tool runs out of context. It can see the bank line. It cannot see the settlement report, the invoice history, the email thread, or the chart of accounts logic that tells it how to split a complex transaction correctly.

How TheBookkeeper.ai Extends Past the Ceiling

The levers above are genuinely useful for the clean majority of transactions. What TheBookkeeper.ai handles is the rest — the transactions that bank rules, cash coding, and JAX cannot resolve because they require context that lives outside the bank line.

Reading context beyond the bank line

When an unreconciled line lands, TheBookkeeper.ai reads it through Xero’s API alongside your open invoices, bills, chart of accounts, and prior reconciliation decisions. For a payout from a payment processor, it fetches the settlement report directly from the platform API — the structured breakdown of charges, refunds, and fees — rather than trying to infer the decomposition from the single deposit line.

Composing correct postings automatically

It then composes the correct postings: partial invoice settlements, fee journals to the right account code, refund credit notes, split bank reconciliation matches. It posts directly to Xero. You wake up to a reconciled bank statement line, not a queue of suggested matches waiting for a decision.

When the system flags a decision

What it does not post silently is anything where the confidence is genuinely ambiguous. If two invoices have the same amount for the same contact in the same week, the system flags both, shows you the evidence, and asks you to choose. The flag is specific — not “something needs attention” but “invoice 1043 or 1051 — same amount, same client, which settles this charge?” One decision, one tap, done.

The output difference from JAX is meaningful. JAX reconciles the easy 80% automatically. TheBookkeeper.ai handles the hard 20% — the payout decompositions, the partial settlements, the splits — and only surfaces the cases where a human decision is genuinely needed, not where the algorithm ran out of confidence on something it could have resolved with more context.

Worked Example

The scenario

Slate Otter Ltd is a London-based digital agency with fifteen regular clients, billed through Xero on 30-day terms. They take card payments through their Stripe account; a weekly payout typically covers four or five settled invoices, net of fees. On Monday 9 June 2026, a Stripe payout of £6,214.40 settles into their Barclays current account.

The Xero state before

The Barclays feed imports one line:

Date         Description                    Spent    Received     Status
09 Jun 2026  STRIPE PAYMENT ST-RK44...               £6,214.40    Unreconciled

JAX reviews the line and surfaces a suggested match: invoice INV-0892 for £6,200, raised to their largest client. The amount difference is £14.40 — close but not equal. Slate Otter’s founder clicks past the suggestion, unsure whether to accept it. The line stays unreconciled.

What TheBookkeeper.ai does

Detects the unreconciled Stripe line via Xero’s API.
Fetches Stripe payout po_3Rk44... from the Stripe API — returns five settled charges (£3,200, £1,800, £900, £480, £120), platform fees totalling £85.60, and one refund of £200 on a previous charge.
Matches all five charges to open Xero invoices by amount, client reference, and approximate date — all five at high confidence.
Computes the correct split: five invoice settlements + £85.60 fees to account 7900 (payment processing) + £200 refund credit note against the relevant invoice.
Confirms the maths: £6,586.00 gross charges − £85.60 fees − £200 refund = £6,300.40. Wait — the bank line is £6,214.40. There is a £86 gap.
Flags the gap: the Stripe API shows a balance adjustment of £86.00 carried from the prior period’s underpaid payout. TheBookkeeper.ai cannot confirm this without checking the previous payout reconciliation. It posts the five invoice settlements and the fee journal, and raises a flag: “£86.00 carryover from prior payout — confirm whether this closes the prior shortfall or should post separately.”

The Xero state after

Five invoices show paid. The fee journal is posted to 7900. The bank line shows partially reconciled against the invoice settlements, with a £86.00 residual flagged for the founder’s decision. The reconciliation screen shows exactly what remains and why.

What it flagged

One decision: confirm the £86 carryover. The founder checks the prior payout — it was indeed £86 short — and approves the posting with one tap. Total time: under two minutes, on a transaction that JAX’s suggested match would have posted incorrectly.

Takeaway

Xero’s bank rules automate clean, recurring transactions well — but they go stale silently when payment references change, and they cannot reason about edge cases.
Cash coding is a powerful bulk tool for unmatched lines, but creates duplicates if an invoice already exists in Xero for the same transaction.
JAX handles the easy 80% of bank lines at high confidence; it misleads on payout deposits, partial payments, and split transactions where the bank line alone is not enough information to reconcile correctly.
The hard 20% clusters around a handful of transaction types — payout settlements, partial payments, split transactions, contra entries — that all require context from outside the bank line.
Filling the gap means fetching that context, composing the right postings, and only surfacing decisions that genuinely require a human — not every line JAX wasn’t confident about.

Ready to Stop Clicking Through Suggested Matches?

If your month-end currently involves twenty minutes staring at a Stripe payout that JAX almost-but-not-quite matched, we’d like to take that off your hands. Get on the waitlist and we’ll be in touch when we open the next cohort of UK Xero users.

Sources: