Transaction coding — assigning the correct account code and GST code to each bank transaction — is the core daily work of bookkeeping. ReconLink's coding engine is designed to make this work faster and more consistent through a three-layer architecture: deterministic rules, machine learning pattern suggestions, and large language model (LLM) coding for transactions the first two layers cannot confidently handle. Understanding how each layer works, when each one fires, and how to review and accept codes efficiently makes the difference between a chaotic inbox of uncoded transactions and a practice that processes most clients' transactions automatically.
The Three-Layer Coding Architecture
ReconLink processes every imported transaction through three layers in sequence. The layers are not simultaneous — each one fires only if the previous layer has not produced a confident result.
Layer 1: The Rules Engine
Layer 1 is the deterministic rules engine. It checks each transaction's vendor key (more on this below) against the coding rules stored for the practice. If a matching rule exists, the transaction is coded automatically to the rule's assigned account code and GST code — with no suggestion required from the bookkeeper, no AI call, and no delay.
Layer 1 is fast, free (no API cost), and exact. A rule that matches fires every time, producing perfectly consistent coding for recurring transactions. The rule-based approach is ideal for:
- Regular supplier payments (utilities, subscriptions, known trade suppliers)
- Payroll-related transactions (wages, super, PAYG W)
- Loan repayments and rent payments
- Known client receipts
Rules in Layer 1 are created in two ways: manually (you create a rule directly for a vendor key or transaction description pattern) or automatically promoted from Layer 3 (when a practice opts in to rule promotion, accepting an LLM suggestion with confidence above the promotion threshold triggers automatic rule creation for that vendor key). The auto-promotion feature means your Layer 1 rule set grows organically as you accept LLM codings — over time, more and more of your clients' transactions are handled at Layer 1 without any human review.
Layer 2: ML Pattern Suggestions
When no Layer 1 rule matches, Layer 2 applies. Layer 2 is a machine learning model trained on the coding history of your practice — both the rules you have created and the transactions you have coded manually. It looks for patterns: this vendor key has been coded to a particular account code in the past; this transaction amount and description pattern resembles other transactions that were coded a certain way.
Layer 2 produces a suggestion with a confidence score. High-confidence Layer 2 suggestions (above a configurable threshold) are presented to the bookkeeper as a strong recommendation. Lower-confidence suggestions are still shown but with a visual indicator that the match is less certain.
Layer 2 suggestions are not automatically applied — they always require review. The Layer 2 suggestion workflow is designed to make review fast: keyboard shortcut A accepts the displayed suggestion with a single keystroke; E opens the edit panel to change the code before accepting. You can work through a queue of Layer 2 suggestions at high speed when the model is performing well.
Layer 2 learns continuously. Every time you accept or edit a suggestion, the model updates its understanding of how your practice codes transactions. New clients whose transactions have no history in your practice will initially see lower Layer 2 accuracy; this improves over the first few months of coding.
Layer 3: LLM Coding
When neither Layer 1 nor Layer 2 produces a confident result, the transaction is passed to Layer 3 — the LLM coding engine. Layer 3 sends the transaction description (normalised to its vendor key), amount, and metadata to a large language model with context about the client's industry and the practice's account code list. The LLM analyses the transaction and returns a suggested account code and GST code, along with its reasoning.
Layer 3 is the safety net for genuinely novel transactions — new suppliers, unusual one-off payments, descriptions that are too ambiguous for pattern matching. It is slower than Layers 1 and 2 (the API call takes a moment) and carries a per-call cost, but it can correctly identify transactions that no rule-based or pattern-based system could handle without specific context.
A key efficiency feature: Layer 3 is called once per vendor key per batch, not once per transaction. If 15 transactions in a statement import all share the same normalised vendor key (e.g., 15 purchases from the same supplier with slightly different reference numbers), the LLM is called once and its result is applied to all 15. This dramatically reduces both the API cost and the review queue.
The RULE_PROMOTION_MIN_CONFIDENCE setting (default 0.70) controls the threshold above which accepted Layer 3 suggestions are automatically promoted to Layer 1 rules. For a practice that wants tight control over rule creation, this can be raised to 0.85 or above. For practices that want aggressive automation growth, the default 0.70 is appropriate for most vendor types.
Understanding Vendor Key Normalisation
The vendor key is the stable identifier derived from a transaction description that allows ReconLink's engines to recognise the same supplier across multiple transactions, even when the raw bank description varies.
Raw bank descriptions for the same supplier often look like:
EFTPOS BUNNINGS WAREHOUSE 1234 SYDNEY
INTERNET BANKING BUNNINGS 5678 REFERENCE 99001234
PAYPAL AUSTRALIA BUNNINGS WAREHOUSE
OSKO PAYMENT BUNNINGS
Without normalisation, these four transactions would appear to the rules engine as four different vendors, requiring four separate codings. With vendor key normalisation, ReconLink's normalize_vendor() function strips:
- Bank channel prefixes: EFTPOS, ONLINE, INTERNET BPAY, PAYPAL AUSTRALIA, OSKO, BPAY
- Trailing reference IDs (transaction numbers, invoice references, dates)
- Excess whitespace and capitalisation variation
The result — in the example above — is the normalised vendor key bunnings warehouse. All four transactions share this key, and a single rule for bunnings warehouse handles all of them regardless of which channel or reference number appears in the raw description.
This normalisation approach directly drives Layer 3 efficiency: the LLM is called once for bunnings warehouse rather than four times for four different-looking descriptions. It also keeps the rule set clean — you manage rules by vendor, not by the infinite variation of raw bank descriptions.
Accepting, Editing, and Reviewing Codes
The transaction coding interface is designed for speed. The review queue shows unresolved transactions with suggested codes from Layer 2 or Layer 3 displayed inline. The keyboard shortcuts:
- A — Accept the displayed suggestion without modification
- E — Open the edit panel to modify the account code or GST code before accepting
- S — Skip the transaction (move to the next without coding; it remains in the queue)
- R — Reject the suggestion and mark for manual review
For transactions where you disagree with the suggestion, pressing E opens a dropdown of account codes and a separate GST code selector. The account code list is the 21-code standard Australian accounting code set; the GST codes are GST, FRE, INP, N-T, and CAP. Select the correct codes and press Enter (or click Accept) to save.
When you accept or edit a Layer 2 or Layer 3 coding, the coding is applied to the transaction and — if rule promotion is enabled and the confidence threshold is met — a Layer 1 rule is created for the vendor key. Future transactions with the same vendor key are coded automatically at Layer 1.
Bulk accept is available for the queue: if the entire queue for a client consists of transactions you are confident are correctly suggested, the bulk accept function applies the suggested codes to all of them simultaneously. Use this judiciously — review a sample before bulk accepting to confirm the suggestions are sound, particularly for a new client whose Layer 2 model is not yet well-trained.
Setting Up Coding Rules Manually
For clients with large volumes of known recurring transactions, setting up Layer 1 rules manually at the start of the engagement is worthwhile. Navigate to Settings > Coding Rules for the relevant client and create rules for:
- The client's regular supplier payments (identify them from the most recent three months of bank statements)
- Payroll-related transactions (set up rules for the payroll platform's direct credit reference)
- Known inter-account transfers (code to the correct clearing or transfer account to prevent false positives in the P&L)
A well-seeded rule set at client onboarding means that the first import is mostly handled at Layer 1, with only genuinely novel transactions flowing to Layers 2 and 3. This dramatically reduces the review burden in the first few months and demonstrates immediate value to the client practice.
Monitoring Coding Performance
The ReconLink dashboard shows auto-code rate by client — the percentage of transactions coded automatically by Layer 1 without any human review. A high auto-code rate (above 70%) indicates a mature rule set and a well-trained Layer 2 model. A low auto-code rate for a long-standing client suggests that either the vendor key normalisation is not matching rules correctly (check for unusual bank description formats) or that the client's transaction mix has changed significantly.
Review the auto-code rate monthly. For clients where it is declining, investigate: are new supplier relationships appearing that need rules? Has the bank started formatting statement descriptions differently? Is there a batch of transactions with no vendor key match due to an unusual payment method?
The coding engine is designed to become more accurate over time as the practice accumulates coding history. New clients start at a lower auto-code rate and improve over the first two to three months as Layer 2 learns the patterns. The combination of manual rule seeding at onboarding, Layer 2 learning, and Layer 3 LLM coding with automatic rule promotion means that most well-managed clients reach an auto-code rate above 85% within six months of engagement.