Your first coding rule
A rule is a standing instruction: when an invoice looks like this, code it like that. The point is not automation for its own sake. It is that you should never have to make the same coding decision twice, and that the decision should be written down somewhere your colleague can read it — rather than living in the head of whoever normally does the invoices and going on holiday with them.
Rules and approval tiers are one feature, and both begin with the Starter plan. A free workspace processes invoices and codes them by hand.
Start from something you have already done twice
The best first rule is not hypothetical. Open the inbox, look for a vendor whose invoices you have coded identically three times running, and encode that.
The classic is a landscaping contractor: every invoice goes to the same property and the same grounds maintenance account, and has done since the contract was signed.
The condition vocabulary
A rule matches on these fields, and only these. Each understands only the operators listed against it:
| Field | Operators | Matches against |
|---|---|---|
| Source email | is, contains | The full sender address |
| Vendor | is, contains, is not mapped | The vendor name read off the invoice |
| Amount | is, is greater than, is less than | The invoice total, as a number |
| Keyword in document | contains | The subject line the invoice arrived under |
| Property alias | is, contains | The property hint read off the invoice, or the subject |
| Intake mailbox | is, contains | The intake address the mail arrived at |
Two of those repay a moment's attention.
There is no domain field. Matching a whole vendor domain is Source email contains "@greenacreland.com", which reads a little oddly the first time and is exactly right: it catches billing@, accounts@ and whichever new address their bookkeeper starts using next spring.
"Keyword in document" reads the subject line. Not the body, not the PDF. It is useful for vendors whose subject lines carry a job number or a building name, and useless for anything printed inside the invoice. The name is more generous than the behavior, so plan around the behavior.
Writing the landscaping rule
Conditions, both of which must hold — conditions combine with AND, so every one you add narrows the match:
Source email contains @greenacreland.com
Amount is less than 2500
Actions:
Set coding 6300
Assign reviewer Priya Raman
That is the whole rule. Invoices from that domain under £2,500 arrive already coded, with a named human attached, and land in the approval queue rather than the review queue — assuming extraction was confident about the rest.
The amount condition is doing real work. Without it, the day the landscapers send a £40,000 grounds redevelopment invoice, it is coded to routine maintenance and treated like a lawn mowing. A ceiling on a rule is cheap insurance against the unusual invoice, and the unusual invoice is the one that hurts.
A second rule: the mailbox one
If you have given a building its own intake address, a rule can act on it:
Intake mailbox contains lakeshore@
Use contains with the local part rather than typing the whole address. The rule then survives a change of intake subdomain, which a full address does not.
You may not need this rule at all. A mailbox created with a property already codes mail arriving there to that property when the invoice names nothing your aliases recognize. Reach for the rule when the mailbox should also set a GL code, assign a particular reviewer, or apply only to some of the mail arriving there.
The four actions
| Action | What it does |
|---|---|
| Set coding | Applies a GL code to the document |
| Assign reviewer | Puts a named person on it |
| Auto-approve | Approves the invoice outright, subject to the conditions you set |
| Quarantine | Holds the document and stops any further rule from running |
Auto-approve is opt-in, and worth being deliberate about. A sensible first use is small, high-confidence invoices from a vendor you have mapped — the ones a human approves without reading, which is to say the ones where the approval was theater. Every auto-approval is recorded in the audit trail with the rule that caused it, so the control is auditable rather than invisible.
Order matters
Rules run in ascending priority order: 10 before 20, 20 before 30. Leave gaps when you number them, in the way you were taught to number BASIC lines, so that inserting one later does not mean renumbering the lot.
Quarantine stops the chain. Nothing after it runs, which is the point — a document held for a security reason should not then be auto-approved by a later rule that only looked at the amount.
Everything else accumulates. A general rule that sets the GL code and a specific one that assigns a reviewer will both apply, provided both match.
Check it actually fired
Each rule carries a match count. If you wrote a rule this morning and it has matched nothing by tomorrow, the rule is wrong, not the world — and the usual culprits are a keyword condition expecting to read the document body, a domain typed without its @, or an amount condition in the wrong direction.
The audit trail records which rule touched which document, so a document that was coded in a way nobody expected can be traced back to the instruction that did it.
Where to go next
- Rules reference — every field, operator and action in detail.
- Approval tiers — who has to say yes, and by when.
- Coding invoices — what you are actually setting when you code.
- Per-property mailboxes — when an address is a better tool than a rule.