> ## Documentation Index > Fetch the complete documentation index at: https://zenorent.com/docs/llms.txt > Use this file to discover all available pages before exploring further. # Rules > Deterministic pattern → vendor and GL mappings that categorize bank-feed items and parsed documents before anyone looks at them A rule is a pattern with a resolution: when an incoming item looks like *this*, file it as *that*. Rules run without AI, cost nothing, and produce the same answer every time — which is why anything deterministic belongs here rather than in a judgment call. Rules live at **Zeno → Knowledge & rules → Rules**. They stay available even when the AI Bookkeeper module is off, because they drive the bank-feed matcher on their own. ![Rules Engine Hierarchy](https://mintcdn.com/zenoservices/oXHN6W4EbbFuxgiw/images/illustrations/rules-engine.svg?fit=max\&auto=format\&n=oXHN6W4EbbFuxgiw\&q=85\&s=3303d9a8ab742cd10530d5298841001c) ## 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 A rule can also express OR by grouping alternatives, so one rule covers several spellings of the same merchant instead of three near-duplicates. ## 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 that `AMAZON` 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](https://zenorent.com/docs/knowledge-and-rules.md)** — this vendor bills two jobs on one invoice and the split depends on the line items. Someone has to read it. Don't put a mapping in knowledge because it was easier to write there. A rule that fires at ingest is free and exact; the same mapping as prose costs a model call every time and can be read two ways. ## Where to go next * [Knowledge & rules](https://zenorent.com/docs/knowledge-and-rules.md) — the judgment layer, and the work log. * [Books](https://zenorent.com/docs/books.md) — the review queue rules feed. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.