Rules are how you teach Supalog's expense tracker to file specific merchants into your own categories and labels, automatically, every time. Here's what each match type means and what it actually catches.
How rules fire. Every time a bank alert lands in your Supalog inbox, we parse it into a transaction (amount, recipient, description, date). Then every active rule of yours is checked against that transaction. Any that match apply their categories and labels right away.
Where to find them. Open the Spending tab → tap Manage categories → Auto-tag Rules. Tap the + in the header to create one.
Pick the loosest match type that still keeps false positives out. Bank alerts are messy, so usually fuzzy matches or name matches wins.
contains on recipient · description Plain substring check, case-insensitive. The rule fires whenever your value appears anywhere inside the field. Use this when you know a stable keyword will be in every alert from that merchant.
netflix is exactly on recipient Strict equals, case-insensitive. Only matches when the recipient is exactly your value: no extra characters, no nearby words. Useful when a substring would catch too many false positives.
Uber fuzzy matches on recipient · description Tolerates typos, OCR noise, and weird casing. Anything that's about 85% similar to your value within the field will match. Good for banks that mangle merchant names with random codes or truncations.
sweetgreen name matches on recipient · description Word-by-word fuzzy match. Each word in your value has to find a similar word somewhere in the field. Order doesn't matter, extra junk doesn't matter. Perfect for multi-word merchants buried in messy bank descriptions.
whole foods is greater than on amount Numeric comparison on the transaction amount. The rule fires when the transaction's value is strictly greater than the number you set. Use it to auto-flag large outflows for review.
500 contains would also catch "Starbucks Reserve Roastery", which you might not want.)Whichever field you picked when you created the rule. Recipient is the parsed merchant name; description is the raw line from the bank alert; amount is the transaction's value. Most rules want recipient; it's the cleanest signal.
Fuzzy matches looks at the value as one fuzzy substring of the whole field; it's great for catching a slightly-mangled brand name. Name matches splits your value into individual words and requires each word to find a fuzzy match somewhere in the field. That one is better when the merchant name is buried in a long bank description with the words in a different order.
Contains catches every transaction that has your word in it, which can include things you don't want. "Uber" with contains would catch "Uber Eats" too. "Uber" with is exactly only matches plain rides.
Whatever the transaction amount is, treated as a number, has to be strictly greater than the value you put. So a rule with value 500 would not match a $500 transaction; only $500.01 and up.
Every matching rule applies. Categories from different rules will stack as long as each rule sets a different category. Labels stack too: the resulting transaction picks up every label any matching rule applies.
No. All text comparisons are lowercased before matching, so "NETFLIX", "netflix", and "Netflix" all behave the same.
No. Rules only run on new transactions as they arrive. If you want to re-categorize history, edit those transactions directly. The rule will keep tagging new ones from then on.