nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Renaming Rule repeatedly ignored despite matching downloaded payee

rcleonard

I'm having a reproducible problem with a downloaded transaction that Quicken refuses to rename.

Downloaded Payee: DIRECT DEBIT SPOTSYLVANIA WATER

Renaming Rule:

If payee contains: SPOTSYLVANIA WATER
Rename to: Spotsylvania Water

Actual result: The Downloaded Transactions queue displays Direct Debit Spotsylvania Water, without quotation marks, with status New.

The rule appears valid but isn't being applied.

I've performed several controlled tests:

Confirmed that Use my existing renaming rules is checked in Downloaded Transactions preferences.
Confirmed that the rule is saved and visible in the Renaming Rules list.
Restored the previous day's Quicken backup and downloaded the transaction again. Same failure.
Changed the condition to the complete bank description, DIRECT DEBIT SPOTSYLVANIA WATER. Same failure.
Disabled Automatically categorize transactions while keeping existing Renaming Rules enabled. Same failure.
Deleted the original rule and created a completely new one with a different output name, SW Rename Test. Same failure.

The downloaded transaction remains New, not Match

There is an ordinary Memorized Payee entry for Spotsylvania Water, but no conditional Memorized Payee rule. I've also confirmed there is no Do-Not-Rename rule.

Other Renaming Rules have worked, so I don't believe the entire feature is disabled.

My question: What could cause Quicken to bypass an enabled, valid Renaming Rule for a genuinely new downloaded transaction? Is there another matching or processing mechanism that takes precedence? Any help would be greatly appreciated.

I'd particularly appreciate insight from anyone familiar with Quicken's renaming-processing sequence. My understanding is that rename happens up front, taking the raw, unaltered downloaded transaction from the bank, changing the payee if the rule is met, and then the transaction is put into the downloaded transaction queue for the user. All seems so easy, but I've been beating my head against the above for a while now.

[Edited - Readability]

Find more posts tagged with

Windows

download transactions

Renaming Rules

Comments

Sceptic

@rcleonard What happens if you change the renaming rule to.

If payee contains: DIRECT DEBIT SPOTSYLVANIA WATER
Rename to: Spotsylvania Water

[Edited - Readability]

Quicken Kade

Hello @rcleonard,

I understand how frustrating it can be when rules don't seem to work, and I would be happy to help investigate it further. To start, I would like to gather some additional information to better understand the situation and determine the best next steps.

Where is your Quicken data file located? Is it saved locally on your computer or stored on a cloud service such as OneDrive or Carbonite?
Is this issue occurring only with this particular payee/rule, or are you experiencing it with other payees/rules as well?
How long has this been happening, and has the renaming feature worked correctly for this payee/rule in the past?
Have you verified that no other renaming rule contains "SPOTSYLVANIA" in either the "Contain" or "Rename" field?

Here is an article on how to check where your data file is located. The additional details you provide will help us narrow down the potential cause and determine the most appropriate solution. Thank you for your time and cooperation.

I look forward to your response!

rcleonard

My .QDF file is at: "C:\Users\rcleo\OneDrive\Documents\Quicken\Laptop_QDATA.QDF" which was quite a surprise to me. IIRC the .QDF must be on a local drive, right? Am pretty sure I saw to it that it was local (like user/roaming) but it was a long time ago. I never (intentionally) use OneDrive. So if this is a problem, how do I fix it?

[Edited - Readability]

rcleonard

Have not been able to get a payee into the Downloaded Transactions queue with a payee other than Direct Debit Spotsylvania Water, no matter the rename choice (Spotsylvania Water, Water, Electricity, whatever).

[Edited - Readability]

Quicken Kade

Thank you for your response.

Based on the information you provided, I recommend starting by moving your Quicken data file off of OneDrive and then validating the file to check for potential issues.

To begin, please follow the instructions outlined in the support article provided. Once your data file has been moved, we can proceed with validating and repairing it. As shown in the attached screenshot, select the Validate file checkbox and click OK to begin the process.

Once these steps are complete, please let me know the results so we can determine the appropriate next steps.

Thank you for your time and cooperation!

rcleonard

The new path: C:\Users\rcleo\AppData\Roaming\Quicken

The new path did not fix my problem but was a much-needed improvement. I have had OneDrive logged out forever, and when asked, OneDrive says it isn't connected. Guess I killed it long ago. Also, I validate my .QDF before backing up to Dropbox after every run; no errors now.

[Edited - Readability]

rcleonard

[Tue Oct 27 20:31:22 2026]

File: "C:\Users\rcleo\AppData\Roaming\Quicken\Laptop_QDATA"

QDF:
Validating your data.
No errors.

QEL:
No read errors.

QEL:
All internal consistency checks passed.

[Tue Oct 27 20:32:07 2026]
Maximum security reference: 180, number of securities: 180.
Analyzing securities.
All security references are within the normal range.

Validation has been completed.

UKR

The new path: C:\Users\rcleo\AppData\Roaming\Quicken

AFAIK, that is NOT a recommended storage path for your Quicken data file.
Reinstalling Quicken may wipe the Appdata\Roaming\Quicken folder, and you may lose your QDF file.

The recommended non-OneDrive path is C:\Users\rcleo\Documents\Quicken\

rcleonard

Thanks, and good point. I did a quick search, and my choice was a recommended selection but less favored than what you suggest. I was familiar with the app/roaming use for Thunderbird, so I went with it.

I'll move it to C:\Users\rcleo\Documents\Quicken\ to avoid the possible loss on reinstall you described.

Meanwhile, I've made no progress on my rename problem. Seems so simple … IDK

UKR

If you're not getting anywhere with your Renaming Rules, here's a possible alternative:

You already have Direct Debit payments set up with the individual utilities, correct? And these debits download like clockwork on or about the due date.

To work around the non-working Renaming Rules, try this:
For each direct debit, set up a Scheduled Reminder and record it a couple of days before the direct debit arrives in a download. This gives you a correctly named and categorized register transaction. When the download arrives, Quicken should be able to match the download with the register transaction, and you'll have the results you're looking for.

[Edited - Readability]

rcleonard

Yes, that should work. I've discovered that for a "pre-recorded (future dated)" transaction, the Payee name makes no difference. The downloaded transaction will match on date (not necessarily exact) and precise amount. If the pre-recorded date is changed to the downloaded date, the type in the queue will change from New to MATCH (given the amount matches). If the date is correct but the amount is different, changing the amount of the pre-recorded transaction to match the downloaded one also results in MATCH. However, I'm still looking to make it work properly.

[Edited - Readability]

Quicken Kade

Hello @rcleonard ,

Thank you for following up on this. I understand that you are still looking for a permanent resolution to this issue, and I would like to help move the investigation forward. To do so, I would appreciate it if you could revisit my original response and provide answers to the remaining questions below:

Is this issue occurring only with this particular payee/rule, or are you experiencing it with other payees/rules as well?
How long has this been happening, and has the renaming feature worked correctly for this payee/rule in the past?
Have you verified that no other renaming rule contains "SPOTSYLVANIA" in either the "Contain" or "Rename" field?

Your answers will help us narrow down the potential cause and determine the best next steps toward a resolution. Thank you for your time and cooperation. I look forward to your response.

Chris_QPW

I recommend answering @Quicken Kade 's questions and seeing where that might lead, and I don't want to interfere with that process, but I see some confusion about what the process is (even though I think you figured out some of it), and as such I'm going to put that down here.

Renaming rules are applied as one of the first things after the transactions are downloaded. And that is before you see them. This makes troubleshooting them a pain, because as you have noted, the only way to "retry" is to restore from a backup. But renaming the payee has nothing to do with matching existing transactions. And as you have noted, from the best we can get from the process (because Quicken Inc. never exactly states anything about internal things like this, so the users have to guess), at most the payee's name is a "very slight hint". At least, some people have claimed that I have never seen that; it is totally ignored as far as I have seen. And yes, the source for the payee's name is the downloaded one, which you can see if you turn on the field/column in the register.

Looking at all the things you have tried, the one thing I would try is going the opposite way on the renaming rule. Try SPOTSYLVANIA or even WATER. And see if you get it renamed. Going from "SPOTSYLVANIA WATER" to "DIRECT DEPOSIT SPOTSYLVANIA WATER" makes it less likely to match. In the first case, it is looking for two words in a row, and in the second case it is four words. Fewer words make it more likely to match, and then rename, but of course risk renaming too many payee names. But for a test, less is the way you want to go. This logic is why I would have skipped "Disabled Automatically categorize transactions". If this one kicked in, the payee would have been renamed, just not to the one you intended. This option kicks in only if your renaming rule doesn't match.

The relationship between the renaming rules and the memorized payee list is that the memorized payee has to be exact except for case. So, the renaming rules are normalizing the payee names so that they will match a given memorized payee and therefore allow for categorization.

Again, this "matching" isn't the "Match" on the transaction status.

The "Match" status opposed to "New" is when a downloaded transaction matches a transaction that has been pre-entered into the register. And as you noted, that is done by the exact amount and approximate date. It has nothing to do with the payee's name getting renamed or the memorized payee matching and setting the category (and possible tag, memo, …)

It would be interesting to see if another workaround would work. When they changed the memorized payee to have account and amount rules, they also added the ability to change the payee's name. So, you might be able to set up a memorized payee with "DIRECT DEPOSIT SPOTSYLVANIA WATER" and select this:

[Edited - Readability]

rcleonard

Hello @Quicken Kade , @Chris_QPW , @UKR,

I think I found something that explains this. I'm not the first to encounter this bug.

Renaming rules work on my Wells Fargo Visa account. For example, "Total Wine 208 POS" is renamed to "Total Wine" as expected.
How long, and whether it ever worked for this payee: I can't tell. For years I've removed "Direct Debit" by hand when accepting Fidelity transactions, so my register history can't show whether any rule ever fired on this account.
Other SPOTSYLVANIA rules: there is one other rule, "Spotsylvania County CTAX," with condition Spotsylvania CTAX. Its output wasn't applied either. The queue showed the unmodified downloaded text.

The problem(s) I reported were associated with my Fidelity-linked cash account (Banking). It's paired with the investing account "RCL CFL Fidelity Cash Mgt EFT," which connects via Express Web Connect. Other users report the same symptom: renaming rules ignored on Fidelity-linked cash accounts after the EWC+ cutover:

Renaming rules for Fidelity still not fixed in R67.7: https://community.quicken.com/discussion/7973651/renaming-rules-for-fidelity-still-not-fixed-in-r67-7
Renaming rules still not working for linked cash account (R68.31): https://community.quicken.com/discussion/7975398/renaming-rules-still-not-working-for-linked-cash-account

I'm on R69.53 (build 27.1.69.53) and the problem continues.

Could you confirm whether this is a known issue, give a reference number if there is one, and say whether a fix is scheduled? If it isn't a known issue, I'm happy to run any test you suggest. I keep a pre-download backup so I can repeat a fresh download on demand.

[Edited - Readability]

Chris_QPW

Yep, it looks like you found the problem.

EDIT: Linked checking accounts add the complication of the fact that the cash transactions are actually downloaded into the investment account and then "pushed" to the linked/virtual checking account.

Quicken Kade

Hello @rcleonard,

Great catch! Thank you for the insight in your post.

After reviewing your provided information, I do agree that this seems like what you are experiencing. The good news is it's already been escalated, and our teams are working toward a resolution.

Unfortunately, we do not have an ETA as to when it will be fully resolved. We apologize for the inconvenience and appreciate your patience as we work towards a solution.

Thank you.
[CTP-17482/QWIN-27960]