What a rule matches on
Conditions are combined with AND — every condition you set has to hold:- Payer name contains and Memo contains — text matching on the imported item
- Memo regex — pattern matching for structured memos
- Amount ≥ / Amount ≤ — an amount range
- Financial account — limit the rule to one account
- Source — restrict to bank-feed items or to parsed documents; unset matches both
What it fills in
- Vendor — the contact the item is linked to
- GL account — the account the expense side posts to
- Route to — an optional property, project, job, shop, or cost center
Where rules fire
The same rule reaches items from two directions, through one matcher. At ingest, automatically. New bank-feed transactions and newly parsed documents are matched as they arrive, so they land already carrying a vendor and category. Most items arrive this way. Keep the rules current and the daily review becomes a scan instead of data entry. In batch, over what’s already pending. Rules you write today don’t reach yesterday’s queue on their own. Ask Zeno what your saved rules would do to the pending items right now, and it comes back with the matches grouped by the rule that won them — so you approve or reject a pattern, not two hundred rows. Uncheck any group you don’t want and apply the rest. Two things about batch apply:- It only fills blanks. An item that already has a vendor or category keeps what it has. Applying rules can’t overwrite a decision someone already made.
- It re-checks at write time. Every rule is re-evaluated server-side when you apply, so a preview you left open for an hour can’t write something the current rules wouldn’t.
Testing a rule before you save it
Dry-run answers a different question from batch apply: not “what would my rules do to the queue” but “what would this condition set catch.” You get the pending and historical items the draft rule would match, which is how you find out thatAMAZON sweeps up AWS along with the marketplace orders.
Keep patterns short and distinctive, then check the dry run. Widening a rule later is easy; unpicking a rule that miscategorized six months of history is not.
Knowing a rule did it
An item whose fields were filled by a batch apply carries the rule that filled them. The badge means a rule set this value — not “a rule ran here once.” Edit the field by hand and the badge clears, because at that point the value is yours, not the rule’s. So when a category looks wrong, the badge tells you whether to fix the row or fix the rule.Rules that suggest themselves
Zeno counts how often each merchant pattern resolves to the same GL account. Once a pattern has settled the same way enough times, it starts offering that account as a suggestion when the payee shows up again. A habit you’ve repeated becomes a suggestion, and a suggestion you accept becomes a rule. If you keep approving the same category for the same payee, write the rule and stop deciding it.Changing a rule
Editing a rule changes what it does from then on. It doesn’t recategorize what it already touched — reach for batch apply over the pending queue for that, or reparse the documents still waiting in the queue so they pick up the new mapping. Disable takes a rule out of the matcher without deleting it. Use it when you suspect a rule is causing trouble but aren’t sure yet.Rules or knowledge?
Ask whether the answer requires judgment:- A rule — this payee always posts to this account. No thinking involved.
- Knowledge — this vendor bills two jobs on one invoice and the split depends on the line items. Someone has to read it.
Where to go next
- Knowledge & rules — the judgment layer, and the work log.
- Books — the review queue rules feed.