Offer the option to download transaction dates instead of posting dates from the bank

JeffJazz

The downloaded dates are the post dates, which for credit cards always lag behind the actual transaction date. But the bank has the transaction date. So why not import the actual transaction date so they match what I enter manually, match my receipts, everything matches?

UKR

Isn't that what a new option, available with R 58.14, proposes to do?

Hover over or click the small blue "i" button for additional information.

NotACPA

@JeffJazz

The bank, particularly for checking account transactions, has no idea of the Transaction date. They don't capture the date that you wrote the check.

And the "transaction match" is somewhat flexible in that the downloaded date doesn't need to match the date that you actually made the txn for the 2 to be matched together, as long as the input date is in the past and within a few days.

Additionally, the bank has no idea, for either cards or checks, what categories you intend to use with the txn. So, you need to manually input that anyway. Q's suggested categories are a guess at best and can't cover split txn, such as when I buy both groceries and medicines at my local Kroger.

Chris_QPW

Going off of just a credit card and using Express Web Connect +, the transaction date is actually in the data that Quicken receives as shown by this example:

{"id":"449467788485946624","createdAt":"2024-09-07T17:41:19Z","modifiedAt":"2024-09-07T17:41:19Z","source":"QCS_REFRESH","accountId":"447317129903460865","postedOn":"2024-09-06","payee":"EATALY SILICON VALLEY","coa":{"type":"UNCATEGORIZED","id":"0"},"amount":-8.4700,"state":"CLEARED","matchState":"NOT_MATCHED","knownCategoryId":"4000000000","cpData":{"id":"202409061148197240817#20240817","postedOn":"2024-09-06","txnOn":"2024-09-05","payee":"EATALY SILICON VALLEY","amount":-8.4700,"inferredPayee":"EATALY SILICON VALLEY","inferredCoa":{"type":"UNCATEGORIZED","id":"0"},"cpCategoryId":"701","mcc":5411},"mlInferredPayee":"eataly silicon valley","type":"CASH_FLOW"}

But when I think about it, Quicken can't use that date.

Quicken has always reconciled to the posting date (and so do the financial institutions even though it might not be obvious). When reconciling to the online balance the transactions that are supposed to be included in that online balance are the ones where the posting date is within the reconcile period. And this is true of the financial institutions. They might have the transaction date on the statement, but they will not include any transactions in that statement that have yet to posted by the statement ending date.

Note that checks are a completely different animal. As @NotACPA said the financial institution doesn't read the date you wrote on the check, and besides that they aren't even concerned about it. The dates they would be concerned about are that date they received it and the date it posted (and there might be another date for the when they allow you to withdraw the money).

With even more thought, it seems to me that there are four kinds of users in this regard.

1. People doing this purely manually. Since they are entering everything, there isn't any conflict with whatever they want to do.
2. People that enter the transactions from their receipts and then download. With this method the main date for the transaction will be the transaction date on the receipt and Quicken will have no problem at all matching the downloaded transaction that has a posting date that lags by a day or so (reconcile is
3. People that don't enter receipts, and don't even try to match to receipts. The only time the difference between the transaction date and the posting date is going to matter is the reconcile fails and one has to use the statement to figure out what went wrong. This should be a very rare situation. And I can tell you that what throws me off more is the ordering of transactions on a given date in these situations. But a simple way to handle it is print out the statement and go through Quicken's register putting a checkmark on the paper statement for each transaction as you find it in Quicken.
4. People that don't enter receipts and want to match receipts (I suspect this is what @JeffJazz is doing). Given that I don't think it is possible to change what Quicken reconciles to, about the only way to support this that I can think of would be to have a "Downloaded Transaction Date" field that the user could turn on.

Jim_Harman

I can think of another use case, which occurs quite frequently for me.

I have many utility and other bills set up to Auto pay, where the biller withdraws the money from a checking or credit card account each month, a few days before the bill is due. I also have Reminders set up in Quicken for these bills, with the due date set approximately the same as the date the money will be withdrawn.

As soon as I know what the amount will be for a bill, I enter it in the Reminder and accept the Reminder. This sets the date in my register to the Reminder due date, which is often several days away from the eventual posting date. When the transaction downloads from the FI, Quicken usually matches it to the transaction in the register. Currently the date remains the same as the estimated date in the register unless I change it to match the posting date.

I hope the new setting will set the register date to match the posting date in this case.

AgBrewer97

@UKR this functionality feels like a fix for the problem where Schwab downloaded dates are one day prior to actual transaction

ONGOING 8/29/24 Charles Schwab - Downloading Transactions Using Yesterdays Date — Quicken

The one thing I've noticed though is that this fix doesn't seem to work. I have this box unchecked, so should use the date I used when I manually entered transactions. As an example, I bought several ETFs today in Schwab and put them in during the day using today's date. I did my evening OSU and the transactions downloaded, but with yesterdays incorrect date (see above link). Despite having the box unchecked, it overrode my date with yesterday's date. I had to go back and override / correct them all, defeating the purpose of the "fix / workaround". One thing I notice is that instead of match, they download as "near match", with the only difference being the date. If you select to use your manually entered date over downloaded, and they're different, then it doesn't 100% match, so I assume it ignores this rule. If it "matches" and triggers this, then there's no difference to keep. Just seems like flawed logic in the code.