Ethan on 20 Jul, 2020 02:51 PM
I had a situation sort of like this with my credit union about a year ago. When I talked to them about it, they said what I was actually setting was a "deliver by" date. When they made the first payment to a new vendor, they would withdraw the amount a few days before the date I sent. If they had to write a paper check, this could almost be a week in advance. But then they said that their system learns how long it takes the funds to actually be processed, and adjusts the withdrawal date accordingly. This usually meant shortening the gap between the deliver by date and the actual withdrawal date, sometimes to the same day, especially in the case of electronic payments to major vendors (like the local cable company, for example). Sometimes the few that require paper checks are withdrawn earlier, like if the due date falls on a weekend this month.
I guess the idea is that they keep the funds in my account for as long as possible, which I appreciate. I suppose the same practice could be used in a more sketchy sort of way, where the bank or third-party processor is taking the money out slightly earlier than needed, holding it in some mysterious account that may generate interest or other profits for them, and then sending the bills. If they skim a day off of every bill from hundreds of thousands of accounts, that would start to add up. (This is just speculation based on the behavior of many major banks here in the US.)
If this is a common practice, my guess is that it would vary significantly by bank and vendor.
This is different. What I am talking about is the Bank (or their processor) changing the “process on” date (shown in Bill Pay) to whatever it needs to be to arrive at your payee’s due date - as determined by their knowledge of the actual due date, and ignoring what you enter in Bill Pay as the due date.
So far, my bank's knowledge of the actual due date has been correct. But, for me, that’s not the point. I think the choice of when you want a debt to be paid by should be mine, not theirs - and it may be legal requirement. ACH speed, or not, some payments I like to make sure arrive well before actual due date. I wonder what it would take to get the bank to cover the consequences of a large, late payment.
I have tried correcting (via edit) payments back to the due dates I wanted (and earlier). This would work, but often required up to three edits (a change would show in the Bill Pay window, but then change back the next day) to get it to change. Also, editing only works if you catch the changed “process on” date in time to avoid the “date is too near to allow sufficient time for processing” catch 22.
As to why it is happening, I could speculate. US Bank said their processor was responsible and they had not control over it. Of course, that is probably BS. In any case, just wondered how widespread this behavior it might be.
BTW, I am only talking about OFX/Direct connect Bill Pay. I do not use web Bill Pay enough to have noticed whether it happens there also.
Ethan on 20 Jul, 2020 04:57 PM
That does sound different. I think all I can say is that this isn't something that Moneydance does; it just connects to the bank's servers, sets the payment information, and receives confirmation. If a change is made later on, that's definitely something to take up with the bank.
I'd also be interested to hear others' experiences about their banks changing dates in this way. I agree it seems like this should be a contract-like agreement based on the date the customer sets. But I'm sure there's terms of agreements for these systems, and like most people I've never read mine!
Update: I switched from US Bank to Mechanics Bank. Their bill pay is even worse. It will not allow any editing of payments or payee info, unless it is done through their web site bill pay. Even then, it will probably not "take" for payees they "know" about.
I have gotten one of their support people to agree (and see via screen shots) the problem exists and they are supposed to be looking in to it. Will report on any results.
Update: No word yet from MB support on why due dates are being changed and payment payee editing is messed up. However, They have replied about "process dates" changing from session to session in the MD bill pay window. I have a payment now that shows a 9/21 due date in MB web site and, today, a will process of 9/30/20 in MD's payment window. Here is what they wrote:
Due dates being changed in the Quicken view. This appears to be an ongoing issue with Quicken. We send over the correct payment date but there seems to be a problem with how Quicken is using that data. It is not something that we have control over. The payment due date stays consistent in our Bill Pay system. The suggestion is to seek help from Quicken support. https://www.quicken.com/support#contact-support This article contains information about Windows computers but I have seen other help boards that indicate it is a problem on Macs as well. https://community.quicken.com/discussion/7870871/why-does-quicken-k...
I doubt it is an MD, or Quicken, program problem as I have never noticed it before and have used a dozen, or more, OFX institutions over the years.
Checking on the Quicken user forum link provided by MB support, it appears to be about reminders rather than scheduled payments. I let the person that provided the link know and she says she is kicking it back to the tech's that should know what is going on. My suspicion is there are some serious sync'ing problems between the MB accounting system and their 3rd party OFX supplier FISERV. Maybe this is why many banks do not try to sync their bill pay systems.
Update: latest is that MB support has "escalated the problem to their 3rd party service provider". The MD OFX bill pay window dates now seem stable. However, the payment I reported as an example of the problem now shows a "deliver by" date of 9/21/22 (what I entered as due date) on MB's website and a "will process" date of 9/22/20 in the MD OFX window. Will post what happens.
I guess no one, or very few, others are seeing this problem. Hope that is the case and it's just an unintentional bug, rather than a new industry practice.