Xero Bank Rules: How to Set Them Up, and Where They Stop
Bank rules are the first automation every Xero user reaches for. Built well, they take care of the repeat lines. Here is how to build them, and an honest test of how far they go.
What a bank rule actually does
A Xero bank rule is an instruction: when a statement line matches these conditions, code it like this. You set conditions on the payee, the reference, the description, the amount or any text field, choose whether any or all of them must match, and tell Xero which account, VAT rate, contact and tracking category to use. A rule can allocate the whole amount, fixed amounts, or percentages across several lines (Xero Central).
Two details matter more than they look. Rules are applied in priority order, so when two rules match the same line, the higher one wins and you don't get to choose; Xero users have been asking for that choice for years (Xero Product Ideas). And a rule suggests the coding during reconciliation. You still check it and click OK.
Quick answer: A Xero bank rule tells Xero how to code a statement line that matches conditions you set, such as a payee or a word in the description. Build them on text with contains rather than fixed amounts, and order specific rules above general ones. They suit repeat suppliers. They can't match invoices, can't tell look-alike names apart and never cover one-offs: in our test feed, 31 rules reached 58% of lines.
Three rules worth building
Most rule problems come from building them the way Xero suggests by default, straight from the line in front of you. These three patterns cover nearly every rule a small business needs.
- Condition
- Any text field
containsCRAVEN ESTATES - Code to
- Rent, the right VAT rate, the landlord as contact
- Apply to
- The one bank account it is paid from
Leave the amount out of the condition even though it never changes. Xero warns that a rule looking for a fixed amount stops applying the moment the value moves (Xero Central), and rents and premiums go up once a year, usually unannounced.
- Condition
- Any text field
containsone distinctive word, such asTRAVIS PERKINS - Code to
- Materials, standard-rated
Bank narratives carry a branch, a reference or a date that changes every time. Choose the word that never changes and drop the rest. Prefer Any text field to Payee or Description, because banks move text between those fields and a rule on the wrong one silently stops working.
- Condition
- Any text field
containsVODAFONE - Allocate
- 80% Telephone, 20% to the director's loan or drawings; or by tracking category
Percentages keep working when the bill changes. Fixed amounts don't. Then put the most specific rules at the top of the list, so a narrow rule is reached before a broad one catches its lines.
The stress test
Rules are easy to admire one at a time. The real question is what share of a business's bank lines they can ever reach. So we measured it on a three-month feed from a simulated joinery business we use to test our own coding engine: 310 lines across a current account, a savings account and a business credit card, with the same mix of suppliers, customers, transfers and awkward cases a real one has.
We counted a line as rule-friendly if its merchant, with the changing references stripped out, appeared at least three times in the quarter. Then we looked at everything else.
Three things stood out.
The rules that work, work. 180 lines came from 31 repeat merchants. That is a manageable number of rules. But 24 of those 31 merchants charged varying amounts, which is why the amount belongs nowhere near a condition.
A quarter of the lines shouldn't be coded by a rule at all. 77 lines were customers paying invoices. A rule on a customer's name would code each receipt to sales, and if you raised the invoice in Xero, that income is now counted twice. A receipt needs to be matched to the invoice it pays, sometimes several invoices, sometimes one invoice paid in instalments. Rules don't match.
Text can't tell look-alikes apart. The feed includes SKIPTON BUILDING SOCIETY INTEREST when one customer is Skipton Building Solutions, and RIPON ESTATE SUPPLIES CREDIT beside a customer called Ripon Estates. A rule built on the customer's name codes the building society's interest and a supplier's refund as sales. The rule did exactly what it was told. It was told the wrong thing.
Where bank rules stop
- One-offs. Nobody writes a rule for a purchase they will make once, so those lines are always manual.
- Invoices. Matching receipts and payments to open invoices and bills is a different job, done in Xero's Match tab, one line at a time.
- Look-alikes. Text conditions can't weigh context, so similar names misfire in both directions.
- Maintenance. Suppliers rename, banks reformat narratives, and the list grows. Rules don't learn from your corrections; you edit them.
- Every client separately. For a practice, rules live in each client's file. Fifty clients means fifty rule sets to build and keep current.
Xero has also been testing automatic reconciliation, which reconciles lines it is highly confident about using the business's history, its rules and matching information (Xero). It is a welcome step for simple, repetitive businesses, and it inherits the same question: what happens to the lines it isn't confident about.
The other 42%
This is the part CodeIQ was built for. It connects to Xero, reads the client's own coding history, pulls the outstanding invoices and bills, and codes a statement through eight phases: transfers between the business's own accounts, invoice and bill matching, the client's history, shared merchant patterns, card merchant categories, meaning-based matching, your own corrections, and VAT. Lines it isn't sure about are flagged for review rather than guessed, and the approved result posts back into Xero.
One honest limit, which is Xero's rather than ours: Xero's API doesn't let software mark transfers and invoice payments as reconciled, so those arrive in Xero as suggested matches that need your OK. Ordinary coded lines can post fully reconciled.
Automatic coding uses four credits a line; coding a line yourself is always free, and every account starts with 1,000 free credits. The ReconcileIQ practice plans include 50,000 to 500,000 credits a month.
The honest answer: use both
Keep bank rules for the twenty or thirty fixed, repeat merchants every business has. Build them on a distinctive word, leave the amount out, use percentages for splits, and order them from specific to general. They are free and they are reliable for exactly that job.
Then stop expecting them to do the rest. Receipts belong against invoices, look-alikes need context, and one-offs need judgement. That is where a coding engine that learns from the client's own books earns its place.
Code the lines your rules can't
CodeIQ codes a Xero bank statement from the client's own history, matches receipts to open invoices, and posts the reviewed result back. 1,000 free credits to start.
See how CodeIQ worksFrequently Asked Questions
Create the rule from the bank account's reconciliation screen or from the bank rules list. Choose spend, receive or transfer, set conditions on the payee, reference, description, amount or any text field, choose whether any or all must match, then set the account, VAT rate, contact and any tracking or percentage split.
The commonest reasons are a condition on a fixed amount that has since changed, an equals condition where the bank text varies, the text arriving in a different field from the one the rule checks, a higher-priority rule matching first, or the rule being set to a different bank account. Using contains on any text field avoids most of them.
No. A bank rule suggests the coding during reconciliation and you confirm it. Xero has been testing automatic reconciliation for lines it is highly confident about, which can draw on your rules as one of its signals.
No. Bank rules code lines to accounts. Matching a receipt or payment to an open invoice or bill is done in reconciliation's Match tab, or by software such as CodeIQ that matches against outstanding invoices automatically.
Yes. A rule can allocate fixed amounts or percentages across several accounts or tracking categories. Percentages keep working when the amount changes; fixed amounts don't.
Both. Bank rules are free and reliable for a short list of fixed, repeat suppliers. Automatic coding handles what rules can't: invoice receipts, varying narratives, look-alike names and one-offs, learning from the business's own history.