Transfer anomaly

oldngrmpy1

I'm having trouble with account transfers through Quicken, but everything is okay in my accounts from the financial institution end and reconciles fine. I'm asking this question here because I've read posts where people are having account balances that are not balancing, and this in fact could be the result of my problem that, and might be hard to notice at first look. 

I'm using V32.10, PC is current on all updates, and my CU is impeccably accurate, always!  I use Express Web Connect. During the month I will go to the CU website and transfer
- Checking to Visa,
- Checking to Savings,
- Checking to Xmas Club.
After the transfers come through Quicken they may be from the wrong account or to the wrong account in my account registers, always! This didn't stat happening until about 2 months ago. I used to use Memorized Payees, and or Renaming rules and they used to always come out correctly in my register.

I just today deleted the Memorized Payees and Renaming rules that I had set pertaining to transfers to see if that will help. It seems lately I've been slowly whittling away at Quicken features in order to get Quicken to work even in it's most basic form. I gotta ask why?

I have sync set to off and am using Quicken in it's basic form just as bank register, and that even isn't working correctly. A year ago everything worked much better.. until the new improved Mobile and Web came out.

The foundation for even the basics seems to be crumbling beneath the behemoth structure that has been constructed. So what exactly is the protocol when an user experiences this kind of problem? Where should a user of over 20 years with a problem like this actually start with the protocol, and what are the correct steps in the support process trying to get this issue rectified? What should be the correct order when using,: Community (ask a question), 1-800, (chat or call), or the ongoing (Question Answered) post for 32.10 sync problems. I'm at a point I don't know where to go!

Chris_QPW

To add to what @splasher said I want to also point out about "transfer matching".  This is a guess on Quicken's part. It is mostly based on the amount and partially the date.  If you have transfer matching on, you should certainly have "confirm" on.

I will also state the way I handle transfers.  For predictable transfers like paying my credit card accounts, I setup reminders for them, and when I get a statement I usually updated the next instance amount with it, but I'm always checking them/matching them to the real downloading because first off I have caught Quicken reverting the amount back to the default number.  And second if I have a return after the statement close then I will be paying less than what was on the statement.

For "non predictable" transfers I generally enter them before hand.  Sometimes I do get lazy when I'm just transferring money between my savings and checking account and let transfer detection pick them up (with confirmation).  But in that case they are in the same financial institution and come down at the same time (usually the next day), and never an amount that I will mistake for something else (as pretty large, and very "rounded" amounts).

BTW as a side note, a problem that came in from the recent switch over in USAA to a different security system/processing brought the fact that the OFX protocol actually does have a "transaction type" for transfers.  And looking at that standard they could put "hints" into where the transfer is going.  But of course it gets extremely "unlikely" that a program can really figure out what the "other account" is when the transfer is between different financial institutions.  And Quicken makes no attempt to use such information.

The problem with what USAA was sending was that they were sending the "Transfer type" for every transaction.  And Quicken was actually setting the check number/reference number to TXFR, this in turn locked the category to only transfers.

But one can immediately see a problem with this even if the "Transfer type" is sent correctly.  Imagine you do a transfer to an account that isn't in Quicken.  You would probably want that to be a regular category or a balance adjustment transaction.

This is the first time I have ever seen that in Quicken, and the fix seems to be that they changed all transaction type back to normal debit/credit types.

NotACPA

PLEASE PLEASE PLEASE use some white space in your messages.  I went cross-eyed trying to read this post ... so I stopped reading it.

Ps56k2

Did a little editing - to make it easier for all of us -

splasher

There is nothing in the download from the FI that indicates that a transaction is a transfer, either in or out, so it would only be by using very precise Renaming Rules and Memorized Payees to get them created from the downloaded transactions.

Personally, I use my FI's bill pay system and schedule them ahead of time and  I manually enter my transfers from saving to checking or checking to credit and then match the downloaded transactions when they happen and are downloaded.

Seems to me that you think Quicken is smarter then it really is.

Chris_QPW

To add to what @splasher said I want to also point out about "transfer matching".  This is a guess on Quicken's part. It is mostly based on the amount and partially the date.  If you have transfer matching on, you should certainly have "confirm" on.

I will also state the way I handle transfers.  For predictable transfers like paying my credit card accounts, I setup reminders for them, and when I get a statement I usually updated the next instance amount with it, but I'm always checking them/matching them to the real downloading because first off I have caught Quicken reverting the amount back to the default number.  And second if I have a return after the statement close then I will be paying less than what was on the statement.

For "non predictable" transfers I generally enter them before hand.  Sometimes I do get lazy when I'm just transferring money between my savings and checking account and let transfer detection pick them up (with confirmation).  But in that case they are in the same financial institution and come down at the same time (usually the next day), and never an amount that I will mistake for something else (as pretty large, and very "rounded" amounts).

BTW as a side note, a problem that came in from the recent switch over in USAA to a different security system/processing brought the fact that the OFX protocol actually does have a "transaction type" for transfers.  And looking at that standard they could put "hints" into where the transfer is going.  But of course it gets extremely "unlikely" that a program can really figure out what the "other account" is when the transfer is between different financial institutions.  And Quicken makes no attempt to use such information.

The problem with what USAA was sending was that they were sending the "Transfer type" for every transaction.  And Quicken was actually setting the check number/reference number to TXFR, this in turn locked the category to only transfers.

But one can immediately see a problem with this even if the "Transfer type" is sent correctly.  Imagine you do a transfer to an account that isn't in Quicken.  You would probably want that to be a regular category or a balance adjustment transaction.

This is the first time I have ever seen that in Quicken, and the fix seems to be that they changed all transaction type back to normal debit/credit types.

oldngrmpy1

Something changed in the last couple of months, as up until then I never had this problem. I was using same Memorized Payees, and Renaming Rules. I just today deleted both of those so I will see what happens now. When I go to mu CU site, I just move $xx.xx from acct 1 to acct 2. I have acct 1 and acct 2 (that transaction set up in Memorized Payees) and Renaming Rules also. Now I will try letting Quicken use what it wants to use...