Loading

Coding Rules

Coding rules turn a recurring bank or feed line into a coded transaction without anybody looking at it. A monthly direct debit to the same supplier for the same purpose should not need twelve human decisions a year. Rules are tested before any AI suggestion, and they are written with pickers on the Rules tab of Bank Feeds & Reconciliation.

Where to find it

Admin Panel → Finance:

  • Bank Feeds & Reconciliation — the Rules tab: write, edit, order and delete coding rules; the Queue tab applies them

Architect Panel → ERP - Finance:

  • Feed Queue — the same console for architects

Writing a rule

  1. Open Rules and press New rule.
  2. Under Applies to, choose Every connection of a company, or one connection only.
  3. Set the Priority: higher runs first.
  4. Under When, choose what the rule tests: Description / narrative, Counterparty (as the bank wrote it), Counterparty reference (customer/supplier code), Payment reference, Transaction type, Currency, Amount (signed) or Bank transaction ID.
  5. Choose how it compares under is (for example contains, starts with, equals, is one of (comma-separated), matches the pattern, is at least) and type the Value, for example AMAZON WEB SERVICES.
  6. Set what it codes to: Code to account, VAT, Analysis (for example dim1=CC100; dim2=SALES) and optionally a Counterparty code, which is used to match invoices.
  7. Leave Post automatically when it matches unticked unless the rule is certain. When ticked, a matching line is posted with no human review, but only when rules are applied from this screen by someone allowed to post.
  8. Press Create rule.

The quicker way is Code & learn on the Queue tab: code one line by hand and a rule for the same counterparty is written for you.

Reading the rule list

The Coding rules list shows each rule's Priority, Applies to, When, Then code to and Used, the number of times it has matched. A rule whose field or operator can no longer be read is flagged for you to edit. Deleting a rule leaves the transactions it already coded as they are.

Why rules come first

A rule you wrote gives the same answer every time and can be pointed at when someone asks why a line was coded that way. A suggestion is a guess, however good. So express anything you can as a rule, and keep suggestions for the ambiguous rest, accepted by a person.

Order and specificity

Give specific rules a higher priority than general ones. A rule catching everything from one supplier will silently swallow the one payment to that supplier that should be coded differently. Review priorities whenever you add a rule. Match on the most stable thing in the line: a supplier's name in the narrative usually outlasts a reference that changes monthly.

What goes wrong

  • A rule never fires: its Used count stays at 0. Check the field and value against a real line on the Queue tab.
  • The wrong rule fires: a general rule has a higher priority than the specific one.
  • Something posted that should not have: an auto-post rule matched more than intended. Untick auto-post and reverse the journal.

Worked example

A business writes eleven rules for rent, utilities, insurance, payroll and its five largest suppliers. The rent rule, Description contains LANDLORD PROPERTIES, codes to 6100 Rent and rates with VAT EX and auto-post ticked. The others code without posting. Together they cover about 80% of bank lines; the rest are worked by hand, and any counterparty coded by hand three times gets Code & learn.

Recommendations

  • Learn a rule on the third manual coding, not the first.
  • Specific before general, and recheck priorities on every addition.
  • Use auto-post only for fixed, certain payments such as rent.
  • Delete rules whose Used count stops rising; an old rule is a trap for a similarly named new supplier.