Quicken Downloads Showing Credit Card and other Payments as Transfers to same account

Options
Geobrick
Geobrick Member ✭✭✭

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

  • Quicken Kristina
    Quicken Kristina Moderator mod
    Options

    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.

  • Geobrick
    Geobrick Member ✭✭✭
    edited May 8
    Options

    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".

  • NotACPA
    NotACPA SuperUser ✭✭✭✭✭
    Options

    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 VP

  • Geobrick
    Geobrick Member ✭✭✭
    Options

    No. Nothing in the Renaming rules for any credit card or loan payments (or anything else that would have a transfer to another account).

  • Geobrick
    Geobrick Member ✭✭✭
    Options

    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.

  • mshiggins
    mshiggins SuperUser ✭✭✭✭✭
    Options

    " ... 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 list

  • Geobrick
    Geobrick Member ✭✭✭
    Options

    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.

  • mshiggins
    mshiggins SuperUser ✭✭✭✭✭
    Options

    [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.

    -JP

    Quicken user since Q1999. Currently using QW2017.
    Questions? Check out the Quicken Windows FAQ list

  • Geobrick
    Geobrick Member ✭✭✭
    Options

    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.

  • Geobrick
    Geobrick Member ✭✭✭
    edited May 25
    Options

    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.