Why does my Xero bank rule stop working when my supplier changes their bank?

Bank rules match on the exact description text in your bank feed. When a supplier changes their bank account, the payment reference or description typically changes too, and your rule no longer recognises it. The transaction sits unreconciled with no alert. You need to update the rule's condition to match the new description, or set it to suggest mode so missed lines are visible on your reconciliation screen.

Can Xero automatically match a payment that covers two separate invoices?

Not via bank rules — a rule can only code a transaction to an account, not match it against open invoices. JAX (Xero's automatic reconciliation feature) can suggest a Find & Match if it recognises the contact from your history. However, for a payment that exactly spans two invoices, you still need to confirm the split on the reconciliation screen. Partial settlements remain a manual step in standard Xero.

What is JAX in Xero and is it the same as a bank rule?

No. JAX is Xero's machine-learning reconciliation layer, launched in 2025. Unlike bank rules — which fire only when description text matches a condition you defined — JAX predicts matches using your reconciliation history and patterns across Xero's user base. It handles clean, routine lines automatically and surfaces uncertain ones for review. Bank rules are deterministic; JAX learns and improves over time.

What should I do when Xero auto-reconciles a transaction incorrectly?

Go to the Reconciled page in Xero, locate the line, and undo the reconciliation. Then reconcile it manually using Find & Match or by creating the correct transaction. If the error came from a bank rule on auto-apply, review that rule's conditions and either tighten them or switch to suggest mode so similar lines need your approval before posting.

How do I handle a Stripe payout in Xero when the amount doesn't match any invoice?

Stripe payouts are net of fees and often consolidate multiple transactions, so they rarely match a single invoice directly. The safest approach is to reconcile the gross receipts and fees as separate line items — either manually via a split or by using a clearing account. JAX may suggest a partial match from history, but complex payouts with multiple underlying transactions typically need manual allocation or a bookkeeper to decompose them correctly.

When does it make sense to use an AI bookkeeping service instead of relying on Xero's built-in tools?

Xero's bank rules and JAX handle the majority of straightforward transactions well. Where they fall short is the exception pile — partial settlements, payout decompositions, payments with ambiguous references, and anything requiring context from invoices or correspondence. If those exceptions accumulate weekly and take significant time to resolve, a service that reasons across your full Xero data and settles invoices automatically — such as TheBookkeeper.ai — addresses exactly that gap.

Xero Bank Rules vs AI: Which Should You Trust?

You set up a bank rule for your office rent six months ago. £1,850 on the last working day of every month, description contains “LANDLORD”, code to 7200 Rent, 20% VAT, auto-apply. It worked perfectly. Then your landlord changed their bank account and the description on the line became “BACS PAYMENT REF TG881”. The rule sat there, doing nothing, while three months of rent piled up unreconciled — and you found it in January when your accountant asked why your rent expense looked £5,550 light.

Bank rules are not set-and-forget. They are deterministic pattern matchers: they do exactly what you told them, on the exact description you trained them on, and they stop the moment that description changes. For a business with a growing, messy transaction list, that’s both their strength and their quiet liability.

This post runs a fair comparison: bank rules versus AI-based reconciliation in Xero. Not a hit piece on either — an honest account of what each is actually good for, where each breaks, and how to combine them without creating a pile of false confidence.

What Xero Bank Rules Actually Do

How conditions and modes work

A Xero bank rule is a conditional statement applied to incoming bank feed lines. You define one or more conditions — description contains a text string, amount falls within a range, source account matches — and Xero either suggests or auto-applies a category, contact, and tax rate when the conditions fire.

There are two application modes. Suggest mode pre-fills the reconciliation form but leaves the line on your reconciliation screen for you to approve. Auto-apply completes the reconciliation automatically — you never see the line. Both modes are useful; auto-apply on a well-tested rule genuinely removes manual work. The risk is the same in both: the rule fires on description text, and description text changes.

Rule logic and hard limits

Rules support AND/OR logic across multiple fields — payee, description, reference, analysis code. You can set amount ranges rather than exact amounts, which handles modest variation. What rules cannot do: they cannot reason about context outside the bank line, they cannot match a line to an existing invoice, and they cannot handle a line that needs to be split across two or more accounting events. A rule codes a transaction; it cannot settle one.

Rule priority order

Xero processes rules in priority order — rule 1 fires before rule 2. If two rules could match the same line, priority determines which wins. This matters more than most founders realise. A broad rule (“any line mentioning ‘card’”) set to auto-apply and ranked above a specific rule (“Monzo card fee”) will silently swallow the specific case.

Where Bank Rules Break

The honest list:

Description drift

Banks and payment processors change transaction descriptions routinely, and they do not warn you. “STRIPE PAYMENT ST-” becomes “STRIPE TECH INC”, or the reference gets truncated, or your provider consolidates daily settlements into weekly ones. The rule doesn’t learn — it just stops firing. If you’re on auto-apply, the transaction sits unreconciled but nothing alerts you unless you’re actively monitoring the unreconciled pile.

Partial payments

A bank rule can code a transaction to an account. It cannot match it to an open invoice, and it certainly cannot handle a payment that partially settles one invoice and is the full settlement of another. Xero supports recording part payments during reconciliation — but that’s a manual process on the reconciliation screen. A rule won’t get you there.

Split transactions

You receive one payment from a customer that covers their current invoice plus a deposit against a future one. That’s two accounting events in one bank line. Xero’s split function handles this in the UI — you click the arrow on the line and allocate portions manually. A bank rule cannot trigger a split. It can only map the whole line to one account.

Amount variation

Exact-amount rules break the moment the amount changes — even legitimately. A supplier invoice that varies month to month (utilities, ad spend, usage-based SaaS) will only match a range rule if you’ve anticipated the bounds correctly. Too wide a range and you risk false matches. Too narrow and the rule misses.

Context outside Xero

A payment arrives and you need to know what it was for. The description says “FASTER PAYMENT REF 881”, the amount is £3,400, and you have three open invoices in that ballpark. A bank rule has no way to look at your invoice list, your email thread, or your CRM to work out which one this settles. It can only act on what the bank line itself contains.

What JAX Does — and Where It Stops

How JAX predicts matches

Xero’s automatic reconciliation layer, JAX, is meaningfully more capable than a bank rule. Launched in beta in November 2025 and now live, JAX matches statement lines against existing Xero transactions using predictions drawn from your own reconciliation history and from patterns across anonymised Xero user data. Xero’s stated target is for JAX to handle more than 80% of bank statement lines automatically, with a CPO-level ambition to reach 90% of routine bookkeeping tasks in 2026.

For clean lines — a direct debit, a standing order, a single invoice paid in full by BACS — JAX works well. It learns your patterns, improves over time, and leaves anything below its confidence threshold on your reconciliation screen for manual review. It provides an audit trail via a new Reconciled page showing what it matched and why.

The 20% JAX leaves for you

Where JAX stops is the same place bank rules stop, just reached more gracefully. A Stripe payout net of fees, a payment that partially covers two invoices, a line that needs context from your email or CRM to classify correctly — JAX will either surface these for manual review or, in the worst case, match them at lower confidence without signalling the uncertainty clearly enough. The 80% it handles is genuinely handled. The 20% it doesn’t is exactly the expensive, time-consuming 20%.

JAX is also still a tool you check, not a service that runs. You review what it reconciled, correct anything it got wrong, and resolve the lines it left for you. The operator is still in the loop on every exception.

What AI Reconciliation Tools Can Do Differently

Reasoning from context, not just pattern matching

AI-based reconciliation — the category TheBookkeeper.ai occupies — reasons about context rather than matching patterns. The distinction matters.

A bank rule sees a description string and fires or doesn’t. JAX sees a description string plus your history and makes a prediction. An AI reconciliation system sees the description string, fetches your open invoice list, cross-references the contact name, checks whether the amount matches any combination of open items, and — if needed — pulls in context from email or CRM to resolve ambiguity. The output isn’t a category suggestion. It’s a reconciled transaction, with the specific invoice settled, the right tax posted, and a note written into the journal narration explaining the reasoning.

That difference matters most on four transaction types: partial settlements, payout decompositions (Stripe, Shopify, GoCardless), contra entries, and anything where the decision turns on information that lives outside Xero.

Confident mismatches and the review layer

The honest caveat: AI reconciliation can be confidently wrong. A rule that doesn’t fire is a visible miss — the line sits unreconciled and you see it. An AI system that misfires posts to Xero with apparent confidence, which can be harder to catch. This is why the output matters: a well-built AI reconciliation service flags its uncertain matches separately from its high-confidence ones, and writes its reasoning into the journal narration so a human can audit the logic rather than just the outcome.

The practical implication: AI reconciliation doesn’t eliminate the need for a review layer. It changes what the review layer looks at — from “match all these lines” to “check these three flagged exceptions and confirm the rest.”

Worked Example: Where Each Approach Lands

Amber Fox Consulting Ltd is a UK digital agency doing about £380k per year, billing clients on fixed-price project milestones via BACS. Here’s a typical month-end line that tests all three approaches.

The scenario: a two-invoice BACS payment

The scenario. A £6,400 BACS payment arrives from a client, Teal Badger Media Ltd, description: “FASTER PMT TBML REF 024”. Amber Fox has two open invoices for this client — invoice 1089 for £4,200 (overdue by 12 days) and invoice 1091 for £2,200 (due today). Together they sum to exactly £6,400.

Xero state before.

Date         Description               Received    Status
30 Jun 2026  FASTER PMT TBML REF 024   £6,400.00   Unreconciled

Two invoices in Awaiting Payment: INV-1089 £4,200, INV-1091 £2,200.

How each tool handles it

Bank rule response. Amber Fox has a bank rule: “If description contains ‘TBML’, code to 4000 Sales, 20% VAT, contact Teal Badger Media, suggest mode.” The rule fires and pre-fills the reconciliation form. But it codes the £6,400 as a new transaction — it doesn’t settle the two open invoices. If Amber Fox approves the suggestion without switching to Find & Match, both invoices remain open as unpaid, and the £6,400 posts as a duplicate revenue entry. The rule did its job; the operator still needs to recognise this is a Find & Match scenario, not a code-and-create one.

JAX response. JAX, drawing on reconciliation history, recognises that previous TBML payments have been matched to invoices for this contact. It suggests a Find & Match against Teal Badger Media Ltd’s open invoices and highlights INV-1089 and INV-1091 as probable matches. The operator sees this on the reconciliation screen, confirms the match, and the line reconciles cleanly. JAX handles this well precisely because it’s a complete settlement of two invoices — no partial amounts, no splits.

AI reconciliation response. TheBookkeeper.ai sees the unreconciled line, fetches the open invoice list, and identifies the two invoices summing to £6,400 exactly. It posts a split match: £4,200 against INV-1089 (marked paid, overdue flag cleared) and £2,200 against INV-1091 (marked paid). Both invoices close. The bank line is reconciled. The journal narration reads: “BACS from Teal Badger Media Ltd — settles INV-1089 (£4,200) and INV-1091 (£2,200). Matched by invoice total + contact.” No operator action required unless the contact had three open invoices in the same ballpark, in which case that case is flagged for confirmation.

What this illustrates. The bank rule does useful pre-filling but cannot distinguish between “create a new transaction” and “settle existing invoices” — a conceptual gap that costs real work when it fires wrong. JAX handles the clean case well. AI reconciliation handles both the clean case and the partial-settlement variant (if the £6,400 had only partially covered one invoice) and does it without operator input.

Takeaway

Xero bank rules are fast and deterministic. They work well for recurring, stable transactions — standing orders, monthly subscriptions, predictable supplier payments. They break when the description drifts, when the amount varies, or when the line needs to settle an existing invoice rather than create a new one.
JAX handles the easy 80% with genuine capability and learns from your reconciliation history. The 20% it surfaces for review is the expensive part — partial settlements, complex payouts, ambiguous references.
AI reconciliation systems reason about context rather than matching patterns. They can settle invoices, handle splits, and pull in information from outside Xero. The risk is confident mismatches — which is why a well-built system flags uncertain decisions separately and writes its reasoning into the journal narration.
Bank rules and JAX belong in every Xero setup. Use bank rules for the stable, high-volume, low-complexity lines. Let JAX handle the clean automatic matches. Reserve AI reconciliation for the edge cases that cost a bookkeeper thirty minutes each.
The question is not “rules or AI?” — it’s “which work belongs to which layer, and who is responsible for the exceptions each layer surfaces?”

Get the exceptions handled

If your reconciliation screen is clear on Monday but has a pile of unresolved edge cases by Friday, that’s the 20% doing its work. Get on the waitlist if you want those handled overnight, not in your Saturday morning catch-up.

Sources: