'Linked Transfers' should allow different dates for the linked transactions

veegee

When transferring cash between financial accounts, most often the amount gets debited in the source financial institution on one day, but credited in the destination financial institution a day or more later. This is specifically true in the case of inter-bank transfers and other inter-institution transfers.

While the linked transfer feature is much better overall than the plain 'Transfer' category method, it currently suffers from forcing the same date on both.

I am unaware of a workaround if it exists.

I would recommend that when the linked transaction is first created, the user is asked for an inter-institution delay as well. This could be 0 to n days. This delay is applied - as appropriate - to the matching transaction that gets created automatically. The link should be maintained even if the user adjusts (finetunes) the date subsequently.

volvogirl

A work around is to run it through a separate holding account. Set up a new account, like call it Funds in Transit. Transfer the withdrawal to it and then transfer the deposit from it on the right date.

NotACPA

When I authorize, for example, the payment of card account via Direct Debit initiated by the card company, I'm liable for those funds being present in my checking account IMMEDIATELY, even if the actual payment doesn't hit the checking acct until later.

SO, I'd oppose this idea. I want to know what's coming into my account … the exact day it arrives simply isn't significant.

Boatnmaniac

At one time I was thinking of proposing such a program enhancement but as I thought about it some more I began to realize that while it would perhaps reduce the the significance of the transfer timing issues it would not eliminate them and might actually significantly increase the level of effort needed to make it work right. Some of my thoughts behind this:

• The main reason for this is that for the most part we would be guessing as to how much transfer time would be needed. Some transfers take place in the same day while more commonly they are 1-3 days. But how do you predict that, especially since most businesses do not bother telling us which level of ACH service they are using?
• How will weekends and holidays be accounted for because they will increase the amount of transfer time in some cases but not in others? How do we reliably account for those?
• How far do we extend this? Just between our financial institutions? What about the transactions for purchases we make with credit/debit cards or payments we make by check? Are we going to extend this concept/process to these, as well?
• How would this impact the transactions automatic matching process? For instance, if the transfer transaction in the linked account is entered with a 3 days transfer time but the transfer actually completes in 1 or 2 days, will Quicken still automatically match them? Usually, transactions that post prior to the previously entered date will not be matched by Quicken requiring either a manual matching process or an editing of the previously entered date.

Do we really want to and are we really prepared to deal with that level of micromanagement of Quicken? Will the benefit outweigh the level of effort required? For me the answer is probably not. But maybe others will think otherwise.

@volvogirl's suggestion to run it through a manual separate holding account would perhaps be a good way to test out the concept to see how much benefit there might be and to determine if that benefit would be worth the level of effort.

Chris_QPW

To me the workaround was mentioned in the original statement, don’t use linked transfers, just use a regular category.

veegee

For me, I do like linked transfers, as changing one changes the other. I use them all the time, but the date difference is a constat issue.

@volvogirl , using a separate holding account will violate the 'changing source transaction changes the destination transaction' i.e. breaks the link.

As @Boatnmaniac this requires an initial guess on the user's part - but the final dates can be updated by user (per my suggestion). A user can always leave the delay as zero by default (per my suggested solution).

As @NotACPA points out, this could cause a future obligation to not show up bloating the effective current balance in the source account (example checking paying debit card. But that cuts both ways - it can also show a future payment coming into the account today, when it actually has not arrived yet. This also bloats the current balance in the destination account. Current balances in most active accounts are rarely accurate due to pending transactions anyway.

Anyway, I will leave it as a suggestion to think about. All I ask is that - at the time you are placing transfers into the a Quicken register, kindly think about 'what if' this capability was in place.

Jim_Harman

One complication of setting different dates in a transfer is that unless Quicken did some behind-the-scenes accounting, the money would temporarily disappear while in transit, causing an incorrect dip in your net worth.

A separate holding account would prevent this.

veegee

@Jim_Harman , yes, true. But this gets corrected in a day or two. Plus, if this is a problem for the user, they can always set the 'inter-transfer delay' to zero.

The net worth amount is often incorrect anyway due to transaction delays. If my employer pays me today, then my true net worth includes that amount, but Quicken net worth will not reflect that since the amount has not been credited to my account yet. Temporary discrepancies like these are very frequently present. So IMHO this should not be a major issue. There are always so many pending transactions. My net worth amount is most often incorrect in Quicken if I want an exact number.

Chris_QPW

I feel that there are features that people would like to have that for one reason or the other will cause more problems than they solve. To me this is an example of one of them.

veegee

Perhaps it might be less confusing to show the date in the destination account as 'Pending'. This can be updated later when a matching transaction is downloaded and accepted into the register. Or when manually updated in the destination register.

@Chris_QPW , IMHO, we all get used to inconsistencies once we get used to working around them. IHMO, placing the same date on both sides is an inconsistency and does not reflect reality in most cases. We simply got used to this discrepancy in Quicken, IMO. Again, that is just what I see. I certainly respect your opinion and can even somewhat agree that the work involved might be too much to justify, while at the same time disagreeing that it will cause more problems. Any problems caused will, IMO, be only because people are used to it working the current way. And, IMO, once people get used to working in a more realistic way, they will find it more intuitive because it will be more like how the transfer really is. Again, many IMHOs!

Chris_QPW

@veegee Please understand that my opinion is largely based on what I think the Quicken Windows developers can implement without messing things up vs the potential gain.

Case in point, how do you like the new buggy custom report dialogs?

It is that was something that I really thought was straightforward. Expand some dialogs…

You are talking about something that is core to Quicken right down into the database fields. And at the top level it might affect matching, and things like you are suggesting like "pending" and other things like that. To me that is high risk for something that people have found acceptable for over 40 years.

veegee

@Chris_QPW , I understand what you are saying and the risks are definitely there. It will have to be done by some really good developers, and testing will need to be thorough. And then you have to explain to all the users as well. Perhaps not worth the risk.