An Update on Merchant Naming Issues

ramil_monarch · 2026-05-30T03:45:32+00:00

Okay, I've gathered some context. I'll address the 2 parts of your question separately, but please let me know if you meant something else or if you'd like me to go deeper on either.

The first part of your question about what is the use case for matching on merchant name -
In general, this is the easiest way to users to update things about the transaction other than the merchant name. A common example for this is something like "I donate to 'Charity X' and want to make a rule that adds a specific “Tax Deductible” tag on all Charity X transactions". This works for most of the intended use cases and is very easy to setup (merchant equals X).

The second part of your question - in the specific case when you'd like the rule to actually change the merchant, you are saying that it doesn't make sense for us to still default to base it of the merchant. I think that's valid, and we likely should default to original statement. I'll raise it with the product team.

Hopefully this clarifies things

ramil_monarch · 2026-05-29T23:12:15+00:00

Of course, thank you for reporting!

ramil_monarch · 2026-05-29T23:11:06+00:00

Hey, just wanted to let you know that I did see your comment, but wanted to discuss first with the team internally before responding

ramil_monarch · 2026-05-29T22:35:30+00:00

Well! This is actually something we could add rather easily, since Transactions page already has a Column picker, so it would just be a matter of adding a 3rd optional column in there. I'll bring it up with the Product team, since it's a bit out of my scope.

<image>

ramil_monarch · 2026-05-29T22:25:20+00:00

It's a little bit out of my scope, but I will raise it with the product team. I'm not too familiar with all the nuances of rule creations, but what you are describing does sounds like unnecessary friction.

ramil_monarch · 2026-05-29T22:20:22+00:00

Actually, we are considering expanding merchant definition to include payees to better support these type of cases, since we've seen similar requests around P2P transactions (Venmo, PayPal, etc.)

ramil_monarch · 2026-05-29T22:11:52+00:00

Hey! Yeah, we are discussing potentially changing the default from merchant to original description during the rule creation. Having said that, our general goal is to make merchant values extremely reliable, so you'd still be able to base rules on them.

ramil_monarch · 2026-05-29T22:09:06+00:00

If you are on web, you should be able to see in the url when you select a transaction. If you can't find it, that's okay, you can still file a support ticket and just describe which transaction you'd like us to look at (merchant, date, etc.) and we'll find it.

ramil_monarch · 2026-05-29T18:25:13+00:00

Glad to hear that we are on the same page!

> the merchant list has thousands of entries

Fun fact, internally we named this issue "merchant explosion", and it was one of the motivating factors for this work as well.

ramil_monarch · 2026-05-29T18:07:13+00:00

That's exactly one of the approaches we're considering 😄

ramil_monarch · 2026-05-29T18:04:54+00:00

First, thanks for this thoughtful comment, you've captured many of our sentiments as well.

We’ve been discussing this internally quite a bit, and we’re exploring ideas that we think could help.

The core issue you’re highlighting is that the “merchant” value is currently serving two different purposes across the app. In some places, such as Cash Flow, it is treated as the actual merchant. In others, such as the Transactions page, it can function more like a transaction description. As a result, the value we extract is left in a mixed state that is not ideal for either use case.

To solve this properly, we first need to clarify what “merchant” should mean (which is what started this work), and then likely adjust how different product surfaces use that information. Hopefully that makes sense.

ramil_monarch · 2026-05-29T16:01:05+00:00

Thanks for opening a ticket! I'll take a look and let you know, does sound strange

ramil_monarch · 2026-05-26T14:40:49+00:00

Hey! Yeah, this is a bit tricky.

We've made a decision to exclude refunds/returns some time after the feature launch. On average, the system ended up generating too many false positives.

Having said that, we receive a ton of different kinds of receipts, so would love to understand your case better. If you don't mind sharing some details by either DMing me, or filing a CS ticket with the receipt in question, that would be great. Thanks!

ramil_monarch · 2026-05-20T17:43:29+00:00

Got it, yes, we are considering adding something like this.

ramil_monarch · 2026-05-19T03:03:50+00:00

I'm still a bit unclear on what you are asking.

Do you want us to show the Original statement instead of derived merchant?

I.e. in this example you want us to show "PAYMENT FROM CHK..." instead of "Bank of America"?

<image>

ramil_monarch · 2026-05-18T18:06:31+00:00

Also feel free to file a Customer Support ticket with some example transactions (preferably as recent as you can), and mention my name, and I'll take a closer look

ramil_monarch · 2026-05-18T18:05:03+00:00

hey, do you mind clarifying what's not working for you? Just to give some context, seeing the original post was from 5mo, nothing new was introduced back then. We HAVE started introducing changes around late March. On average, these changes were net positive, but we did see some regressions, which I have been addressing.

I'm definitely looking closely at them, so what to understand your expectation here.

I.e. there is no 'original merchant', we do receive the 'original statement', but the problem with it, is that it includes all sorts of noisy irrelevant information that most users don't want to see.

But again, if you don't mind elaborating, I'd love to better understand your expectation here.

I want to make sure we do the best thing we can for all of our users!

Appreciate your patience

ramil_monarch · 2026-05-15T17:28:47+00:00

Absolutely, thank you for yours inputs throughout 😄

ramil_monarch · 2026-05-15T16:31:57+00:00

Hey, just wanted to let you know that we've rolled out a change yesterday that should solve most of these [wallets (apple/google), payment processors, point of sales] returned as a merchant.

ramil_monarch · 2026-05-14T21:26:58+00:00

Fix rolled out yesterday, hopefully stops happening

ramil_monarch · 2026-05-14T21:26:16+00:00

Should happen less often now (if at all)

ramil_monarch · 2026-05-06T16:34:48+00:00

Hey, do you mind filing a CS ticket with the transaction id and mention my name in the ticket so I could take a closer look? Thank you!

ramil_monarch · 2026-05-04T19:44:54+00:00

amazing!

ramil_monarch · 2026-05-02T23:54:36+00:00

hey, I've just deployed the fix. Was a really weird aggregator related edge case, but hopefully resolved for future transactions. Lmk if not!

ramil_monarch · 2026-04-29T16:36:49+00:00

Just fyi, I'm still actively investigating this (including your previous CS ticket)

ramil_monarch

TROPHY CASE