Automation rules apply a classification or another update when a transaction matches a trigger. Use this guide to control where rules run, avoid overly broad matches, and fix unexpected results.
For the basic setup, see Automations: Creating and Assigning Classification Rules.
Two points to remember: conditions currently use OR logic. Deleting a rule does not undo classifications it already applied.
1. Choose the right scope
Open Subledger > Automations > Classification.
Check the scope shown beside each saved rule.
Scope | Where the rule applies | When to use it |
Entity | Across the entity's transactions | The same accounting treatment is valid across the entity. |
Connection | Only the selected wallets or accounts | Treatment depends on the wallet or account. |
For example, a rule for one treasury wallet should use Connection scope. Two rules with the same name can cover different connections.
To create a rule with the intended scope, click + Classification Automation. Create the target classification in your Chart of Accounts first.
Choose Entity or Connection, then click Next. Entity setup asks for a name and optional description. Connection setup also asks you to choose its sources.
For a connection rule, enter a clear name. Choose Wallets or Accounts, then click Select under Automation sources. The example is an unsaved rule for a selected Solana wallet.
Select the intended sources and click Choose. Review the selection count on the setup screen, then click Next.
2. Define a narrow trigger
A trigger says which transactions qualify. An update says what the rule changes.
Start with one condition you can check against a real transaction. In this example, choose Transaction tag, Is, and fees. Use the actual tag stored on your transactions.
Under Update Type, choose Classification, then select the intended classification. Check the classification's accounting treatment as well as its name.
3. Understand OR logic before adding conditions
OR means that one matching condition is enough. AND would require every condition to match. Rules currently use OR only. The comparisons Is, Is Not, and Is Empty belong to one condition; they do not change how multiple conditions are joined.
Suppose you add these two conditions:
Transaction tag Is fees.
Transaction type Is receive.
The rule can match a fee-tagged transaction or any receive transaction within its scope. It does not require a receive transaction to have the fee tag.
Fee tag matches? | Type is receive? | OR rule matches? |
Yes | No | Yes |
No | Yes | Yes |
Yes | Yes | Yes |
No | No | No |
The screenshot below shows this broad trigger as a warning example. Do not activate it as a fee-classification rule.
Adding conditions can widen the match. A date condition is not an AND-based safety boundary for another condition. Splitting two conditions into two rules does not make them behave as AND either.
When every condition must be true, review the matching transactions with filters and apply the approved classification manually, or confirm a supported approach with Support. Do not assume an AND option exists because an older example uses the word “AND.”
4. Check when the rule runs
Rules based on Cost Basis, Proceeds (Sale Price), Fee Value, or Unit Value need Post calculation automation rules enabled. These rules run after calculation completes. A normal connection sync does not provide that completed-calculation checkpoint.
Before activating the rule, click Next and read the summary. Check the affected connections, trigger, update, and classification treatment. Click Confirm only when the rule is ready to apply. The example below returns to the single fee-tag condition.
5. Check a saved rule before running it
Find the rule and click View.
Confirm its scope and trigger. All transactions in the portfolio identifies an entity-level rule in this view. Check that its classification still has the intended treatment.
Normal classification rules can apply as connections sync. To apply one saved rule manually, use Run on its row. Review that rule before running it. Use Run All only when every active rule is ready.
After the run finishes, open Transactions and find the records that should match. Compare their Classification with the expected result. Check at least one matching transaction and one that should stay unchanged. Do not rely on the rule's name as proof that it worked.
6. Delete a rule without losing track of earlier changes
Deleting a rule stops it from applying to future transactions. It does not remove or restore classifications already applied to earlier transactions.
Before deleting, keep the rule details and the transaction IDs you need to review. Open the arrow beside the rule and choose Delete. Use Edit instead when you need to change the rule for future use.
Read the warning, then click Delete if you intend to remove the rule. Use the close button to cancel.
If earlier classifications were wrong, review and correct those transactions separately. Changing or deleting the rule is not a rollback. Keep valid classifications in place. For closed or posted periods, follow your approved correction process before unlocking or changing records.
When a rule does not work as expected
What you see | What to check | What to do |
No matching transactions change | The entity, rule scope, and selected wallets or accounts | Open View. Compare the rule's sources with a transaction's actual connection. |
A transaction looks relevant but does not match | The stored field, exact value, and comparison operator | Check the actual tag, address, type, or other trigger field. A missing value cannot satisfy an exact-value match. |
Older transactions remain unchanged | Whether the rule has run against them | Review the rule, use its Run action where appropriate, then inspect the transactions again. |
Calculation-based fields are unavailable or the rule has not fired | The post-calculation option and calculation status | Enable the option for those fields and wait for a completed calculation. |
Too many transactions change | Multiple conditions joined by OR, or entity scope where connection scope was intended | Stop using the broad rule. Narrow its scope or trigger, then review earlier changes separately. |
The result is an unexpected classification | Other applicable rules and the classification's treatment | Review overlapping rules. Do not assume an undocumented priority or execution order. |
A historical record cannot be changed | Its lock status and whether the period is closed or posted | Use the approved close-correction process. Do not unlock a period just to test a rule. |
The classification stays after deletion | The rule's earlier updates | This is expected. Correct the affected records separately if needed. |
If the rule still fails, contact Support with the rule name, entity, connection, one transaction ID, the expected result, the actual result, and the run time. Include a screenshot of the rule details.