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 matching rule applies.

This guide uses a cautious lifecycle: observe, create paused, backfill a bounded window, inspect, then enable.

Before You Start

Prepare:

• several transactions that should match
• at least one near-miss transaction that should not match
• the target category, tag, or owner
• the exact merchant, counterparty, description, name, or amount pattern from the source
• a priority plan for existing rules

Manually correct representative transactions before automating them. See Reconcile and Categorize Transactions.

Rule Model

Every rule has:

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

All conditions use AND semantics. Active rules are evaluated from the lowest priority number to the highest, and the first match wins.

1. Start from Source Fields

Open matching and nonmatching transactions in the detail sheet. Compare:

• Merchant
• Counterparty
• Description
• Name
• signed Amount
• Direction
• account identity

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

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

Signed amount examples

Direction is derived from the amount: zero and positive values are Money in; negative values are Money out.

2. Design for Specificity

Prefer the smallest rule that captures the intended pattern without catching neighbors.

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 merchant names are shared, 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. Avoid it unless that identifier has been independently confirmed.

3. Choose Actions Deliberately

The builder can:

• set one category
• add one tag
• assign one member
• mark matches internal with Exclude from analytics

At least one action is required. 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 add the desired final state rather than relying on a later rule to clean it up; later matching rules 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 an operating convention, not a product requirement. 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. Read “Every condition must match” literally.
4. Choose the actions.
5. Review the condition and action preview.
6. Resolve all validation pills.
7. Choose Create rule.

Starting paused prevents the rule from affecting the next sync before its recent-history behavior has been inspected.

6. Backfill a Test Window

In the Rule library, choose the play control for the paused rule. The per-rule action can run while a rule is paused.

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 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 and inspect both matches and 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. Enable and Verify 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 newly arrived period.
4. Confirm the intended rows changed and near misses did not.
5. Check which rule would win when conditions overlap.

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

8. Monitor the Library

The top metrics show:

• total 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:

• adding or renaming categories or tags
• changing account structure
• a provider changes merchant or description text
• a teammate leaves
• reports show a sudden classification shift

Replace a Rule

Existing rule definitions cannot be edited in place.

Use this replacement sequence:

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

The Duplicate control immediately creates a paused copy with the same definition and a priority one number higher, capped at 1,000. It does not load that copy into an editor, so duplication is useful for preservation or parallel activation, not for changing the definition.

Pause or Delete

• Pause stops automatic and workspace-wide active-rule evaluation. The per-rule play control can still be run manually.
• Delete removes the rule immediately and has no confirmation or undo.

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

Prefer pause during investigation. Delete only after the replacement and historical effects are understood.

Maintenance Limits

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

Troubleshooting

The rule is active but new transactions do not change

Confirm the source field is populated on the new transaction, every AND condition matches, and a lower-numbered rule is not winning first. Compare the exact source text with an older transaction that did match.

Run workspace rules reports fewer updates than matches

A matching rule can add a tag that already exists or choose actions that do not require a transaction-row update. The workspace result separates scanned, matched, updated, and tagged work internally, while the UI emphasizes scanned and 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 using the same conditions, correct the affected transactions in bulk where safe, and create a narrower replacement.

The replacement never runs

Check whether the paused old rule was re-enabled or whether another 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 targeting an active member, verify it, then pause or delete the old rule. Existing assignments are not cleared automatically.

Historical transactions outside the scan window need correction

Manual rule runs are limited to the newest 2,000 transactions. Use carefully scoped transaction filters and bulk actions for older rows, or contact support before attempting a large historical correction.

Success Checklist

• matching and near-miss examples were inspected
• the rule started paused and was backfilled intentionally
• priority makes the specific rule win
• category, tag, owner, and analytics treatment are correct
• tax-sensitive rows were rechecked
• newly synced transactions follow the rule
• the replaced rule is paused or deleted only after verification

Related Pages

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