A coding rule in accounting software is an if/then instruction: if an incoming transaction description matches condition X, assign account code Y and GST treatment Z. That is the complete definition. Every time a transaction from an imported bank statement matches the pattern, the software codes it automatically — no bookkeeper required. The rule runs in milliseconds, produces the same result every time, and leaves a complete audit trail.
For Australian practices managing multiple clients, coding rules are the foundational unit of automated reconciliation. A well-maintained rule library means the majority of transactions — the recurring vendors, utilities, payroll deductions, and software subscriptions that appear every month without variation — never reach a human reviewer at all.
Why coding rules matter
Without coding rules, every transaction that arrives from an imported bank statement is a manual coding decision. A practice with 20 clients, each averaging 250 transactions per month, faces 5,000 individual coding decisions before BAS preparation even begins. Manual coding is slow, introduces inconsistency, and creates a hard ceiling on how many clients a team can manage.
Coding rules eliminate the easy decisions. The AGL electricity bill, the Telstra mobile charge, the ATO PAYG withholding — these are the same vendor, the same account code, the same GST treatment, every single month. A rule handles all of them permanently. Once written, a rule compounds: it eliminates that coding decision not just for this month but for every future month, across every client whose transactions match the pattern.
A mature practice rule library typically handles 60–75% of all incoming transactions automatically. At that coverage level, reconciliation shifts from a data-entry task to a review task.
The anatomy of a coding rule
Every coding rule has three required components and a few optional ones.
Required components:
- Condition — the text pattern to match against the transaction description (e.g., contains "ORIGIN ENERGY" or equals "ATO PAYG WITHHOLDING")
- Account code — the general ledger account to assign when the condition is met (e.g., 6-1050 Electricity, 2-1230 PAYG Withholding Payable)
- GST treatment — the GST code to apply: GST, FRE, INP, N-T, or CAP
Optional components:
- Memo or description field — a note explaining the coding decision, visible in the audit trail (e.g., "Confirmed GST-registered supplier as of March 2026")
- Amount filter — rules that only trigger above or below a dollar threshold (e.g., any transaction above $1,000 at a hardware supplier flagged as a potential capital purchase)
- Date-range condition — rules that apply only within a season (useful for businesses with seasonal suppliers that invoice for 6 months of the year)
Types of conditions: contains, starts with, equals
The condition is where most of the design thinking goes. The three standard matching types each have different trade-offs.
| Condition type | How it works | Best for | Risk |
|---|---|---|---|
| Contains | Matches if the pattern appears anywhere in the description | Vendors with variable descriptions (e.g., "TELSTRA BILL", "TELSTRA MOBILE", "TELSTRA DIRECT DEBIT" all match "TELSTRA") | Too broad if the pattern also appears in unrelated descriptions |
| Starts with | Matches if the description begins with the pattern | Vendors with consistent prefixes and predictable variations after the prefix | Misses transactions where the bank formats the description differently |
| Equals | Matches only if the description is exactly identical | Payroll and ATO transactions with standardised, unchanging descriptions | Most brittle — breaks if the vendor or bank makes any change to the description format |
Contains is the most commonly used and handles the widest range of real-world bank description formats. Equals provides precision for vendors where the description never changes. Starts with sits between the two and is useful when a vendor uses a consistent code prefix followed by a variable reference number.
Good rules vs. bad rules
Not all rules are equal. A poorly designed rule creates more work than it saves — it miscodes transactions, generates false positives that need correcting, or breaks silently when a vendor changes their bank description format.
Characteristics of a good rule:
- The condition pattern is specific enough to match only the intended vendor
- The matched vendor has one account code and one GST treatment (no ambiguity)
- The vendor's bank description format has been stable for at least three months
- The rule has been tested against recent transaction history before being saved
Characteristics of a bad rule:
- The condition pattern is too short or too generic and matches multiple unrelated vendors (e.g., "BANK" matches "COMMBANK FEE", "BANKWEST TRANSFER", and "OVERSEAS BANK CHARGE" — three different things)
- The GST treatment is assumed rather than confirmed (a vendor that looks like it charges GST but is not registered)
- The rule was built to match a one-off transaction with an unusual description that will not recur
- The rule depends on the vendor maintaining a specific description format with no fallback if it changes
The most common bad rule in Australian practices: a "contains" rule built from a three-letter abbreviation that happens to appear in descriptions from multiple unrelated vendors. The rule codes everything it catches — not just the intended vendor.
Rules vs. machine learning: what is the difference?
Coding rules and machine learning models both automate transaction coding, but they work in fundamentally different ways.
Rules are deterministic. A rule always produces the same output for the same input. If the condition matches, the rule fires. There is no probability, no uncertainty, no learning. This makes rules fast, cheap to run, and completely auditable — you can trace any coded transaction back to the exact rule that produced it.
Machine learning is probabilistic. An ML model is trained on historical coding decisions and predicts the most likely account code and GST treatment for each new transaction. The output includes a confidence score. Transactions above the confidence threshold are committed automatically; transactions below it surface in a review queue for a bookkeeper to confirm.
The two approaches are complementary, not competing. Rules handle the known, stable vendors — the vendors you have seen hundreds of times before and coded consistently. ML handles the long tail: vendors with no matching rule, new clients with no coding history, and transactions with unusual or inconsistent descriptions.
In Reconlink's three-layer coding engine, rules run first. A transaction that matches a rule never reaches the ML model. This is deliberate — rules are faster and cheaper per transaction than ML inference, so routing known vendors through rules improves both speed and accuracy. ML picks up the remainder, and an LLM fallback handles genuinely ambiguous transactions.
There is also a productive feedback loop between the two layers. When an ML model consistently codes the same vendor the same way for three or more months, that pattern is a strong candidate for promotion to a deterministic rule. The rule replaces the ML prediction, reduces ML load, and makes the coding permanent and auditable. Over time, this process lets the rule library grow itself.
Practice-wide rules vs. per-organisation rules
This is a structural distinction that matters a great deal for accounting practices — but it is rarely discussed.
Most general-purpose accounting software (including Xero's bank rules) builds rules per organisation. A rule you create for one client applies only to that client. If you manage 30 clients, you recreate the same rule for AGL electricity 30 times — or you do not, and the rule coverage varies across your client base.
Purpose-built reconciliation tools for practices take a different approach. In Reconlink, coding rules are practice-wide by default. A rule for "ORIGIN ENERGY" applies to every client managed by the practice. You build it once; every client benefits immediately.
This is not a minor convenience feature — it is a structural efficiency gain. A practice-wide rule library means the 30–40 hours a large practice might otherwise spend replicating rules across client organisations is spent once. It also means consistent coding across the client base: the same vendor is always coded to the same account with the same GST treatment, regardless of which bookkeeper handled the file or when the transaction arrived.
Client-level overrides remain available for the cases where the same vendor has different treatment for a specific client — a related-party vendor, a franchise arrangement with a different GST status, or a mixed-use expense that splits differently per entity.
Frequently asked questions
What is the difference between a coding rule and a bank rule? The terms are used interchangeably in most software contexts. "Bank rule" is the term used in Xero; "coding rule" is more generic and reflects the primary purpose — assigning an account code and GST treatment. The underlying logic is the same: a condition matched against a transaction description triggers an automatic coding outcome.
Can a coding rule handle GST treatment, not just account codes? Yes, and this is important for Australian bookkeepers. A complete rule assigns both the account code and the GST treatment simultaneously. Getting the account code right but the GST code wrong still produces a BAS error. When building rules for any vendor where there is any doubt about GST registration status, confirm registration on the ABN Lookup register before saving the rule.
What happens if two rules match the same transaction? Most tools apply a precedence order — more specific rules (equals matches) take priority over broader ones (contains matches). If two rules of the same type both match, the longer or more specific pattern typically wins. In Reconlink, the audit trail shows which rule was applied, so any unexpected match is visible and correctable.
How many rules does a practice need? There is no fixed number. A starter library of 25–35 rules covering universal Australian vendors (utilities, telcos, ATO, payroll, banking fees, common software subscriptions) typically covers 50–60% of transaction volume immediately. Most practices with 10–30 clients reach a steady state of 80–150 rules through a combination of manual rule-building and ML promotion over the first six months.
Can coding rules be wrong? Yes, and understanding how they fail is important. The two main failure modes are false positives (the rule matches transactions it should not, miscoding them) and silent failures (the vendor changes their description format and the rule stops matching, leaving those transactions to fall through to ML or the review queue). A monthly rule-health check — identifying rules with zero matches in the last 30 days — catches silent failures before they affect BAS figures.
For step-by-step instructions on building your rule library in Reconlink — including how to test rules before saving, how to structure your starter library, and how to promote ML codings to rules — see How to set up coding rules in Reconlink.
To understand how coding rules fit into the broader three-layer automation architecture (rules, ML, and LLM fallback), see How to automate bank reconciliation.