Quicken Downloads Showing Credit Card and other Payments as Transfers to same account
Someone posted this problem back in 2023. The problem wasn't resolved and the topic was closed.
While there was a suggested workaround from UKR to pre-schedule the payments, it didn't seem to help. I already do that with several credit card payments and other scheduled transfers and the result is typically double registry entries. There's an uncleared pre-scheduled entry and the cleared downloaded transaction with the category set as a transfer back to the same account.
It's a real problem and it has been going on for several months. It started around the time I had to do a file repair using the export import method which required reestablishing all the online bank credentials so I always assumed this was just something I needed to live with until I saw others were having the same problem last year in the closed thread.
At the time I also noticed Quicken wasn't as good at finding matching transactions as it has been. It may be a related problem.
My initial theory is it may have something to do with memorized transactions so I'm going to try to delete some of the suspicious memorized transactions with transfers as the category. I'll see if that helps.
If someone else is aware of a fix, let me know.
Comments
-
Hello @Geobrick,
You mentioned this started after you repaired your file using the export method. Did the category change in the existing transactions after you repaired your file, or is this happening only with newly downloaded/imported transactions?
If you haven't already done so, only other place to check is Tools>Renaming Rules, just in case a rule somehow got created that is changing the category after it downloads.
I look forward to your response!
Quicken Kristina
Make sure to sign up for the email digest to see a round up of your top posts.
0 -
It was only happening with the new transactions. I checked the renaming rules and don't see anything related to credit card payments. I'll update this the next time I download transactions that should have transfers. I also turned off "memorize all new payees".
0 -
Renaming Rules are Global, not account specific. So, do you see anything in Renaming Rules that pertains to your card issuer at all?
Q user since February, 1990. DOS Version 4
Now running Quicken Windows Subscription, Business & Personal
Retired "Certified Information Systems Auditor" & Bank Audit VP0 -
No. Nothing in the Renaming rules for any credit card or loan payments (or anything else that would have a transfer to another account).
0 -
Update: Two examples of the problem in one download today.
During a OSU today there was a credit card payment among the downloaded transactions. This account is not set up to automatically accept transactions to the registry so I can look at it before accepting it to the registry. I had no scheduled transaction for this payee and there are no memorized transactions for this payee. There are also no other transactions in the past where this payee was categorized as a transfer back to the same account. This is a prime example of the issue.
The bank listed the Payee as "Transfer To Credit Card -XXXX". When I clicked on the transaction in the downloaded transaction list, quicken automatically assigned it as a transfer back to the same checking account. If I click accept, that is what will be entered into the registry. I can also modify the category to the correct account for the transfer before accepting the transaction but it shouldn't be defaulting to a transfer back into the same account. Especially when the matching transaction was also downloaded into the credit card account (with its transfer also going back to the same account). Quicken is missing this easy match and mis-categorizing the transfer.
2nd example: A Zelle payment from a checking account on 5/8 is not being matched with the matching scheduled transaction already in the registry (though the date is 5/9 for that one). In the past this would easily have been matched. I had to do a "Match Manually" to avoid the duplicate entry.
Are the others who reported this problem in 2023 still having this issue? Please chime in.
0 -
" ... there was a suggested workaround from UKR to pre-schedule the payments, it didn't seem to help ... the result is typically double registry entries".
" ... I also noticed Quicken wasn't as good at finding matching transactions as it has been ...."
I have not noticed any degradation in Quicken's matching capabilities - I typically get a very high rate of accurate matches in my downloads.
But Quicken has never been perfect (and in my opinion, it never can be) at matching downloaded transactions to register transactions. When Quicken fails to match (or matches incorrectly), it's the user's responsiblity to correct the problem.
Based on the evidence supplied so far, your issue doesn't sound like a "matching" problem; nor even likely a Quicken problem.
"The bank listed the Payee as 'Transfer To Credit Card -XXXX'.".
If you have a Memorized Payee named "Transfer To Credit Card -XXXX", and that Memorized Payee has a category of [your checking account name], then that would be one way you could get the result you report.
But I believe there is another possibility.
Based on the downloaded Payee name, the formatter of the downloaded transaction "knows" (or believes) that the transaction is a "transfer". If your financial institution has put "TXFR" in the downloaded "Check#" field, Quicken will require the category of the transaction to be a "transfer category". Since Quicken would have no idea what actual account the funds were transferred to, Quicken may simply use the account where the transaction is being accepted as the "transfer category".
If that is what is happening; I think your short term choice is to modify the downloaded transaction and remove "TXFR" from the downloaded "Check#" field ... before clicking Accept.
In the longer term, you would probably need to convince your financial institution (or Intuit) to leave the "Check#" field blank for transfer transactions.
If downloaded transactions containing the payee name "Transfer To Credit Card -XXXX" should always be categorized as a transfer to the same specific Quicken account, you could probably create a memorized payee with that name and the correct "transfer category".
[If the Connection Method for the Quicken account is Express Web Connect, it's possible that Intuit is formatting the downloaded transactions; otherwise, it is the financial institution. For Express Web Connect downloads, I think you can contact Quicken Support and they should be able to determine who is formatting the downloaded transactions. If Intuit is doing the formatting, Quicken Support may be able to convey the problem to Intuit to get it corrected.]-JP
Quicken user since Q1999. Currently using QW2017.
Questions? Check out the Quicken Windows FAQ list0 -
Thanks mshiggins. you may be on to something related to the bank coding it as a Transfer, but I did not see anything in the check# field. Possibly just the word transfer in the payee name is enough to trigger this or maybe the financial institution's coding is in a hidden field. In this case the FI is Navy Federal Credit Union. I'll see if I see this same issue in other financial institutions though almost all my credit cards are paid from an NFCU checking account. This specific example is a good candidate for setting a memorized transaction because it includes the last 4 of the credit card account in the Payee name. I can try setting that up with the category set as a transfer to the correct CC account and see if it helps in the future.
My other example of the missed match of the Zelle payment could just be Quicken being quicken so I'll ignore that for now and continue to use "match manually" when needed.
0 -
[Note: Categories are never downloaded - downloaded transactions have no capability to contain a Category. All categorization of downloaded transactions occurs after the transactions have been formatted and sent to Quicken.]
" ... I did not see anything in the check# field."
Other than having "TXFR" in the check# field or having a Memorized Payee matching the downloaded (and possibly Renamed) Payee; the only other ways I know of that could cause a downloaded transaction to be categorized without user intervention are a couple of Quicken Preference options.
Look at Preferences > Downloaded transactions > During transaction download: make sure "Automatically categorize transactions" and "Automatically apply Quicken's suggested name to payee" are NOT checked.
-JPQuicken user since Q1999. Currently using QW2017.
Questions? Check out the Quicken Windows FAQ list1 -
JP, I did have "Automatically categorize transactions" so I'll uncheck that now. I still don't know why quicken would default to setting the category as a transfer back to the same account but that should go away by turning off the auto categorize setting.
1 -
Update: It's still happening and not only with Navy Federal Credit Union accounts. It happened recently with a transfer from one Chase account to another, but I found some previous memorized transactions (from before I turned off memorize all new payees). Those seem to be the cause in this case. I'm deleting them as I find them to see if I can prevent these transfers back to the same account. I'm still not sure if/why Quicken defaulted to assigning these as transfers back to the same account but once I get rid of those memorized transactions, the problem should go away.
0 -
The problem is not improving. Today an e-check paid to an individual was categorized as a transfer to the same account.
This is happening without a renaming rule or a memorized payee and with "auto categorize" and "memorize all new payees" turned off.
Actual transfers to credit card accounts get duplicated because the credit card account update includes the payment, and the checking account update includes the payment transaction. I'm sure Quicken used to be much better at recognizing these matches.
I'll have to turn off automatic entry for these problem accounts.
1 -
I agree with Geobrick. I have been getting double entries for payments to other accounts such as Credit Cards. I am seeing two identical lines the first showing payment one to "ABC" credit card and then payment two showing a transfer from the "ABC " credit card to the "ABC" credit card. For all of these duplications I have to change payment one as a transfer from checking to the "ABC" credit card then I have to delete the second payment of a transfer from "ABC" to "ABC".
This seems like a pretty basic error for Quicken to continue to be making over and over.
Am I right?
1 -
Geobrick,
When you say, "I'm still not sure if/why Quicken defaulted to assigning these as transfers back to the same account ....", I think that's kind of putting the cart before the horse. Knowing why you're getting those transfers back into the same account is the problem to be solved: if we knew that, we would have already known what to do about it.
I've never had the problem you describe, so I made some educated guesses. Earlier in this discussion I said: "Look at Preferences > Downloaded transactions > During transaction download: make sure "Automatically categorize transactions" and "Automatically apply Quicken's suggested name to payee" are NOT checked."
I don't see anywhere in your subsequent posts where you say you made sure that the Preference to "Automatically apply Quicken's suggested name to payee" was NOT checked.
I did some testing, and as it turns out, the Preference to "Automatically apply Quicken's suggested name to payee" is likely the cause of your problem.
You checked to see if "your" renaming rules were involved, but apparently you didn't check to see whether the text in the Quicken register "Payee" column contained the same payee name text that was downloaded. There are two simple ways to check that:
1.) In the dropdown that allows you to select the register fields to be displayed, put a checkmark beside "Downloaded Payee"
or
2.) Right-click a register transaction and look for "Revert to " in the resulting dropdown. If "Revert to" is present; then it will be followed by the downloaded payee name, and clicking on "Revert to" will replace the renamed payee with the downloaded payee.
In my test, I created a New Quicken file. I created no Renaming Rules or Memorized Payees, and I turned off "Automatically categorize transactions"; but I made sure that "Automatically apply Quicken's suggested name to payee" was turned ON.
Then I added one of my online credit card accounts and Accepted all the downloaded transactions. As expected, Quicken "renamed" virtually every downloaded payee. And all the transactions that were payments of the credit card bill were categorized as transfers back into the same account.
[The downloaded payee for those payments was "AUTOPAY PAYMENT - THANK YOU" - which Quicken renamed to "Autopay Payment - Thank You Xxxx-xnnnn". The "nnnn" actually contained the last 4 digits of the credit card account number.
I can't explain why Quicken would be categorizing such payment transactions at all, much less as transfers back into the same account. Personally, I'm inclined to call it a bug, since I can't think of any situation where that categorization would be correct.
So now you have a few possible ways to deal with your problem.
1.) Do as I suggested earlier and turn off the Preference to "Automatically apply Quicken's suggested name to payee".
Or
2.) Note the contents of the Downloaded payees for the problem transactions and create your own renaming rules for them. As I understand the Quicken rules, when a user-created Renaming Rule is available, Quicken will apply that Renaming Rule before any other (such as the rename that it is doing with Payment transactions when "Automatically apply Quicken's suggested name to payee"). This approach should let the user retain the names Quicken supplies whenever there is no user-created Renaming Rule available.
3.) Create a "Do not rename" Renaming Rule for those Payment transactions that are getting mis-categorized. I haven't tested this, so I'm not sure it will prevent Quicken from renaming when "Automatically apply Quicken's suggested name to payee" is on.-JP
Quicken user since Q1999. Currently using QW2017.
Questions? Check out the Quicken Windows FAQ list0 -
msiggins (JP), thanks for the detailed reply. I have looked into several of your suggestions. Back on 12 May I did post that I found "Automatically Categorize Transactions" was on but I have since unchecked that box (automatically apply Quicken's suggested name is also off).
The problem continues. When a credit card payment from my checking account is downloaded, it's defaulting to a transfer to the same checking account. When I manually change it to the credit card account, Quicken doesn't identify the existing transaction in the credit card account as a match leaving me with duplicate transactions. This was never perfect, but it has gotten much worse in the last 6 months or so. It's almost like quicken is no longer looking for matching transactions as well as it used to.
I'm pretty sure Quicken almost never defaulted to transfers back into the same account. It would just leave the category blank. The only transfers back into the same account were beginning balances for accounts.
I'll read through your post in more detail to see if I'm missing anything.
1 -
A credit card payment to a Citi credit card from my NFCU checking account was downloaded today but not automatically entered. When I click on the downloaded transaction before accepting it, it appears in the register with the category "[NFCU Checking XXxxx]". There's no memorized transactions for this and auto categorize is turned off. The transaction is initiated as an auto debit I have set up at Citi Bank to pull the monthly credit card balance from the NFCU checking account. Ideally quicken should have noticed the matching transaction in the Citi credit card account register but it should never be categorizing it as a transfer back to the same account.
I had no problem changing the category on the register to the Citi credit card account and to Quicken's credit, as soon as I did that, Quicken picked up the matching transaction in the credit card account. So no duplicate this time.
1
