Setting up coding rules in reconciliation software means defining the conditions under which a transaction is automatically assigned an account code and GST treatment — without a bookkeeper touching it. A coding rule says: every time a transaction description contains "AGL", code it as 6-1050 Electricity with GST. Once the rule exists, every future AGL transaction codes instantly and correctly, regardless of which client it belongs to or who is working the queue.
For an Australian practice managing multiple clients, a well-maintained rule library is the single highest-leverage configuration task in the system. Coding rules typically handle 60–75% of all transactions once a library matures — meaning most of the daily reconciliation volume never reaches a human reviewer.
What is a coding rule in Reconlink?
A coding rule in Reconlink is a pattern-match instruction. It has three components:
- Condition — the text pattern to match against incoming transaction descriptions (e.g., contains "ORIGIN ENERGY", starts with "ATO", equals "PAYROLL")
- Account code — the account to assign when the condition matches (e.g., 6-1050 Electricity, 9-9999 Owner's Draw)
- GST code — the GST treatment to apply (GST, FRE, INP, N-T, or CAP)
Rules run before the machine-learning layer. When a transaction matches a rule, the rule result commits — the ML model is not consulted. This makes rules fast, auditable, and 100% deterministic.
Rules in Reconlink are shared across all clients on the practice. A rule built for one client applies to every client whose transactions match the same condition. This is the key architectural difference from per-organisation tools like Xero bank rules — you build the rule once, and the entire practice benefits.
Before you start: what to have ready
Before building your rule library, gather:
- A list of your 30–40 most common vendors across the practice — utility providers, telcos, payroll processors, the ATO, insurance companies, and any other high-frequency suppliers
- The correct account code and GST treatment for each vendor — check your chart of accounts and confirm GST registration status for any vendors where you are unsure
- 12 months of transaction history (if migrating from another system) — scanning this data identifies the vendors you code most frequently
For new practices starting from scratch, you can begin with the 15–20 universal Australian vendors (AGL, Origin Energy, Telstra, Optus, ATO PAYG, Xero subscription, etc.) and add client-specific vendors as you onboard each one.
Step-by-step: building your first coding rules
Step 1: Open the Rules Library
Navigate to Settings → Coding Rules in the Reconlink sidebar. This is the practice-wide rule library — every rule you create here applies across all clients.
Step 2: Create a rule for a recurring vendor
Click New Rule. In the condition field, enter the text pattern that uniquely identifies the vendor in bank statements. Best practice:
- Use "contains" matching for vendors whose descriptions vary slightly (e.g., "TELSTRA" matches "TELSTRA BILL", "TELSTRA MOBILE", "TELSTRA DIRECT DEBIT")
- Use "starts with" matching for vendors with consistent prefixes
- Use "equals" only when the description is always identical — this is the most precise but also most brittle if the vendor changes their description format
Then assign the account code and GST treatment. Add a note explaining the decision (e.g., "Confirmed GST-registered as of Jan 2026") — this is visible in the audit trail and useful when the rule is reviewed later.
Step 3: Test the rule before saving
Reconlink's rule builder shows a live preview of which recent transactions would have matched the condition. Review the matched transactions before saving — if the pattern is too broad, it may catch transactions it should not. Tighten the condition until the match set is accurate.
Step 4: Build your starter library (first session)
For a new practice setup, allocate 60–90 minutes to build the starter rule library in a single session. Target 25–35 rules covering:
- Utilities (electricity, gas, water): AGL, Origin, Synergy, SA Power Networks, Sydney Water, etc.
- Telecommunications: Telstra, Optus, TPG, Vodafone
- Payroll and super: ATO PAYG withholding, super fund clearing house
- Software subscriptions: Xero, MYOB, Microsoft 365, Adobe, Dropbox — all typically GST
- Banking fees: Monthly account keeping fees (INP, not GST), international transaction fees (INP)
- Insurance: Check GST registration — most general insurers are GST-registered, but confirm
- Fuel: typically GST; confirm for mixed-use clients
These 25–35 rules typically cover 50–60% of transaction volume for most client types.
Step 5: Add client-specific rules during onboarding
When you onboard a new client, review their first month of transactions and add rules for any high-frequency vendors that are specific to that client's industry. A hospitality client will have food suppliers; a construction client will have materials suppliers and plant hire companies. The cross-client library handles the universal vendors — client-specific rules handle the tail.
Most practices find they add 5–10 client-specific rules per new client onboarded.
Maintaining your rule library over time
Rules are durable but not maintenance-free. Two things break rules:
1. Vendor description changes. Banks change the way they display merchant descriptions — "AGL ENERGY BILL" may become "AGL DIRECT DEBIT". When this happens, the old rule stops matching and transactions fall through to the ML layer. A monthly rule-health scan (10 minutes) identifies rules with zero matches in the last 30 days — the likely sign that the vendor format changed.
2. Vendor GST status changes. A vendor that was not GST-registered may cross the $75,000 threshold and start charging GST. If your rule codes them as N-T and they are now GST-registered, the rule is generating miscoded transactions. A quarterly review of N-T and FRE rules — particularly for smaller suppliers — catches this before it creates BAS errors.
Promoting ML codings to rules
Reconlink's rule-suggestion view surfaces vendors that the ML layer has been coding consistently for three or more months. These are strong candidates for promotion to deterministic rules — clicking "Create rule" converts the ML coding pattern into a saved rule, removes the vendor from the ML queue, and makes the coding faster and cheaper going forward.
This is the recommended growth path for a rule library: build the starter library manually, then let the ML run for 2–3 months and promote the patterns it has learned into rules. Most practices find the rule library doubles in size over the first six months through this process, and their auto-code rate climbs from 60% to 80%+.
How rules interact with the three-layer coding engine
Reconlink's three-layer coding engine runs in order:
- Rules — deterministic, instant, auditable. Handles matched vendors.
- ML model — per-client, trained on historical codings. Handles vendors with no matching rule.
- LLM fallback — for genuinely ambiguous transactions (new vendors, unusual descriptions). Below-threshold suggestions go to the review queue.
A transaction that matches a rule never reaches the ML or LLM layers. This makes rules the fastest and cheapest coding path — worth investing in upfront.
Frequently asked questions
Do coding rules apply across all clients or per client? Rules in Reconlink apply across all clients on the practice. If you create a rule for "AGL", it applies to every client whose bank transactions contain "AGL". This is the fundamental difference from per-organisation tools — you build it once, the whole practice benefits.
What happens if two rules match the same transaction? Reconlink applies the more specific rule first. "Equals" rules take precedence over "contains" rules. If two "contains" rules both match the same transaction, the rule with the longer, more specific pattern wins. The audit trail shows which rule was applied.
Can I override a rule for a specific client? Yes. Client-level overrides let you set a different code for a specific vendor for one client, while the practice-wide rule applies to all other clients. This handles the case where the same vendor has different GST treatment for different entities — for example, a vendor that is a related party for one client.
How many rules do I need for a well-automated practice? Most practices with 10–30 clients reach a steady state of 80–150 rules. The starter library (25–35 rules) covers the universal vendors; the remainder accumulates through client onboarding and ML promotions. There is no upper limit.
A coding rules library is the foundation of a fast practice. The time spent building it compounds every month — each rule eliminates a coding decision that would otherwise be made manually, indefinitely. See the full feature set or book a demo to walk through rule setup with your actual client data.