Transaction Categories and Rules

Categories determine how transactions roll into reports. Rules turn repeat corrections into a workspace policy by matching transaction fields and applying a category, tag, owner, or analytics treatment.

Use categories to define the finance model. Use rules only after the category model is stable enough to automate.

Where to Work

• Change a transaction's category directly in Transactions or its detail sheet.
• Choose Rules from the Transactions owner shortcuts to open the rule builder and rule library.
• Use the standalone Categories page in the Transactions area for hierarchy, tax, reporting-code, and exclusion maintenance.

The current Transactions shortcut row exposes Rules but does not expose a Categories shortcut. Categories can still be created inline from an individual transaction; deeper category maintenance requires the separate Categories page.

Before You Start

Prepare a small set of representative transactions and decide which reporting questions the category model must answer. If rules will add tags or owners, create the tags and confirm the intended team members are active first.

For tax-sensitive categories, confirm the workspace's tax type, rate, and reporting-code conventions before applying the category in bulk.

Categories

What a category stores

A category can include:

• a required name and display color
• an optional parent category
• a description shown as category guidance
• a tax type and tax rate
• a reporting code
• Exclude from Reports behavior

The Categories table shows name, tax type, tax rate, reporting code, and excluded state. Search filters the visible list by name. Expand a parent to see its child categories.

Parent and child categories

The current category editor supports a top-level parent with child categories beneath it. A category that already has children cannot be moved under a different parent. This protects the existing hierarchy from an ambiguous nested move.

Use parent categories for broad reporting groups and children for operator-level detail. For example:

System and custom categories

System categories carry a System badge and cannot be removed from the table. Custom categories can be edited or removed.

The system Internal Transfer category is always excluded from analytics and cannot be included from the category table. That prevents transfers between owned accounts from inflating both inflow and outflow reporting.

Excluded categories

Turn on Exclude from Reports when every transaction in that category should be omitted from spending analytics, finance reports, and profit-and-loss calculations.

This is broader than excluding one transaction. Before changing it, review how many transactions use the category and whether historical reports should change.

Create a category

1. Open the Categories page in the Transactions area.
2. Choose Create.
3. Enter a name and choose its color.
4. Optionally select a parent and add a description.
5. Add tax type, tax rate, and reporting code when the accounting workflow requires them.
6. Decide whether every transaction in the category should be excluded from reports.
7. Choose Create.

You can also type a new category name in an individual transaction's category selector and choose the create option. Inline creation sets the name and generated color; use the Categories page afterward for hierarchy, tax, description, reporting code, or exclusion settings.

Transaction Rules

Rules are deterministic. They do not ask an AI model to decide whether a transaction matches. Eigenn evaluates the configured fields and operators, in priority order, and applies the first active rule whose conditions all match.

Active rules run after bank transactions land and before built-in categorization heuristics. They also run during supported recurring-transaction sync work.

Conditions

Every rule needs at least one complete condition. Multiple conditions use AND semantics: every condition must match the same transaction.

The regular-expression operator is validated before creation. Invalid expressions and nonnumeric amount conditions prevent the rule from being created.

Actions

A rule must choose at least one action:

• set one category
• add one selected tag from the builder
• assign one workspace member
• mark the transaction internal with Exclude from analytics

Actions only add or set values. The current builder does not provide actions to remove a category, remove a tag, clear an assignee, or reverse an analytics exclusion.

Priority and the winning rule

Priority is an integer from 0 through 1,000. Lower values run first. When more than one active rule could match, only the first matching rule is applied.

Make narrow exceptions lower-numbered and broad defaults higher-numbered. For example:

1. Priority 25: merchant contains “AWS” and amount is less than -500 → Infrastructure.
2. Priority 100: merchant contains “AWS” → Software.
3. Priority 500: direction equals Money out → General expense review.

Quick starts

The builder can prefill examples for:

• software merchants
• large expenses
• income deposits
• internal transfers

Treat these as starting shapes. Review the signed amount, merchant wording, and selected actions before creating the rule.

Create a Rule Safely

1. Manually correct several representative transactions first.
2. Open Transactions → Rules.
3. Enter a descriptive rule name and optional reviewer note.
4. Choose a priority. Remember that a lower number wins.
5. Add the smallest set of conditions that distinguishes the intended transactions.
6. Choose at least one category, tag, owner, or exclude action.
7. Read the condition and action preview.
8. Start with Enabled off when the match is broad or unproven.
9. Choose Create rule.

The builder displays validation messages until the name, every condition value, and at least one action are valid.

Rule Library and Backfill

The library summarizes total, active, paused, backfill-ready, and multi-condition rules. Search includes the rule name, description, condition summary, and visible actions. You can sort by priority, specificity, name, or creation date and filter to Active, All, Backfill, Specific, or Paused.

Each row can:

• apply that rule to recent transactions
• create a paused duplicate
• pause or resume the rule
• delete the rule

Run workspace rules evaluates active rules in priority order across the recent workspace window. The per-rule play control evaluates that one rule, including when the rule is paused.

Both manual paths scan at most the 2,000 most recent transactions. The success message reports how many rows were scanned, matched, or updated depending on the action used.

States and Limits

• Rule names are limited to 120 characters and descriptions to 500 characters.
• Priorities must be integers from 0 through 1,000; the builder offers common preset values.
• Conditions support AND only. OR groups and nested condition logic are not available.
• The first matching active rule wins; later matching rules do not add extra actions.
• The builder selects at most one category, one tag, and one owner per new rule.
• Manual backfills scan the 2,000 most recent transactions. There is no preview-only dry run or automatic undo.
• Existing rule definitions cannot be edited in place. Pause the old rule and create a corrected replacement.
• Duplicate immediately creates a paused copy at the next priority value; it does not open an editable copy of the builder.
• Delete has no confirmation or automatic rollback. Deleting or pausing a rule does not revert changes it already made.
• A category action clears the transaction's saved tax amount, rate, and type so tax can be recalculated for the new category. Recheck tax-sensitive matches after a rule run.

Verify the Result

After applying or enabling a rule:

1. Filter Transactions to the affected date, account, merchant, or category.
2. Inspect both matching and near-miss transactions.
3. Confirm the intended category, tag, owner, and analytics treatment.
4. Check that a lower-priority rule did not win first.
5. Recheck tax fields when the rule changed category.
6. Confirm newly synced transactions receive the same treatment.

Troubleshooting

The rule never matches

Check the exact field populated by the source. Merchant, counterparty, description, and name are separate fields, and a provider may leave one of them empty. Also check the signed amount and whether the rule is paused.

A broader rule wins

Lower the numeric priority of the specific rule or raise the broad rule's priority. Only the first active match is applied.

An amount rule behaves backward

Expenses normally use negative amounts. A large expense may need “amount less than -1000,” not “greater than 1000.” Add Direction → Money out when that makes the intent clearer.

Old transactions did not change

Creating a rule does not automatically backfill the full ledger. Use the per-rule play control or Run workspace rules. Transactions older than the newest 2,000 rows are outside the manual scan window.

A tag or category is missing from the action list

Create the category or tag from a transaction first, then return to the builder. Removed team members and deleted tags cannot be targeted by a new rule.

The wrong account matches

The Account condition compares the internal bank-account ID, not the account name shown in the table. If you cannot confirm that identifier, use merchant, counterparty, description, amount, and direction conditions or contact support before enabling the rule.

Tax values disappeared after backfill

A rule that changes category clears saved tax fields. Reopen representative transactions, confirm the category's tax settings, and attach or reprocess the supporting receipt when needed.

Related Pages

• Transactions
• Bank Connections
• Reconcile and Categorize Transactions
• Maintain Transaction Rules
• Invoice Insights
• Stress Tests