Xero bank rules: what they do, how to build one, and where they stop

What a bank rule does, and what it never does

A bank rule sits between a statement line arriving in Xero and you coding it. You describe the line with a set of conditions, you set the treatment you want applied, and from then on anything matching turns up in the reconcile screen already carrying the contact, the account code, the tax rate and whatever description you told it to use. You still click OK, so nothing reaches the ledger without a person looking at it, but the typing is gone and so is the risk of coding the same recurring supplier three different ways across three months.

Xero gives you three kinds: spend money rules for payments out, receive money rules for money in, and transfer rules for movements between two accounts you hold. That split matters more than it looks, because a rule only ever sees lines going in its own direction, so a supplier you both pay and get refunds from needs two rules rather than one clever one. You can create a rule from Accounting, then Bank accounts, then Bank rules, but the faster route is to open a real example in the reconcile screen and build the rule from the line itself, because Xero then pre-fills the conditions from text the bank actually sent rather than the text you assume it sends.

The things a rule won't do are worth knowing just as well, because most of the frustration with rules comes from expecting one of them:

• It won't create a transaction. A rule only ever acts on a statement line that's already sitting in Xero, waiting to be reconciled.
• It won't reconcile without you. The coded suggestion appears against the line and somebody still approves it.
• It won't go and get anything. Rules have no connection to the feed and never talk to your bank.
• It won't revisit history. Change a rule today and the lines you reconciled last month stay exactly as they were coded, though unreconciled lines still sitting in the screen will pick the change up next time you look at them.

Conditions, and the contains match that gets people into trouble

A rule's conditions test the fields the statement line carries, so typically the payee, the description, the reference and the amount, and you choose whether all of them have to match or any of them. Each condition gets an operator, and the text ones are equals, contains, starts with and ends with, while an amount condition tests a figure: equal to, greater than or less than. That's a small toolkit, and nearly every bad rule in the wild is built out of one contains condition and nothing else.

The classic version is a spend money rule that codes anything whose description contains a platform's name straight to a single expense account. It works beautifully for a month, then a laptop bought through the same platform lands in monthly software costs, or a payment to a supplier who happens to bill through it gets the wrong contact and the wrong tax rate, and because the line arrives pre-coded it reads as reviewed. Somebody clicks OK at speed, and the mistake gets found at year end by an accountant who then has to unpick a hundred lines rather than one.

Narrowing a rule costs about a minute and it's the whole difference between a shortcut and a liability:

• Keep all conditions matching rather than any. A rule set to any is a rule that fires on a coincidence.
• Pair a text condition with an amount condition wherever the figure is stable, so a subscription rule matches the name and the price rather than the name alone.
• Use starts with instead of contains when the useful part of the payee text sits at the front, which is usually the case with reference prefixes and card descriptors.
• Scope the rule to the bank account the payee actually appears in, rather than leaving it running across every account in the org.
• Name the rule so the next person can tell what it does from the list, because in two years somebody will be deciding whether it's safe to delete.

Building one from a real line

1. Find an actual example of the transaction in the reconcile screen and create the rule from that line, so the conditions start from the bank's real text.
2. Cut the pre-filled conditions down, because Xero starts you with more of them than you need and every extra one is another way for next month's line to miss the rule entirely.
3. Add the condition that makes it safe rather than the one that makes it match, which is usually an amount test or a tighter starts with.
4. Set the contact, and set it deliberately, because a rule left to take the contact from the statement text is also the thing quietly creating contact records.
5. Allocate the line to an account code, choosing a fixed value, a percentage or the remainder depending on how the payment is actually made up.
6. Save it, then wait for the next matching line and look at it properly before you trust the rule with anything.

The allocation options are the part worth slowing down on. Splitting a line by fixed value or percentage is genuinely useful for a payment that always carries a known fee, and it's also the setting that does the most damage later, because when the underlying amount changes the remainder line absorbs the difference silently and the coding stays green while the numbers drift.

Before you blame the rule, check what actually arrived

A rule that looks like it's stopped working usually hasn't. Either the line it was written for never arrived, or it arrived twice and the second copy got coded as cheerfully as the first, or it arrived with different text because the bank changed its descriptor. Those are three different problems and none of them is fixed by rewriting conditions, so it's worth two minutes with the account itself before you touch the rule.

1. 1View bank statements and bank statement lines

   What Xero actually received for the account, line by line. It's the only reliable way to tell a rule that missed from a transaction that was never delivered, and it takes the guesswork out of the rest of the checks.

2. 2Check if your bank feed is late

   The per-account view, reached by opening the Accounting menu, selecting Bank accounts, clicking the menu icon next to the account and choosing View Status Updates. Feed transactions arrive roughly every twelve hours and a feed can be refreshed by hand, so an account a few hours behind is normal and an account weeks behind is not.

3. 3Find and remove duplicate bank statement lines

   Xero's documented route for finding statement lines that arrived twice, and for getting rid of them. Worth running whenever rules are involved, because a rule codes both copies of a duplicate without hesitating, and a coded duplicate is far harder to notice than a bare one.

If the line is in the statement view and the rule ignored it, the cause is almost always one of three things: another rule higher up the list matched first and won, the rule is scoped to a different bank account, or a condition is testing a field the bank populates differently from how you assumed. Rules are applied in the order they appear on the Bank rules page, so reordering is a real fix rather than a tidy-up.

Rules only ever act on lines that arrived

A bank rule is a coding shortcut for statement lines that are already in Xero, and that's the whole of its job. It has nothing to say about a transaction that never reached the reconcile screen, which is a different problem wearing similar clothes, because both end with an account that won't reconcile.

Ledgers go incomplete for reasons that have nothing to do with each other. UK open banking consent expires every ninety days and has to be reauthorised, which is regulation rather than a fault, so nothing will ever flag it as an incident. A provider outage stops delivery for a stretch, and when it's restored the feed runs forward from the restoration rather than going back to collect what it missed. A feed switched on today brings only a limited window of history with it, so anything older than that window was never going to arrive by itself. And eligibility is decided per account rather than per bank, so an account at a bank you already feed successfully can turn out to have no feed available at all.

The cause genuinely doesn't matter, because the residue is identical in all four cases: the bank has the transactions, the statement has the transactions, and Xero doesn't. Your rules are sitting there in perfect working order with nothing to act on, and the account stays out by an amount no amount of rule tuning will recover.

• Disruptions to bank feedsThe significant feed outages Xero currently knows about, listed by region.
• Import a CSV bank statementXero's documented manual fallback and the formats it accepts, which are CSV, OFX, QBO, QFX and QIF, and never PDF.

Getting the missing lines in, so the rules have something to work on

The documented answer to a gap is the manual import, and it's a per-file job every time: convert whatever the bank gave you into one of the formats Xero accepts, map the columns again, import, and hope the export covered the whole period. Xero drops lines it recognises from a file you've already imported, but that's an after-the-fact check on files rather than a check on the boundary, so an import that overlaps what the feed did manage to deliver is still yours to get right, and there's no running-balance check at the end telling you the file stopped short of the last transaction.

StatementClear posts the statement into Xero through the Bank Feeds API instead, so the lines arrive as bank feed lines rather than as an imported file. That matters here for a practical reason: the reconcile screen is where bank rules operate, and a rule doesn't care how a statement line got there, so the rules you've already built apply to posted lines the same way they apply to anything the native feed delivers, with no second set of rules to maintain.

Before any of it posts, every line is checked against what's already in Xero so an overlapping period can't double up, the running balance is recomputed and checked against the statement so a truncated export gets caught rather than quietly reconciled, and inverted signs are flagged, which is worth more here than anywhere, because a sign error is precisely the kind of line a rule will code confidently and a reviewer will read straight past. The columns are mapped once per account and remembered, so the second statement is an upload and nothing else.

• Bank Feeds API overviewThe interface a posted feed line arrives through, and why that isn't the same thing as importing a file.
• About bank feedsXero on how often feed transactions arrive, and on refreshing a feed without waiting for the next cycle.