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

Multiple transaction in different accounts with the same description.

drathnow

My wife and I have accounts and credit cards with TD: I have a chequing account and credit card, she has a person chequing account and credit card and a business chequing account and credit card. We have our credit card payments set up so that they automatically get paid from each of the respective chequing accounts.

These automatic payments show up in TDs EasyWeb with the Transaction Description "TD VISA PREAUTH PYMT" in each of the chequing accounts but when I do a "One Step Update", the payee is renamed to "Td" and the money is deposited into one single credit card. This is a royal PITA and a headache to fix, especially if I miss an update because I'm out-of-town.

Is there anyway to fix this? Can I set up something that will tell quicken which credit card account to transfer money to when it sees a Transaction Description that matches the above description? For example, if Quicken encounter a transaction with the "TD VISA PREAUTH PYMT" in my chequing account it should transfer the money to my credit card and not to any other credit card.

Find more posts tagged with

Transfers

memorized payees

Accepted answers

Chris_QPW

Quicken doesn't have a way to tell what account the renaming/memorized payee applies to. When the payee's name and memo are exactly the same there isn't a way to separate them out to different categories and such using the renaming/memorized payees lists.

That is the reason for this idea that people can vote on to add that:

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

The only other way to handle this is making reminders that get put into the accounts before the downloading the transaction, so that Quicken can match that existing transaction in the register to the downloaded one, and when they are merged together it will have the payee and category of the reminder entered one.

All comments

UKR

IMHO, this really depends on any Renaming Rules and/or Memorized Payee List entries you might have defined in conjunction with the text that the bank downloads in your transactions. Incorrect definitions can really mess things up.

For best results I recommend you manually enter transfer transactions into your register BEFORE you download transactions from the bank which contain the transfer confirmations. For recurring transfers use scheduled reminders and enter them at least a day or two before the due date.
Be sure to use distinct Payee Names for each transfer / credit card payment to avoid confusing Quicken - memorized payee entries.
That takes the guesswork out of the process to create new transactions from downloaded information. Because a correctly entered transfer transaction already exists in your account registers, the download process should just match the downloaded transfer transaction to the existing one in both accounts and not cause any additional problems.

Arctic Hare

While it does sound like Renaming Rules and/or Memorized Payee List entries are playing a role in this issue, there may also be a component of how the transactions are being downloaded, e.g. is it by Express Web Connect and how are the different credit cards set up. We'd need a bunch more info on the download workflow and account set up to comment on that. For starters, are the two credit cards joint such that they are different numbers, but single statement? If so, how is that set up in Quicken and how are the transactions downloaded?

drathnow

All the credit cards and chequing accounts are separate and appear on separate statements. To download, I use the "One Step Update" under the tools menu. You will have to explain how the Memorized Payee or Renaming Rules are going to help. The transaction is in the Memorized Payee list but I can't see any way to tell Quicken which account it applies to.

All three chequing accounts have an online transaction with the text "TD VISA PREAUTH PYMT" that is downloaded when I do an update but this is translated to "Td" by Quicken and put in the Payee column. How would a renaming rule help differentiate these transactions so Quicken would apply them to the correct credit card?

Chris_QPW

That is the reason for this idea that people can vote on to add that:

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

drathnow

Thanks Chris, your solution is pretty much what I suspected would be the only way to solve this. It will be a lot of work, as I have other, similar, types of these transactions across our accounts. I think if Quicken did add a feature to tie a Memorized Transaction to a specific account, it would be really helpful.

Arctic Hare

There is something that I'm not following about this thread and the relationship to the proposed solution. The proposed solution is all about selecting a unique category based on the account in which a memorized payee/transaction is used. The word category is not used in this thread. So, what is the link between the solution and the problem.

This thread talk about matching downloaded transactions to a particular account and I'm not following that either because, regardless of how you download transactions, they download into a specific account.

What am I missing here? It is evident I am not understanding the issue.

My spouse and I have multiple bank accounts, credit cards, and do transfers between them and I don't seem to have whatever issue is being discussed here. I'm curious.

Is "auto detect transfers" not switched on? Are you automatically or manually accepting downloaded transactions into the register?

drathnow

My bank is TD so I can't speak for what happens with other institutions. Let me also say that my experience with Quicken is limited so some of this may not be entirely accurate but assumptions I've made based on my observations. Please correct me if I'm wrong.

When you setup automatic payments for credit cards (from, say, a chequing account), TD enters this transaction in your online chequing account register with the description "TD VISA PREAUTH PYMT" (Although this isn't always consistent I've found). There is nothing in the description that indicates which credit card this payment went to. If you have multiple chequing accounts, and multiple Visa cards, each transaction looks the same. When Quicken downloads these transactions, it has now way to tell which credit card is the target of the transaction. It will apply its renaming rules, and then match the Payee with some previous transaction and deposit the money into the account associated with that transaction. That means all credit card payments going to one single card.

If you enter your credit card payments manually through your banking web site (again, I'm talking about TD), you would not have this problem because TD includes the credit card account number in the transaction description. Quicken can then figure out which credit card is the target of the payment.

If I understand the solution proposed by other responders, I would have to either enter each credit card payment into their respective account in Quicken before I update from my bank. Then Quicken would be able to match the transaction from the online account with the Quicken account.

Arctic Hare

https://community.quicken.com/discussion/comment/20475690#Comment_20475690

Not exactly…

Firstly, any transaction that moves money from one Quicken account to another Quicken account [within a common Quicken data file] is a "transfer". So, in the Quicken world, your credit card *payment* transactions are "transfers" because they move money from one account tracked in Quicken to another account tracked in Quicken. So, what we are discussing here is correctly entering and recognizing "transfers" in quicken. This, in my view, has little to nothing to do with the thread that @Chris_QPW referenced. That is a different, but largely unrelated issue. Based on my understanding, this thread is about auto detecting transfers and the solution @Chris_QPW proposed is about auto assigning unique (non-transfer) categories based on the account in which a transaction is downloaded. Both valid issues, but birds of a different feather.

It might not be intuitive that, in Quicken, making a payment to a credit card account from a bank account is "transfer" because it moves money between two accounts tracked in a common Quicken data file. TRANSFER being the key concept and word here.

What, I believe, @drathnow is seeking is auto recognition of a transfer. Quicken should detect the two side of a "transfer" in the downloaded data and then ask you to confirm that it is in fact a transfer. It will recognize the transfer largely by the fact that $X leaves one account and the same $X value comes into another account - in close proximity in dates… that looks like a "transfer". If you have the appropriate settings set, Quicken will suggest that the pair of transactions is a transfer and ask you to confirm such.

I'll suggest it is a good practice, whenever practical, to enter "transfers" manually using the "transfer" function before you download the transaction data from the financial institution. However, in cases where you don't get the transfer entered manually ahead of downloading the transactions, Quicken should, normally, recognize the transfer. This is true even if one transaction has already been accepted into the register… Quicken will still suggest that they other half of the transfer, which is downloaded from a different financial institution or a day or more later as the other half of the transfer.

Here is where you can find the settings for detecting transfers.

Am I correct that what you are seeking is this auto-detect transfers functionality?

mshiggins

I recall one trick for differentiating payments to different credit cards from the same checking account is to use different cents in the payment amount: $100.01, $100.02, and $100.03 for credit cards 1, 2, and 3 respectively.

Arctic Hare

https://community.quicken.com/discussion/comment/20475693#Comment_20475693

@mshiggins the use case being discussed here is where the credit card payment is automatically created by the financial institution. That is, the OP has authorized automatic payment of the full monthly balance. So, the OP has no control over the payment amount… the FI just takes whatever amount is required to fully cover the statement balance in a pre-authorized manner. So, this is case where the user can't create unique payment amounts because the amount of payment is solely determined by the balance on the monthly statement.

mshiggins

@Arctic Hare the OP’s current method is not working, I’m suggesting an alternate method.

drathnow

I apologies for using inconsistent nomenclature and that I should have use the term "Transfer". What you describe is exactly what I'm looking for but was not what happened when I did my initial download of transactions from my bank. I'll have to wait for my next billing cycle to try it again. Maybe I messed something up.

mshiggins

@drathnow are the transfers on different days or on the same day?

Arctic Hare

https://community.quicken.com/discussion/comment/20475696#Comment_20475696

We don't know whether the OP has "auto detect" transfer turned on. That might be the issue. The OP is new to Quicken and I suspect there is some unfamiliarity with Quicken "transfers" and the feature that auto-detects potential transfers in the downloaded data. I could be wrong, but I suspect that is what is going on here.

Also, given that the payment to the credit card is automatically the amount indicated on the statement, it highly unlikely that two statements will have the same payment value. The unique payment numbers you have suggest will already exist in the current operating process, except in the incredibly unlikely scenario that two statements have the same monthly ending balance and are due on the same day - about the same chance as winning the lottery. The payment amount is already like a "random" number, so the unique payment amounts that you are proposing already exist… except in the extremely rare case that two statements had the same balance to the penny.

Arctic Hare

https://community.quicken.com/discussion/comment/20475697#Comment_20475697

Did you confirm that the transfer auto detect settings are configured as indicated?

Also, are you manually accepting downloaded transactions into the register or do you have the "automatically accept downloaded transactions into the register" feature turned ON?

Arctic Hare

It shouldn't matter whether they are on the same or different days because the values will - except in incredibly unlikely scenario - be entirely different. Quicken is primarily using the value as the means to auto-detect transfers.

E.g.

Payment of $2,347.52 from Bank Account #1 to Credit Card #1
Payment of $4,644.27; from Bank Account #2 (or #1 actually, it doesn't matter) to Credit Card #2

Regardless of same day or near proximity dates, Quickens transfer auto-detect feature should handle the above correctly, recognizing two distinct transfer transactions. I'm confident my Quicken setup would handle this seamlessly.

The two payments shown above will, of course, result in four (4) transactions downloading to Quicken into 2-3 accounts (depending on whether the payment came out of the same account). Then, Quicken should auto-detect two matching pairs - based on the common values for $ in/out and present them as potential transfers - IF the transfer wasn't manually entered in advance. IF the transfer was manually entered in advance then it is simple match that will be accepted.

If Quicken's settings are configured correctly, I can't see how this could go wrong. Quicken isn't going to propose to treat two transactions as a transfer if the values don't match. It will propose a transfer if the values match but the dates are different, however. The only way I see this getting mixed up is if the two payments were of the same value, but that, again, is an extremely remote possibility.

mshiggins

@Arctic Hare you’ve got this, have fun.