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; } } }

Payments being Auto Categorized as Transfers to Same Account (screenshot included)

Geobrick

I know I've posted on this issue before. I've also seen a few similar threads going back several years but there has never been a fix posted, and the threads have been closed. The suggested workarounds to schedule known transfers in advance helps a bit, but the underlying problem doesn't only affect internal transfers. Sometimes it's Zelle payments or some other outgoing payments being categorized as transfers to the same account.

I've been using Quicken for a long, long time and prior to this issue, the only time I have ever seen quicken create a transaction with a transfer back to the same account is for opening balance transactions when adding a new account.

In the cases shown below, Quicken shouldn't put anything in the category column. It should be blank. How is this happening and why does it seem limited to just a few of us?

The auto categorizing of deposits and payments as transfers to the same account are happening with, 1) No category information in the downloaded data, 2) Auto Categorize set to off, 3) No memorized transactions with transfers as the category and, 4) "Complete fields using previous entries" is unchecked.

Here are some screenshots with examples. They are downloads using OSU that were not automatically entered into the register (though if they were, they would be entered as they appear below). The transactions are selected but not yet accepted.
(Hopefully redacted enough to hide personal info while showing details of the issue)

2024-08-06 Quicken Auto Categorize Self-Transfer Issue (70).png

2024-08-06 Quicken Auto Categorize Self-Transfer Issue (71).png

2024-11-24 Quicken Auto Categorize Self-Transfer Issue (79).png

These are all from my NFCU checking account, but I've seen it happen to some of my Chase accounts too.

Find more posts tagged with

Windows

Transfers

Comments

UKR

The only advice (and fix for this problem) I can give and have always been giving is:

Manually record your transfer transactions, correctly categorized with the Transfer-To/From account name, enclosed in [square brackets], e.g. [ABC VISA] BEFORE you download and auto-accept transactions into your register.
Alternatively use a Scheduled Reminder if this transfer is a recurring event.
This way you will have valid register transactions, properly named and [categorized], already existing in your account registers when you download either half of the transfer transactions.

As far as I can determine, the way the programmers dance around the issue of trying to build a valid linked transfer transaction pair, based on the cryptic downloaded payee name text, is by creating an unlinked transfer to the same account. When the other half of the transfer transaction in the other account downloads a day or two later, another unlinked transfer to same account will be created, too. This way your account balances in the registers will not be upset by creating duplicate linked transfer transactions.
Anything else would require a crystal ball. The program code used for making sense of downloaded transactions just can't handle it.

Chris_QPW

I saw this problem today, and it is "worse" than you might think @UKR because "manual entry" will not fix it.

Here is what happened to me. I have a credit card payment that first hits the credit card account. It gets downloaded, and is properly recorded. As in with a transfer from the Checking account to the Credit card account.

So, I have an "existing" transaction in the Checking account with this transfer. Now a couple of days go by, and that transaction is downloaded into the Checking account. It shows up as a new transaction with the "transfer account" being set to the Checking account!

If I do a manual match of the existing transaction, it has no problem matching with the downloaded one in the Checking account. It just didn't do the automatic match correctly.

UKR

https://community.quicken.com/discussion/comment/20463617#Comment_20463617

Hmmm … this only happens to me when the Date of the register transaction is still in the future.
I can see this happen on a deposit transaction, scheduled for 3rd Wednesday every month. For the last several months, the bank deposits this ACH transaction up to 3 days early. So, when I download (on the Monday before 3rd Wed.), the early transaction downloads as "New". To make it "match", I have to change the transaction date to the downloaded transaction's date … and all will be well.

Quicken Kristina

Hello All,

Thank you for taking the time to visit the Community to report this issue, though we apologize that you are experiencing this.

We have forwarded this issue to the proper channels to have this further investigated. In the meantime, we request that you please navigate to Help > Report a problem and submit a problem report with log files attached and (if you are willing) a sanitized copy of your data file in order to contribute to the investigation.

While you will not receive a response through this submission, these reports will help our teams in further investigating the issue. The more problem reports we receive, the better.

We apologize for any inconvenience!

Thank you.

(CTP-11608)

Geobrick

@UKR, I do some manual entries for credit card transactions when I know it's going to be a significant amount, so I'll know if I need to move money into the checking account to cover them. These will typically match-up with the downloaded transaction. I appreciate Quicken trying to find matching transfers. I have the detection turned on (but set to let me confirm possible detections). It seems to work well in most cases but prior to a year ago, I've never seen anything get auto categorized as a transfer back to the same account except for opening balances. In the past, if Quicken didn't know how to categorize a transaction, the category would remain blank. That should be the case now, especially if Auto Categorize is off.

As @Chris_QPW says, sometimes the credit card account downloaded transaction hits before the date of the transfer from the checking account. In my case when this happens, I'll get a separate deposit in the credit card account that's categorized as a transfer back to the same credit card account.

It's one thing to think this is Quicken's awkward way of detecting transfers but why would a Zelle payment get auto categorized as a transfer back to the same account (see my 2nd screenshot)?

I'd like to continue posting examples as more of these occur, so I hope the mods don't close this discussion until it's resolved, or I give up (again).

Quicken Kristina

Thanks for your reply @Geobrick,

Discussions are closed after roughly 30 days of being inactive. The best way to keep the discussion open is to post at least once every 3 weeks.

That said, this issue has been reported and the ticket will remain open until the issue is resolved, even if this discussion is closed.

I hope this helps!

Chris_QPW

Note that my transactions have always come in this exact same way since I have the setup for automatic payment (from the credit card side), Citi credit card, payment hits first, then a day or so later it hits the checking account. So, the transaction/date for the credit card account is always before the one that hits the checking account. This problem is pretty new, I remember only seeing it one other time.

And now that have double checked it, I realize the "matching" didn't work right either.

Look at this:

Citi credit card account:

And when I do "go to matching transfer" it goes to the checking account and shows this transaction:

So, not only didn't it match automatically, when I match manually it created this "broken transfer".

Geobrick

https://community.quicken.com/discussion/comment/20463674#Comment_20463674

That broken matching transfer along with UKR's speculation that the coders may be creating unlinked transfers as place holders until its future match is downloaded may be a hint to where the problem lies. I'll have to check for that.

Geobrick

I can't be sure what I've done specifically, but things seem to be improved over the last month. Here's one thing I remember doing; I deleted all my memorized payees and started recreating new ones specifically for transaction that involve transfers. It seems that as long as the bank keeps using the same descriptions for the transaction, the new memorized payees will work to help quicken use the correct transfer account in the category field of the downloaded transactions.

There were no specific memorized transactions I was aware of that could have caused transfers back to the same account but maybe there was some hidden memorized transfer transactions or some sort or file corruption that caused the problem and deleting all the memorized transactions corrected the issue. I'll keep an eye on this to see if it continues to improve.

Quicken Kristina

Thank you for the follow-up,

I'm glad to hear that deleting memorized payees and adding ones specifically for your transfer transactions has helped to reduce the issue.

Thank you!

GTClover

I have the same problem! This currently only happens for me with Transfers between Bank Accounts within the same bank (Business, a Money Market, and a regular checking account). And Credit Card payments from those accounts to different credit card accounts that are all Capital One Credit Cards, 2 of which are Master Cards & 1 Visa. All transactions are downloaded using Express Web Connect). Sometimes this results in the amount being entered back in the same account; sometimes it results in being correctly recorded as a transfer matched to the correct account for both (Bank account or CC account) and other times as an “unmatched” transaction in the correct CC account or worse incorrectly into the wrong Capital One account which causes a mess in all the registers of accounts affected!

I'll try to use some of these suggestions, but judging by the number of 'closed' discussions on the subject it seems this problem goes back at least 5 years. It would seem to me that the "Quicken Team" should have found a solution by now. I'm a minuscule company compared to some on this platform so it's easier to manually change the affected account, but I thought that since I'm paying Quicken to to figure out what is going wrong & fix it, right?

UKR

https://community.quicken.com/discussion/comment/20470619#Comment_20470619

Are you automatically accepting downloaded transactions into your registers?
You should, at least for a while, turn off the "automatically accept downloaded transactions into registers" setting to gain better control over what is downloaded and what to do with it. Click on and review each downloaded transaction, make changes if necessary (e.g., to get a payee name = "Starbucks" instead of "POS TRANS 070124 STARBU", "POS TRANS 070224 STARBU", "POS TRANS 070324 STARBU", etc. or to assign a category or fix up a transfer) before you click to individually accept each new transaction.

Geobrick

https://community.quicken.com/discussion/comment/20470619#Comment_20470619

Deleting all my memorized transactions seemed to work for me. It has been over a month since I did it and I haven't seen a 'self transfer' since. I saw an improvement the next time I did a OSU. I would get the expected blank when the category was unknown. Even on transfers. Quicken even detected a few transfers on it's own. No more transfers back to the same account so far.

I slowly started memorizing transactions again over time as new transactions were downloaded (especially if they were transfers between accounts). It seems to be working as expected. I'll provide an update if anything changes or just to let people know if it's still working.

@GTClover, Back up your file and try it. Let us know if it helped.

Chris_QPW

I encountered this a day or so ago, and I think I fully understand what is going on now.

Quicken's renaming rules/memorized payee don't allow for specifying what account to apply them to.

So, let's look at a typical transfer if one memorizes it.

In the register:

In the memorized payee list:

This all well and good as long as the transaction first hits the credit card account, but if it hits in the checking account first, then it is going to put in the self-referencing/balance adjustment transaction, which can't be connected to the credit card account.

A memorized payee like this can work for the situations where there is a delay between when it hits the credit card account and the checking account (provided you download in between that period of time), but without being able to control what account this memorized payee for you are basically asking from trouble if you memorize any transfer.

Currently there are really only two safe options. 1) Manually enter transaction. 2) Have a reminder enter the transaction.

On that score you might be interested in voting on this idea:

https://community.quicken.com/discussion/7854603/memorized-transactions-or-renaming-rules-by-account-2-merged-votes

Geobrick

Chris_QPW, I think that's just part of the issue I've experienced.

I've shown cases were there was nothing related to a transaction in the memorized payee list, yet the transaction would be entered as a transfer to the same account. There were times the transaction was just a payment and not even a transfer to another account.

In the past, quicken would never auto-categorize a transaction as a transfer back to the same account. The only transactions I'd ever see as transfers to the same account were Opening Balance transactions.

Since cleaning up the memorized transactions renaming rules, I have not been seeing this problem. Now, even when a credit card payment hits the checking account and doesn't match an existing transaction in the credit card account, it no longer gets auto categorized as a transfer back to the same account. It is working well in 3 of my 4 quicken files. I don't know why the 4th one still has this problem.

It's working so well now, Quicken actually finds matches on its own again.

The only remaining problems with matching are when a credit card payment hits the CC account before the checking account but even then, I'm not seeing any transactions being auto categorized as self-transfers. They are entered with no category.

I also get the situations where a scheduled CC payment is in the register with a future date and the payment hits the checking account (or the CC account) a day or two early and quicken won't consider it a match unless you manually match it or adjust the date on the scheduled transaction. But all that is minor compared with the auto-categorizing self-transfers I was getting on a daily basis.

GTClover

I cleared out most of the Memorized Payees that involved bank transfers or credit card payments in my preferences. & so far so good. I won't say solved until a couple of months (rounds of transactions) go by, but I'm pretty sure you correct in that being the source of the problem. Thanks Everyone!

Randy 415

Same problem here. I can't upload a sanitized data file as it is too large.

Geobrick

I mentioned how things are working well in 3 of the 4 Quicken files I manage.
Here are some recent examples from that 4th QDF file. In this case, the transactions aren't transfers or credit card payments yet they get auto-categorized as self-transfers. These are Venmo payments from a chase checking account.

And again a week after I corrected the above categories…

I'm glad it's working in 3 of my files but I really can't say that deleting the memorized payees and the renaming rules was the fix because I did that in the 4th file as well. There must be something else I changed.

Chris_QPW

https://community.quicken.com/discussion/comment/20476229#Comment_20476229

Click on the Venmo payee and then type Ctrl+T. I'm pretty sure that will take you to a memorized payee with [Chase Checking XX5717] saved as its category.

If correct, and you are wondering how it got there, then the most likely reason is because you have this option on:

Edit → Preferences → Data entry and QuickFill → Automatically memorize new payees

Note that if you actually want Quicken to automatically memorized new payees, but not change the Venmo one when you edit transactions, then edit the memorized payee to remove the category and select to lock that memorized payee.

Geobrick

https://community.quicken.com/discussion/comment/20476230#Comment_20476230

Chris_QPW, I wish it was that easy. There are no memorized payees and 'automatically memorize new payees' has been unchecked.
It seems like some sort of phantom-ghost-bug that auto-categorizes random transactions as transfers to the same account.
I don't really know why it doesn't happen anymore on my three other qdf files but it's still happening with the file shown in my last post.
I no longer have the problem in the file shown in the first post in this this thread. I thought deleting all the memorized payees and renaming rules is what fixed it, but as you can see above, I didn't. There must be some setting that I changed in three of my files that I didn't change in the 4th but again, with no memorized payees or renaming rules, what setting would ever make quicken add a self-transfer as a category rather then just leaving it blank?

Chris_QPW

@Geobrick Well in that case I'm sorry I'm out of ideas. There aren't any other settings that I know of.

Geobrick

Here's a new one from Wednesday. I sorted by date descending so the newer entries are on top (closer to the name of the account on top).

Screenshot 2025-02-15 at 10.13.08 AM.png

[Edited - Removed Personal Information]

Quicken Kristina

Hello @Geobrick,

https://community.quicken.com/discussion/comment/20476471#Comment_20476471

This issue has already been reported and is in work. Currently, we do not have an ETA.

Thank you!

(CTP-11608)

skelplevel

Clearer Explanation: Quicken will randomly select a Category for downloaded transactions then fill all categories with that category. Locally we have a convenience store called WAWA. Quicken categorized all downloaded transactions as Medical:Co-pay:Paul not the saved Category. The transactions do not need to be blank. Quicken will re-categorize all downloaded transactions as Medical:Co-pay:Paul.

Quicken can grab another Category randomly and start using it as the default Category for all downloaded categories rather than grabbing the saved Category.

Also, manually entered transactions will not be auto-filled with the correct Categories. Manually entered transactions must have the Category entered, otherwise it will be blank. Here is an example of a downloaded WAWA transaction:

This is an example of what a downloaded WAWA transaction should be:

Geobrick

https://community.quicken.com/discussion/comment/20476575#Comment_20476575

This could be a related problem but my post is referring to Quicken auto-categorizing transactions as transfers back to the same account. Transfers back to the same account is something that is almost never needed to happen (let alone getting auto-categorized that way). The only time it's typically used as designed is for the opening balances of newly added accounts.

In your case, check your memorized payee list or renaming rules to see if you see anything associating WAWA to the category "Medical:Co-pay:Paul". Also fix any past WAWA transactions that still have the category set to "Medical:Co-pay:Paul". Then make sure "Auto categorize transactions" is unchecked under the 'preferences:downloading transactions:During trasnsaction download'. If that all checks out and you still have this problem, then it is similar to what I'm experiencing.

GTClover

I too continue to have problems and that Quicken is working on a fix!! Keep us posted.

Geobrick

https://community.quicken.com/discussion/comment/20481078#Comment_20481078

I haven't heard of any fix yet but hopefully one is on the way. This used to affect all four of my qdf files but now only happens in one of them. The Venmo transaction I showed as an example is the clearest indication there's something wrong.

Quicken Kristina

Hello @Geobrick,

The ticket is still open and in work. Currently there is no ETA and I'm not seeing any updates yet.

Thank you!

(CTP-11608)