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
• set one GL account code
• add one selected tag from the builder
• assign one workspace member
• mark the transaction internal with Exclude from analytics
• mark the transaction ready to sync

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.

A GL code action posts against the workspace chart of accounts. See Transaction Coding for the chart, the coding dimensions, and the constraints that can restrict a value.

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 summary.
8. Choose Preview matches and read the dry run.
9. Start with Enabled off when the match is broad or unproven.
10. Choose Create rule.

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

Preview matches

A rule is a standing instruction over the whole ledger, so save-and-find-out is an expensive way to learn that it was too broad.

Preview matches reports how many of the recent transactions scanned would match, and lists each affected transaction with the field changes as from → to.

The preview evaluates the draft alongside the team's enabled rules, so the result reflects real precedence rather than the draft alone.

A row can also report that you already set a field by hand. A human edit outranks a rule, so the rule would not change that field.

The control stays disabled until the rule has a complete condition and at least one action.

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.

Run workspace rules scans up to 5,000 transactions in one pass. The per-rule action covers that rule's matches. 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.
• Preview matches dry-runs the draft rule against recent transactions before you save it. The preview evaluates the draft alongside the team's enabled rules, so it reflects real precedence rather than the draft in isolation.
• You cannot edit a rule's conditions or actions in place. You can pause and resume a rule. To change the definition, 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, but it does revert. Eigenn drops the rule's claims, clears the fields it set, and re-runs the remaining rules over the affected transactions so the next-best rule, or nothing, takes over. Pausing a rule does not revert its earlier changes.
• 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.

Find Out Which Rule Won

Open a transaction and read its Coding trail. The trail names the rule that set each field, and the rules that matched but lost, with the reason:

Use the trail when a coded value is not the one you expected. It tells you which rule to change. See Transaction Coding.

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

Open the transaction's Coding trail to confirm which rule won and why. Then lower the numeric priority of the specific rule, or raise the priority of the broad rule.

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. One workspace pass scans up to 5,000 transactions, so a large ledger can need more than one pass.

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