Request change to Transfer Money function

Herrick Inman

When transferring money from an account at one bank to an account at a different bank, the credit and debit sides of the transaction typically occur on different dates. However, the existing Transfer Money function forces the user to specify the same date for each side. The Transfer Money function should be modified to allow the user to specify different dates for each side of the transaction.

Boatnmaniac

@Herrick Inman - If you wish to suggest a product improvement change, click on the triangle just to the right in the blue "Ask A Question" button in this Community.  Then click on "New Idea" and post your idea. 

This process will post it in the correct category where others can view and vote up the idea if they like it.  (You should also vote up your own ideas posted there.)  The voting button shows up directly beneath the post and looks like this:

The Quicken team reviews ideas posted there and the more users who vote up the idea the more likely it is that Quicken will put it into their product development plans.  The Quicken team will also eventually post a status on the idea (such as, Under Consideration, Planned, Not Planned, etc.).

I actually like your idea and will vote for it if you do post it.

volvogirl

I can't see how that would work.  2 different dates would make it 2 separate transactions.  

You need to run them through holding account.  Set up a new account called Funds in Transit.  Then transfer the money into it.  Then when it posts on the other account, transfer the money out of the holding account to the receiving account.

q_lurker

@Herrick Inman  The issue has been raised before - as long ago as 13 and 14 years ago as far as I can see.  

The dilemma I have with using different dates is the short term impact on net worth.  What would you propose to do to maintain proper net worth across this delay? @Volvogirl 's suggestion of an 'in-transit' account is accurate but more trouble than I would choose to go with. 

As such, I am comfortable (and prefer) maintaining the single date.  For me, this is analogous to checks clearing the bank.  I write the check on Monday (and deduct it from my register then) but it doesn't clear the bank for days, weeks, or months later when the recipient deposits it and it works it way through the system. 

FWIW:  Old time prior posts (that you may or may not be able to get to:
https://community.quicken.com/discussion/7101592/newbie-double-entry-for-transfers-due-to-transit-time 
https://community.quicken.com/discussion/7090402/can-matching-transfer-transactions-have-different-dates

Herrick Inman

You're right. It won't work the way Quicken currently implements Transfer Money. That is why I want Quicken to allow me to change the REGISTER dates of the credit and debit sides of a transfer, AFTER I execute Transfer Money. It would then be up to me to decide if and when I change the two register dates.

In the real world, the typical external transfer is debited from one account on one date and credited to a different account on a later date. Quicken refers to the corresponding credit and debit transactions as "matching transfers." Currently, if I change the register date on one side of a matching transfer, the register date on the other side is automatically changed to the same date, which is undesirable as it does not reflect the way an external transfer occurs in the real world.

I had already considered your suggestion. It entails more work for me than simply allowing me to change register dates independently after I do a Transfer Money.

aquickuser

Instead of an "in transit" account you could set up a category called banktransfer (or whatever works for you) . Record the transaction in the sending account as a withdrawal with a payee of the receiving bank and a category of banktransfer.
Record the transaction in the receiving account as a deposit with the sending bank as payee and the banktransfer category. The two transactions will zero out the banktransfer category and Each transaction can have its own date.

Boatnmaniac

I do agree with @volvogirl that what is suggested would be separate transactions because the reality is that is what they are...one transaction in the sending account and another in the receiving account.  But Quicken doesn't recognize that and treats them as the same single transaction.

I also do agree that it's probably not feasible to enter one date in one account and then go to the other account and modify it because that would break the transfer link and that would break a lot within Quicken.  It needs to be addressed differently so it doesn't break the transaction link between the two accounts. 

The current Quicken band-aid using what I call "a dummy Cash account" or what @volvogirl calls "a holding account" is workable but it is not a solution.  I use it but I don't like it.

We (and perhaps Quicken) need to think outside of the current box some on this.  The part that would need to be addressed is the bridge linking the two dates during the transaction set up. Where there is a will there is a way and the basic concept of what has been suggested can be done.  Heck, it is so incredibly easy to do this in Excel and every ERP system in existence utilizes this concept extensively.  It's a simple calculation process where the date in the originating account is entered along with the number of days (commonly referred to as lead-time) for the transfer to be completed in the other account.  ERP systems classify the transfer lead-time as in-transit assets (cash, inventory, etc.) and account for it that way in their financials so there is absolutely no gap in net worth and P&L calculations.  Why can't Quicken do the same?

The question is not "Can it be done?" but "How much effort (and cost) would it take for Quicken to design and implement it?"

Maybe the effort and cost required to implement a change like this will be too great but maybe not.  How will we know what Quicken and others think of this idea if it is not thrown out there for consideration? 

I do know that doing transfers with only one date or the other has caused me register balance and planning issues too frequently and I absolutely hate that.  I've also seen a number of other users over the years state a desire to see a change like this, too.  So, yes, I would absolutely and wholeheartedly support this suggested change provided it is done correctly.

Boatnmaniac

Herrick Inman said:

You're right. It won't work the way Quicken currently implements Transfer Money. That is why I want Quicken to allow me to change the REGISTER dates of the credit and debit sides of a transfer, AFTER I execute Transfer Money. It would then be up to me to decide if and when I change the two register dates.

In the real world, the typical external transfer is debited from one account on one date and credited to a different account on a later date. Quicken refers to the corresponding credit and debit transactions as "matching transfers." Currently, if I change the register date on one side of a matching transfer, the register date on the other side is automatically changed to the same date, which is undesirable as it does not reflect the way an external transfer occurs in the real world.

I had already considered your suggestion. It entails more work for me than simply allowing me to change register dates independently after I do a Transfer Money.

@Herrick Inman - I understand your reluctance to use the band-aid solution offered in this post thread but for now, if you want/need to have real transfer transaction dates in each account, it is the only solution available.  Even if the Quicken team were to start immediately planning (which is not going to happen) for some capability in this area it would be many months (likely years) before we would see it in Quicken.  And the reality is that the Quicken team could very well deny the request.  So, for now we need to live and work with either the same dates in both accounts or the band-aid dummy Cash account.

NotACPA

"The current Quicken band-aid using what I call "a dummy Cash account" or what @volvogirl calls "a holding account" is workable but it is not a solution."

Actually, a "Cash Items in Transit" account exists at every bank that has ever employed me or hired me as a consultant.

It's VERY workable.

Herrick Inman

What you call “VERY workable” creates so much extra work for me that I might as well just skip the Transfer Money feature and instead manually create a debit transaction and a matching credit transaction for each ACH transfer so that I could easily change the register dates to accurately reflect the posting date of the debit and the posting date of the credit.

Boatnmaniac

Herrick Inman said:

What you call “VERY workable” would create so much extra work for me that I might as well just skip the Transfer Money feature and instead manually create a debit transaction and matching credit transaction for each ACH transfer so that I could easily change the register dates to accurately reflect the posting date of the debit and the posting date of the credit.

What you are asking for and what I support is a functionality that does not exist in Quicken today...and that is not going to change anytime soon, if at all.  So we all need to do what we are reasonably comfortable with and that reasonably approximates the result we want/need to see.  I do think you are greatly overestimating the amount of work that is involved with the dummy Cash account process compared to the process you are thinking of using.  @NotACPA is right in that it is a very workable option, but it is not ideal.  Do what you want to do but I think you would regret not at least trying it.

Boatnmaniac

NotACPA said:

"The current Quicken band-aid using what I call "a dummy Cash account" or what @volvogirl calls "a holding account" is workable but it is not a solution."

Actually, a "Cash Items in Transit" account exists at every bank that has ever employed me or hired me as a consultant.

It's VERY workable.

As do many, many businesses, especially those with multiple facilities and far flung financial operations.  But the current band-aid process will only become a real solution if it can be somehow automated so a single transaction can be entered to accomplish what we now do manually with two transactions...or what we don't do at all because we've become accustomed to having inaccurate transfer transactions data in our accounts.

I do about 20 transfers each month in 4 different data files.  If I were to use the dummy Cash account process we now have for each of these it means I would have a total of 40 transfer transactions each month and I would be constantly managing 4 additional Cash accounts that I should not need to manage.  While it is workable it is inefficient and time consuming.

NotACPA

"I would be constantly managing 4 additional Cash accounts"

Why would it take 4 accounts?  Run them all thru a single "CIT": (Cash Items in Transit) account.

q_lurker

NotACPA said:

"I would be constantly managing 4 additional Cash accounts"

Why would it take 4 accounts?  Run them all thru a single "CIT": (Cash Items in Transit) account.

(Four different data files)

I am still failing to see the problem with having the money show up "early" in the receiving account or go out "late" from the sending account.  Especially with respect to the approximate 2-day transfer time.  (Meaning it is not a problem for me.  YMMV). 

@Boatnmaniac wrote earlier

I do know that doing transfers with only one date or the other has caused me register balance and planning issues too frequently and I absolutely hate that.  

Is this because you are recording these some weeks in advance?  Such is not my usage style.  

Chris_QPW

When I look at how "fragile" transfer linking is (as shown by all the problems I have seen with it over the years) I would really "fear" if they add this extra layer to them to do this directly.

There is another way to do this, but no one is going to like it, but then again I don't see anyone liking anyone else's suggestions here.  

If you go back to the original double book accounting there isn't any "transfer".  There are offsetting entries in two different books (accounts).

There isn't anything stopping you from doing that here.  You will lose the ability to directly jump to the other side of the transfer, but at least for me I seldom do that.

Chris_QPW

q_lurker said:

I am still failing to see the problem with having the money show up "early" in the receiving account or go out "late" from the sending account.  Especially with respect to the approximate 2-day transfer time.  (Meaning it is not a problem for me.  YMMV).  

To me it isn't a problem because I always give my cash flow kinds of transfers plenty of time, but I can certainly see how it would be a problem for people that have the "just in time" attitude.

As in say you need to have $1000 in your checking account on the 1th and you are transferring that from some account that isn't at your checking account financial institution.  You start the transfer on say the 30th of the previous month if it is recorded as the 30th in both accounts the projected balance in the checking account would indicate that you have enough money in the account, but depending on when that transfer really went through it would be wrong.

Now that I have put this in I'm going to leave it, but follow it by why this and the whole idea of having a transfer that has different dates on it is a bad idea.

Chris_QPW

First off when I started to think about these kinds of transfers I realized a few things.

I don't get into the kind of problem I stated in the previous post because I plan better.  The money I need is either in an account that I can transfer immediately (same financial institution) or I transfer it will lot sooner, after all there might be weekends/holidays or other reason it is delayed.

When you start transfer you don't know when it will show up in the other account.  Sure they say two days and you might have done this a lot of times and therefore can make a guess at it, but really until it is in your account and cleared it isn't guaranteed.

So you are simply guessing at when it will be there and as such you still have that same "uncertainty" of looking at your protected balances and assuming that you have enough.

In fact the real problem isn't the date on the transaction.  The real problem is making judgements on if you have enough money in an account based on transactions that have yet to clear.

Boatnmaniac

NotACPA said:

"I would be constantly managing 4 additional Cash accounts"

Why would it take 4 accounts?  Run them all thru a single "CIT": (Cash Items in Transit) account.

Maybe because I have 4 different data files and they all can't share the same CIT account?

Boatnmaniac

q_lurker said:

NotACPA said:

"I would be constantly managing 4 additional Cash accounts"

Why would it take 4 accounts?  Run them all thru a single "CIT": (Cash Items in Transit) account.

(Four different data files)

I am still failing to see the problem with having the money show up "early" in the receiving account or go out "late" from the sending account.  Especially with respect to the approximate 2-day transfer time.  (Meaning it is not a problem for me.  YMMV). 

Showing up early in the receiving account is OK...provided the receiving account is not a loan since that would mess up the calculated principal and interest splits. 

Showing up on time in the receiving account is good...but that means the balance in the sending account is higher than what it is at the FI.  I don't usually manage my finances so tightly that 2-4 days of balance discrepancies is of concern but it does happen that those 2-4 days of balance discrepancies can sometimes mean the difference between a check getting paid or bounced.

You are right, everyone's need (perceived or real) and practice is different.  Those who wish to continue doing things they way they've always been done can continue to do that.  But why in the world would anyone here (especially the SUs) be so argumentative against an improvement change that users for years have requested because it would make Quicken more valuable and easier for them to use?   I'm dumbfounded.

q_lurker said:

@Boatnmaniac wrote earlier

I do know that doing transfers with only one date or the other has caused me register balance and planning issues too frequently and I absolutely hate that.  

Is this because you are recording these some weeks in advance?  Such is not my usage style.  

I frequently schedule transfers/payments (at my FIs) 2-4 wks in advance.  Once they've been scheduled I enter them into my registers in Quicken.  By locking them in early it provides me with time to plan for other changes that might need to be done to support them.  For instance, if I need to transfer $10K or $20K from my investments because I need to cover some bill or business or investment venture, which securities should I be liquidating?  Should I also be reallocating assets to keep my portfolio in line with my investment strategy?  And what about tax implications?  Should I pull that money out of my Roth IRA or my taxable brokerage or out of one or more of my wife's or my IRAs or one of our savings accounts or some combination of them all and, if so, should I have tax withheld and, if so, how much?  And how will that affect my overall tax liability and how can I minimize that?  Yes, I do these types of assessments and calculations just about every single month of the year.

Chris_QPW

Boatnmaniac said:

But why in the world would anyone here (especially the SUs) be so argumentative against an improvement change that users for years have requested because it would make Quicken more valuable and easier for them to use?   I'm dumbfounded.

How about because of the general fear that if the Quicken developers do this they might mess up transfers for everyone?

If the suggestion was for automating passing transactions through a second account, I would be more for it, but changing the behavior of the current transfer system worries me no end.

Boatnmaniac

Chris_QPW said:

Boatnmaniac said:

But why in the world would anyone here (especially the SUs) be so argumentative against an improvement change that users for years have requested because it would make Quicken more valuable and easier for them to use?   I'm dumbfounded.

How about because of the general fear that if the Quicken developers do this they might mess up transfers for everyone?

If the suggestion was for automating passing transactions through a second account, I would be more for it, but changing the behavior of the current transfer system worries me no end.

There's a lot going on in this thread so perhaps you didn't see what I'd posted earlier:  "...the current band-aid process will only become a real solution if it can be somehow automated so a single transaction can be entered to accomplish what we now do manually with two transactions." 

Adding a transfer transaction option (for transactions within Quicken) that allows one to enter the send date which transfers the funds from a sending account on that date to an in-transit account and also allows for entry of the receipt date (or number of days in-transit) which then transfers those funds from the in-transit account to the receiving account on that date would be a big improvement and I think would well meet the needs of most people who have been making this request for years.

And, such a change would not need to mess up any transfer commands sent to FIs from within Quicken if only the send date would be sent to FI.

Feeling more comfortable, now?

Chris_QPW

@Boatnmaniac Yes I saw your post and that is why I mentioned it (and that I would be fine with that).

But original post wasn't for that, and in fact when this comes up that is what everyone thinks of, allowing a transfer with different dates on each side.  And you asked why people were so opposed to the idea, and I think that explains it.

I suggest that you create an Idea thread for your way of handling the problem, and hopefully that will get a better response from everyone, but I can bet that another person coming here and seeing it when they want to have different dates on a transfer will not consider it a "solution" they want.

Chris_QPW

BTW it is the SUs that will be the ones that push back the most so that shouldn't really surprise you.

After all if you knew nothing about Quicken's development history would you think that my reason for not having such a feature is the "correct attitude"?

As in don't do it because we don't trust the Quicken developers to do it, instead do it because it is needed?