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)

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

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.