Transaction Categories and Rules

Categories control how transactions roll into reports. Rules turn repeat corrections into a workspace policy. A rule matches transaction fields. It then applies 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 shows Rules. It does not show a Categories shortcut. You can still create a category inline from an individual transaction. Deeper category maintenance needs the separate Categories page.

Before You Start

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

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

Categories

What a category stores

A category can include:

• a mandatory 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 below it. You cannot move a category that already has children under a different parent. This protects the current 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. You cannot remove a system category from the table. You can edit or remove a custom category.

Eigenn always excludes the system Internal Transfer category from analytics. You cannot include it from the category table. Because of this, a transfer between owned accounts does not increase both inflow and outflow reporting.

Excluded categories

Turn on Exclude from Reports when a category must stay out of reports. Eigenn then omits every transaction in that category from spend analytics, finance reports, and profit-and-loss calculations.

This is broader than an exclusion of one transaction. Before you change it, check how many transactions use the category. Also check whether the historical reports must change.

Create a category

1. Open the Categories page in the Transactions area.
2. Select Create.
3. Enter a name.
4. Select a color.
5. Select a parent category if you want one.
6. Add a description if you want one.
7. Add the tax type, tax rate, and reporting code when the accounting workflow needs them.
8. Decide whether Eigenn must exclude every transaction in the category from reports.
9. Select Create.

You can also type a new category name in the category selector of an individual transaction. Then select the create option. An inline creation sets the name and a 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. Many conditions use AND semantics. Every condition must match the same transaction.

Eigenn checks the regular-expression operator before creation. Eigenn does not create the rule if an expression is invalid or an amount condition is nonnumeric.

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 has no action to remove a category, remove a tag, clear an assignee, or reverse an analytics exclusion.

Priority and the rule that wins

Priority is an integer from 0 through 1,000. Lower values run first. When more than one active rule can match, Eigenn applies only the first rule that matches.

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 initial shapes. Check the signed amount, the merchant text, and the selected actions before you create the rule.

Create a Rule Safely

1. Correct many representative transactions by hand 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 shows 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. You can 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, even when the rule has the paused state.

Both manual paths scan at most the 2,000 most recent transactions. The success message reports how many rows Eigenn scanned, matched, or updated. The count depends on the action that you used.

States and Limits

• A rule name has a limit of 120 characters. A description has a limit of 500 characters.
• A priority must be an integer 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 active rule that matches wins. A later rule that matches does 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.
• You cannot edit a rule definition in place. Pause the old rule. Then 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 and no automatic rollback. When you delete or pause a rule, Eigenn does not revert the changes that it already made.
• A category action clears the saved tax amount, rate, and type on the transaction. Eigenn can then recalculate the tax for the new category. Recheck tax-sensitive matches after a rule run.

Confirm the Result

After you apply or turn on a rule:

1. Filter Transactions to the affected date, account, merchant, or category.
2. Examine the transactions that match and the 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 that newly synced transactions get the same treatment.

Troubleshoot

The rule never matches

Check the exact field that the source fills. Merchant, counterparty, description, and name are separate fields. A provider can leave one of them empty. Also check the signed amount. Then confirm that the rule is not in the paused state.

A broader rule wins

Lower the numeric priority of the specific rule. You can also raise the priority of the broad rule. Eigenn applies only the first active match.

An amount rule behaves backward

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

Old transactions did not change

A new 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.

The action list does not show a tag or category

Create the category or tag from a transaction first. Then return to the builder. A new rule cannot target a removed team member or a deleted tag.

The wrong account matches

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

Tax values disappeared after backfill

A rule that changes category clears the saved tax fields. Reopen representative transactions. Confirm the tax settings of the category. Then attach or reprocess the relevant receipt when necessary.

Related Pages

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