FAQ Automatic Transfer Detection Usage
I will start by saying that in my opinion the only valid use case for automatic transfer detection is when the user is using in conjunction with automatic transaction entry mode and both sides of the transfer are downloaded in the same One Setup Update session. And even then, the user might be better off not using it.
The next thing I will say is that people have understand that there is nothing in downloaded information that Quicken Windows makes use of that makes automatic transfer detection anything other than a guess based on the amounts of the transactions and the approximate dates. I have tested this and the dates of the two transactions must be within 5 days of each other.
Since this is always a guess on Quicken’s part, the user should always select the option to have Quicken confirm any automatic transfer detected.
Note the worst possible situation for automatic transfer detection is if the user has multiple transactions that have the same amount. This could be transferring say $100 frequently, or a $100 transfer at the same time you have a regular transaction for $100 or a combination of both. Better results would be obtained by unique amounts, so that say a $100 transfer will not match with a $150 ATM withdraw.
Below I will go into all the different situations where this subject comes up, and give the current recommendations, my recommendations, and merits of these and possible problems with a given use case.
For automatic transfer detection to kick in, both sides of the transfer must have been downloaded.
I will start with the only use case that I think is “valid”.
USE CASE 1: You have automatic transaction entry mode on, and both sides of the transfer download in the same One Step Update session, and the dates are within 5 days of each other. Because both sides of the transfer are downloaded at the same time, and the automatic transfer detection will kick in after the downloading of transactions, this will kick in before the user can review the downloaded transactions.
PROBLEMS with USE CASE 1: Then main ones are that it is a guess, and that it is restricted to 5 days on the dates between the two sides of the transfer. So, you can have a false match, and you can have situations where it doesn’t do automatically transfer detection at all.
Now I will go into the “invalid” use cases, and some of the ways that one might deal with transfers.
USE CASE 2a: You have automatic transaction entry mode on, and only one side if the transfer has been downloaded. You didn’t pre-enter anything and no matching memorized payees. When you finish downloading transactions you need to review the transactions downloaded. At this time, the “category” of one side of that transfer should have been entered/fixed to be [Other Account], where “Other Account” is the name of the other account that has the transaction from the other side of this transfer. Given that this is done correctly, there will already be a transaction entered into the other account that the other side of this transfer will be matched to. This matching will be before the looking for automatic transfer detection, and as such automatic transfer detection will never happen.
PROBLEMS WITH USE CASE 2a: User doesn’t do the right thing and review/fix transaction. Also, this gives no insight into cash flow, for example for use in the projected balances graph.
USE CASE 2b: The same as 2a, but there is a memorized payee that matches the payee of the transfer for the payee in the first account, and its “category” is set to [Other Account]. This works the same way as 2a, except that when reviewing the user will find that Quicken has already set the “category” correctly.
PROBLEMS WITH USE CASE 2b: Memorized payees are global, but for this to work right [Other Account] must be the “right category”. Say you have two credit cards that are paid from the same checking account, and the credit cards payments download with the same payee. What is most likely to happen is that the payments will first show up in each of the credit cards accounts. Provided that the memorized payee is [Checking Account] then this will work for both credit card accounts. But do notice that the memorized payee is entered in relationship to it being entered in one of the credit card accounts. If the payee is the same in the Checking account, and it gets processed first then it would get a category of [Checking Account] in the checking account, which would be wrong. This situation only comes up if the payees are the same and if in the same One Step Update session the downloading of the Checking account side of the transfer happens first. The other way this would mess up is if you were paying the two different credit cards from two different checking accounts and the payees in the credit card accounts were the same. This use case also does not have anything for predicting cash flow.
USE CASE 2c: Same as use case 2a, but you either pre-entered a transfer transaction, or had a reminder do that for you. In this case, you should be matching the existing transactions in the registers. Note that this does give information to be used in cash flow.
PROBLEMS WITH USE CASE 2c: Some transfers amounts aren’t known beforehand and only an estimate can be entered. For Quicken to match a downloaded transaction the amount must be exact. If the amounts aren’t exactly what the user must do is change the amount in the pre-entered transaction to match the one downloaded, and then click on the Status/blue dot column for the pre-entered transaction and select Manual Match, which will bring up a dialog to match this transaction with the downloaded one. The two transactions will then be merged.
USE CASE 3a: Automatic transaction entry mode is off, no pre-entered transactions, and no memorized payees. As you can guess these use cases are going to closely resemble the 2 use cases, so I will mostly deal with what is different. When you have Automatic transaction entry mode off, you will be dealing with one account at a time, as such you shouldn’t have the situation where automatic transfer detection ever kicks in, provided you do the right procedure (Use case 1, should never occur!). Transactions go to the Downloaded Transactions tab at the bottom of the register. The proper procedure is to chick on each transaction in the Downloaded Transactions tab and it will be shown in the register. At this time if the “category” for a transfer isn’t [Other Account], you should change that before accepting the transaction in the register. Once you do that, Quicken will also create a linked transaction in the other account and when going through that account Quicken will match the downloaded transaction to this one that is now in that account.
PROBLEMS WITH USE CASE 3a: The same as same as 2a, no cash flow prediction, and the user needs to follow the right procedure. The worst thing someone can do is use Accept All without first making sure that all the transactions are correct. If you use Accept All none of the transactions will have any kind of status that indicates that they are new or new matched, like they would if automatic transaction entry mode was used. Accept All and Automatic transaction enter mode are not the same thing!
USE CASE 3b: This is the same as 2b with exception that you have automatic transaction entry mode off. Instead of “Reviewing” you are selecting the transaction in the Downloaded transactions tab and if correct accepting it into the register.
PROBLEMS WITH USE CASE 3b: The same as with USE CASE 2b.
USE CASE 3c: Basically, the same as USE CASE 2c, with the only real difference being that instead of selecting the Status to start the manual match you would first just change the amount in the pre-entered transaction and Quicken should then change the one in the Downloaded Transactions tab to “Matched”. And you can then accept it into the register.
PROBLEMS WITH USE CASE 3c: The same as USE CASE 2c.
This is my website: http://www.quicknperlwiz.com/