Advanced Transaction Rules: Share your feedback here!

Love to see this added!

I have two additional component ideas that would make it even better:

Additional IF:

• Date
  • On or around a certain day of month, day of week, etc (the Frequency & Occurrence tab when creating a new Recurring Series has all the options one would need)

Additional THEN:

• Link to Recurring Series
  • Link to the current upcoming or unpaid reminder within a certain Recurring Series

Question regarding the advanced rules. I've configured a rule that just adds a tag to transactions, but I noticed that other rules aren't running, specifically the ones that rename the payee. This is causing the tags to be added, but the payee names aren't being changed. Is there a way to ensure rules continue to be evaluated and aren't stopped after the first match?

Created a rule for some Apple Card transactions but Simplifi won’t apply them even though they show in the preview once I hit apply the transactions don’t update.

Hi @Coach Natalie

I've set up separate rules. The tag rule is applied more broadly, since it matches more general transactions. The other rules, where I perform actions like renaming the payee, apply to a much narrower scope. This approach reduces repetition and allows me to apply the tag regardless of other transaction rules. However, the system currently stops at the first match, preventing subsequent rules from running. As a result, matched transactions only receive the added tag and miss other actions from other rules.

Today was the first day I've logged in with the new feature enabled and I wanted to give it a try. I haven't seen one in action yet, but I did notice that the create rule screen was inconsistently defaulting some of the checkboxes. Here's what I believe I did in this order:

• Clicked +Rule from the Rules settings page to preview what the new options looked like
• Clicked the Exclude From box to view those expanded options
• Cancelled out of the new rule setup menu
• Chose Edit on an existing rule
• The Exclude From box I'd checked in the previous window before cancelling defaulted to checked like instead of defaulting to unchecked/collapsed. I expected this to be collapsed initially when opening an existing rule.
• Added a tag rule to the existing rule
• The Apply to past transactions was unchecked (as desired)
• Created rule
• Edited another existing rule
• Same experience as above up until the Apply to past transactions screen
• This time the Apply to past transactions box was defaulted to checked (NOT desired)
• I cancelled the change for now and will revisit it at a later time

While the Exclude from defaulting as checked was unexpected, there is no unexpected risk. But it seems like the apply to past transactions should default to unchecked and do so consistently to ensure users do not unintentionally change past transactions.

On a related note, I think it would be helpful to know exactly how many transactions (and ideally which transactions) are going to be updated if you select to apply to past transactions. From what I can tell, the preview window only shows you the last handful of matching transactions, which could be misleading or cause user oversight if recent behaviors/usage was different than past behaviors/usage. This could be similar to how you get another confirmation pop up when deleting a category or tag. Without the ability to search or view the original statement descriptions anywhere else in the system, you literally have to use the sample transactions provided and your own memory to decide the best option for each rule creation/change.

Thanks for continuing to improve the system and request user feedback on changes!

Hi @Coach Natalie

Here's a specific example: I have rules that rename the payee and set a category. These are simple rules, and I can have multiple of them, as seen in example screenshot 1. Now, I also want to tag transactions based on a completely different match. For instance, all transactions with the last 4 digits of an authorized user's CC should be tagged "Lia" (see screenshot 2).

Currently, once one rule is matched (likely the one adding the tag, as it's first in order), the other rules stop running. This means the payee renaming and category setting rules are not applied. As a result, I have to manually fix these, as shown in screenshot 3, where the payee was not renamed, and the category is incorrect ("Gifts" instead of "Convenience Store").

In short, I can't tag transactions without breaking other rules. I hope this is clearer than my previous explanation.

Example TX Original Statement: 6528-APPLECARE MNTHLY PLAN 888BESTBUY MN

When I select the above TX and choose to "Create Rule", the statement name changes "6528-APPLECARE" to "6528 applecare". This causes the "Contains" keywords to create two keywords. The resulting rule does not match the source transaction. I have to add the correct keyword "6528-APPLECARE". And since the payee matching logic wants the keywords in order and I don't see a way to re-order, I have to delete all of the auto-provided keywords and start over.

Original:

Create Rule:

Why are payee matches performed based on space-separated exact and ordered keywords rather than substrings? I've found many of my transactions contain noise around the most important keywords, something like:

1234-BUISINESS-888282348 some other words ach

Where 'BUISNESS" is the most likely target of a string match, but now I've got to create alternatives for all of these number variations that can't be reasonably predicted. It would be very helpful to allow a selector to specify the search string should be 'exact' or 'contains'.

Upon review of my original post, I see how there was some confusion as to what I was reporting. My intention was to point out the hyphen discrepancy.

The rule will match only when the hyphen is present in the keyword, despite what the 'original statement' display shows within the Create Rule dialog. The Create Rule dialog is stripping the hyphen for the automatically generated keywords and for the 'original statement' text, but the actual rule logic is run against the real statement name which includes the hyphen.

Given you can create keywords with hyphens, and the obvious intention of the automatically generated keywords is to match the source transaction, this appears to be a bug.