Maintain Transaction Rules

Transaction rules turn repeated corrections into deterministic workspace policy. Maintenance matters because an active rule runs on newly synced transactions, and only the first rule that matches applies.

This guide uses a cautious lifecycle: observe, create the rule paused, backfill a bounded window, check it, then turn it on.

Before You Start

Prepare:

• Some transactions that must match
• At least one near-miss transaction that must not match
• The target category, tag, or owner
• The exact merchant, counterparty, description, name, or amount pattern from the source
• A priority plan for the current rules

Correct some representative transactions by hand before you automate them. See Reconcile and Categorize Transactions.

Rule Model

Every rule has:

• A name and an optional description
• One or more conditions
• One or more actions
• A priority from 0 through 1,000
• An active state or a paused state

All conditions use AND semantics. Eigenn evaluates active rules from the lowest priority number to the highest. The first match wins.

1. Start from Source Fields

Open the detail sheet for a transaction that matches and for a transaction that does not match. Compare these fields:

• Merchant
• Counterparty
• Description
• Name
• Signed Amount
• Direction
• Account identity

Use the field that is stable across the source records. A bank can populate Merchant for one payment method and only Description for another.

Text operators are case-insensitive. Regular expressions are also case-insensitive. An empty source field does not match a positive text condition.

Signed amount examples

Eigenn derives Direction from the amount. Zero and positive values are Money in. Negative values are Money out.

2. Design for Specificity

Use the smallest rule that captures the intended pattern but does not catch neighbor transactions.

Good first rule:

Merchant contains “Amazon Web Services” AND Direction equals Money out → Category Infrastructure

Risky first rule:

Description contains “service” → Category Software

Add conditions when transactions share a merchant name, amounts vary by direction, or accounts have different reporting treatment. OR logic and nested groups are not available, so create separate rules for valid alternative patterns.

The Account condition compares a stored bank-account ID, not the display name. Do not use it until you confirm that identifier independently.

3. Select the Actions with Care

The builder can:

• Set one category
• Add one tag
• Assign one member
• Mark matches as internal with Exclude from analytics

Each rule must have at least one action. A single rule can combine these actions.

The builder cannot remove a category or tag, clear an owner, or reverse a prior internal flag. Create rules that set the final state you want. Do not depend on a later rule to correct the result. Later rules that match do not run after the first match.

4. Set Priority

Lower values run first. Reserve lower numbers for exceptions and higher numbers for defaults.

An example priority scheme:

• 0–49: exact exceptions and internal transfers
• 50–249: named vendors or customers
• 250–499: account or amount patterns
• 500–1,000: broad review defaults

This is a convention. The product does not enforce it. What matters is that specific rules beat broad ones.

5. Create the Rule Paused

Open Transactions → Rules.

1. Turn Enabled off.
2. Enter the name, description, and priority.
3. Add every condition.
4. Read “Every condition must match” literally.
5. Select the actions.
6. Review the condition and action preview.
7. Resolve all validation pills.
8. Select Create rule.

When you start the rule paused, the rule cannot change the next sync. This gives you time to check its behavior on recent history.

6. Backfill a Test Window

In the Rule library, select the play control for the paused rule. You can run this action on a paused rule.

Important behavior:

• It is a real write, not a preview
• It scans at most the 2,000 most recent workspace transactions
• It applies the rule's category, tag, owner, and internal treatment to the matches
• There is no automatic undo

For a broad or high-impact change, export the affected working set first. After the run, use filters that reproduce the rule's conditions. Check the matches and the near misses.

If the rule changes category, Eigenn clears saved tax amount, rate, and type on each updated transaction. Recheck tax-sensitive rows and their receipts.

7. Turn On the Rule and Confirm New Syncs

When the backfill is correct:

1. Turn the rule's switch on.
2. Run a manual bank sync or wait for the next provider sync.
3. Filter Transactions to the period that arrived last.
4. Confirm that the intended rows changed.
5. Confirm that the near misses did not change.
6. Confirm which rule wins when conditions overlap.

Active workspace rules run when Eigenn upserts synced transactions. Run workspace rules also applies every active rule to the recent manual-scan window in priority order.

8. Check the Library

The top metrics show:

• Total rules and paused rules
• Active rules
• Backfill-ready rules
• Multi-condition rules

Use library filters to review Active, All, Backfill, Specific, or Paused rules. Search matches names, descriptions, condition summaries, and visible action summaries. Sort by priority, specificity, name, or newest.

Review the library after:

• You add or rename a category or a tag
• You change the account structure
• A provider changes its merchant text or description text
• A teammate leaves
• Reports show a sudden classification shift

Replace a Rule

You cannot edit a rule definition in place.

Use this replacement sequence:

1. Pause the old rule.
2. Create a new paused rule with the corrected definition.
3. Backfill the newest 2,000 transactions.
4. Check the result.
5. Turn on the replacement.
6. Keep the old rule paused until a new sync confirms the replacement.
7. Delete the old rule only after the audit window is complete.

The Duplicate control immediately creates a paused copy. The copy has the same definition and a priority one number higher, to a maximum of 1,000. Duplicate does not load that copy into an editor. Use it to preserve a rule or to activate a rule in parallel, not to change a definition.

Pause or Delete

• Pause stops automatic evaluation and workspace-wide evaluation of active rules. You can still run the per-rule play control by hand.
• Delete removes the rule immediately and has no confirmation or undo.

Neither action reverts categories, tags, owners, or internal flags the rule already applied.

Use Pause during an investigation. Delete a rule only after you understand the replacement and the historical effects.

Maintenance Limits

• Name: 1–120 characters.
• Description: up to 500 characters.
• Priority: integer from 0 through 1,000.
• Conditions: AND only. At least one condition is necessary.
• Actions: at least one. The current builder selects one category, one tag, and one owner.
• Match behavior: only the first active rule that matches applies.
• Manual scan: newest 2,000 transactions.
• No dry run, no undo, no in-place change to a definition, and no automatic historical rollback.
• Regular expressions must be valid before creation.
• Amount comparisons use signed values.

Troubleshoot

The rule is active but new transactions do not change

Confirm that the new transaction has a value in the source field. Confirm that every AND condition matches. Confirm that no lower-numbered rule wins first. Compare the exact source text with an older transaction that did match.

Run workspace rules reports fewer updates than matches

A rule that matches can add a tag that already exists. It can also select actions that need no update to the transaction row. The workspace result separates scanned, matched, updated, and tagged work internally. But the UI shows only the scanned counts and the updated counts.

The per-rule run changed too many transactions

Pause the rule immediately. There is no automatic undo. Filter the recent 2,000-row window with the same conditions. Correct the affected transactions in bulk where this is safe. Then create a narrower replacement.

The replacement never runs

Confirm that nobody turned on the old paused rule again. Confirm that no other lower-priority rule matches first. The replacement needs a lower number than any broader competitor.

A removed teammate still appears in an old rule summary

The rule stores the member identifier. Create a replacement rule that targets an active member. Confirm the replacement. Then pause or delete the old rule. Eigenn does not clear the current assignments automatically.

Historical transactions outside the scan window need correction

A manual rule run scans only the newest 2,000 transactions. For older rows, use carefully scoped transaction filters and bulk actions. Contact support before you try a large historical correction.

Success Checklist

• You checked the examples that match and the near-miss examples
• The rule started paused, and you ran a planned backfill
• The priority makes the specific rule win
• The category, tag, owner, and analytics treatment are correct
• You rechecked the tax-sensitive rows
• The newly synced transactions follow the rule
• You pause or delete the replaced rule only after you confirm the replacement

Related Pages

• Transaction Categories and Rules
• Transactions
• Reconcile and Categorize Transactions
• Bank Connections
• Connect Transaction Records
• Support