Don't unclear transactions just because they didn't reconcile

Noxsc

I have one credit card account where transactions within the last day or two of the end of the billing cycle don't show up on the next bill even though their posting date is within the date range for the bill. When I reconcile the bill in Quicken, I have to un-check those cleared (downloaded) transactions to get the bill to balance. That's fine. What annoys me is that doing this marks the transactions in the register as uncleared, so I have to go through them all again and re-mark them as cleared. Unchecking a cleared transaction in the bill reconciliation window should just leave that transaction as cleared but not reconciled.

q_lurker

What you are asking to have changed is a 'from the beginning' fundamental aspect of Quicken.

Are you aware that within an account register you can select several transactions, then rt-click to get a menu of options, one of which is to change the "Reconcile status" of those selected transactions. That should be easier than individually altering the status of several transactions.

UKR

When you run a manual Reconcile, you can deselect these cleared-but-not-included-in-the-statement transactions to make Reconcile balance to the Statement Ending Balance.
Next month, when you run reconcile again, these transactions will automatically be included in the process, regardless of cleared or uncleared status. It should not be necessary to change these transactions prior to Reconcile, but you may / will have to checkmark these transactions in the Reconcile dialog window (or click the "Mark all" button) to include them.

q_lurker

Another ‘did you know’

When in the reconcile screen, you can click the box to mark one transaction cleared or not cleared (green checkmark) and then drag down the list to instantly mark multiple transactions the same way.

Boatnmaniac

I agree with the OP. It has always bothered me that unchecking a transaction in the Reconcile window always changes the cleared status in the register to uncleared and that is a PIA. Those affected transactions were previously marked as cleared and the reconciliation process should not change that status to anything but R when they have actually been reconciled.

What others have posted about how to change the status of transactions that have been uncleared back to cleared is good info but the point is that we should not be having to do that in the first place. They are workarounds to resolve a Quicken-caused reconciliation issue, they are not a fix for that issue.

This Product Idea is quite simple: When unchecking a transaction in the Reconcile window simply retain the cleared status that it had prior to starting the reconciliation process.

It's got my vote. But I am also going to submit a problem report to Quicken that this is a program issue that needs to be fixed. I encourage others to do the same via Help > Report a problem….be sure to copy/paste the URL of this idea thread in the report.

q_lurker

I don’t see it as reasonable for Quicken to remember or “retain the cleared status” much like I don’t see an Undo feature remembering changes. Rebuilding the status should be possible. Should the remedy be:

When Quicken completes the reconciliation, it scans the account for “posting date” for all transactions and changes any blanks to ‘c’.

If you cancel the reconciliation, nothing changes just like current behavior. If you “Finish later”, a ‘c’ you have changed to uncleared as part of the reconciliation remains uncleared (blank) so that your initial reconciliation work is maintained.

Boatnmaniac

I don’t see it as reasonable for Quicken to remember or “retain the cleared status”…. 

That assumes that once the Reconcile status starts all of the "C" items will automatically and immediately have the "C" status removed….and with no input from the user. In that case, yes, Quicken would need to remember the change in order to put the "C" status back in place.

But should not the Reconcile process not change anything at all with the actual transaction status (other than to place a check mark in the Reconcile window) until after the approval/command to complete the reconcile process is granted by the user? Deleting the "C" status before the user approves the reconcile to me is faulty logic and actually defeats the concept of what it means to reconcile an account because it removes the record of the transaction having been downloaded from the financial institution. That should not happen.

…much like I don’t see an Undo feature remembering changes.

But doesn't Quicken already provide some Undo capabilities? For example, one can undo transaction matches when all transactions that were downloaded were all accepted at one time.

Rebuilding the status should be possible. Should the remedy be:

When Quicken completes the reconciliation, it scans the account for “posting date” for all transactions and changes any blanks to ‘c’.

Why would you want to have all blanks changed to "C". I have many instances every month where there are transactions that have a blank status prior to the current date because the financial institution did not yet download the posted transactions. To me, this would be an even bigger issue than the one the OP and I would like to see fixed because then we would need to review every "C" transaction and compare it to the online account to see what has actually been posted and, hopefully, downloaded and what is still either pending or perhaps not yet even in the financial institution's records.

If you cancel the reconciliation, nothing changes just like current behavior. 

True, and that is what I end up having to do frequently. It means that my reconciliation is usually delayed by no more than a few days since I reconcile to the Online Balance. But for those who reconcile to a paper statement 1X per month, it would mean they would need to delay reconciliation by another month….maybe even more than that if the same situation occurs with the following month.

If you “Finish later”, a ‘c’ you have changed to uncleared as part of the reconciliation remains uncleared (blank) so that your initial reconciliation work is maintained.

But that is the problem. "C" should not ever be changed until the command is given by the user to Quicken to complete the reconciliation process. By changing the "C" to anything before this is faulty program logic and needs to be fixed to prevent that from happening.

Maybe one way to do this is to have one column in the reconcile window that shows the current status (blank or "C") and have a column next to it for the check mark. Adding or removing the check mark makes no change in the register. Only after the user approves the reconciliation do the check-marked transactions get changed and then get changed to "R". All the other transactions remain unchanged in the register.

q_lurker

First off,, I was not sufficiently clear with my proposed remedy. I was suggesting that once a reconciliation was achieved and Finish was clicked, the program would review that account, and transactions with both a posting date and a Clr status of blank (uncleared) would have the status changed to 'c'.

• When finishing reconciliation
  • Posting date and blank Clr status ⇒ Change Clr (back) to 'c'.
  • No posting date (meaning never downloaded) ⇒ no change to the Clr status.

The Cancel reconcile comment - no change:

True, and that is what I end up having to do frequently. It means that my reconciliation is usually delayed by no more than a few days since I reconcile to the Online Balance. But for those who reconcile to a paper statement 1X per month, it would mean they would need to delay reconciliation by another month….maybe even more than that if the same situation occurs with the following month.

I reconcile to the 'paper statement' even if it is online information; indeed that is undoubtedly a bias in my thought process. I've never had to delay a reconciliation at all. I start a reconcile; see something I don't like or understand; I cancel it. Nothing is changed. How does that lead to having to wait a day or a month?

As currently implemented, if the FI has downloaded the transaction before the statement date but not included the transaction in the statement balance, the current process has the user change the Clr status by unchecking the transaction in the reconcile window. That works meaning the reconcile completes correctly. With no intermediate user intervention, the next month the user must check that transaction in the reconcile window. The possible intermediate intervention is the user changing the Clr from blank to 'c'. Two ways to do the same thing that the user is required to do - under the current process. I understand that user intervention is the problem some users want alleviated. (I'll add I don't see that there should be a difference when reconciling to an online balance, but maybe the frequency is greater of transactions getting downloaded without being included in the online balance value.

You asked:

But should not the Reconcile process not change anything at all with the actual transaction status (other than to place a check mark in the Reconcile window) until after the approval/command to complete the reconcile process is granted by the user? 

Rephrasing

Should not the Reconcile process not change anything at all with the actual transaction status (other than to place a check mark in the Reconcile window) until after before the approval/command to complete the reconcile process is granted by the user? 

Honestly, I am not sure.

What is the Clr status? I see it as a user controlled status or measure reflecting the state of that transaction as the user knows it with respect to the FI. That is why it dates back to the infancy of the program - before downloading of transactions and FI interfaces existed. I see the checkmark in the reconcile window being that Clr status — checkmark = c, blank = blank. Nothing more. They are one in the same. So if the user changes that state in the reconcile window, yes that should change in the transaction records.

Should the Clr status ever be different than as implied by the downloaded date? Probably not. That is sort of how I got to my proposal.

Chris_QPW

Whereas @Boatnmaniac sees this as a Quicken reconcile issue I see it as a financial institution data issue.

If the financial institution wasn't sending the wrong information this thread wouldn't exist.

To me this is a thread trying to convince people/the developers to code around bad data, which is never a good thing in my book.

As for why it works this way in the first place, I think it is pretty obvious. As @q_lurker suggested start at the beginning, no downloading. Quicken could certainly popup the reconcile window and just show you the transactions and if they reconcile without allowing you to change anything. But of course, if they user made mistakes then they are going to want to have the convenience of changing it right there in the reconcile window. And changing a transaction from cleared to uncleared would be part of that. It isn't a separate part of the process for the simple fact that this isn't "reconcile process only window operation". It is allowing the user to make the needed changes without jumping back and forth between the reconcile window and the register.

I will note that in Quicken Mac they do the reconcile in the account register where they can make sure changes without jumping back and forth.

Boatnmaniac

@Chris_QPW, @q_lurker - Thanks for the comments and input but it seems that you both are not understanding the issue and proposal of this Product Idea.

We’re not talking about how the FI might be causing issues with the reconciliation process because of delays in downloading transactions or the Online Balances...those are valid issues/concerns but they are not what this Product Idea is about. I think we all can agree that the FI is not telling Quicken to change the status from “C” to uncleared when they truly have been cleared (i.e., posted at the FI) so that is not the cause of this issue.

And we’re not talking about how there are manual workarounds or alternative reconciliation processes for this issue (requiring additional user effort) that we should simply accept as being OK or that we can or should either simply disregard the deleted “C” status of transactions. Or that we should just be happy that we have work arounds that we can use to fix what Quicken broke or to just back out of the reconciliation process. But why do that when “C” status has real and significant meaning in Quicken and when Quicken should be able to not break accepted transaction records without user approval in the first place?

Simply stated: We are saying that Quicken should not be changing the status of any transaction previously marked “C” without user approval and acceptance of that change. Nor should we be required to abort the reconciliation process to avoid having Quicken wrongly break a transaction’s “C” status when reconciliation can be properly completed by simply unchecking that transaction. The logic that says a checked transaction is either going to be an R transaction or an uncleared transaction but not a C transaction is flawed and should be fixed.

Chris_QPW

Simply stated: We are saying that Quicken should not be changing the status of any transaction previously marked “C” without user approval and acceptance of that change. Nor should we be required to abort the reconciliation process to avoid having Quicken wrongly break a transaction’s “C” status when reconciliation can be properly completed by simply unchecking that transaction. The logic that says a checked transaction is either going to be an R transaction or an uncleared transaction but not a C transaction is flawed and should be fixed.

I understood this statement, but I disagree with it.

This check mark and the ability to change it:

was literally put in as a convince for the user to change the Clr status field in the transaction from inside of the reconcile window and not have to do it from the register.

This dates back to before downloading existed, which means the only reason that a transaction would be marked cleared when it wasn't really cleared with the financial institution is because the user did it by mistake and now in the reconcile window wants to correct that mistake.

Deselecting that check mark is the "user's approval" to change the Clr status.

Moving forward to now include downloading of transactions and why a given transaction might be marked cleared. The two possible reasons are the user did it or Quicken did it when it got a posted transaction in the downloaded information. If the user did it by mistake, then above applies.

If it is the second case, the financial institution sent incorrect information. And for this there is multiple things they can send wrong.

• Marking a transaction as posted when it hasn't yet (still pending).
• Giving the wrong posting date.
• Giving the wrong current online balance date (only affects the user if they are using online balance date for reconciles).
• Giving the wrong online balance (only affects the user if they are using the online balance for the reconcile)

The "workaround" that @q_lurker seems like it would work to me, but I can tell you I dislike the idea from the standpoint that this is the exact kinds of workarounds that cause problems (guessing on how to fix up bad data).

But I'm not the person deciding this so we will just have to see if this gets enough support and if Quicken Inc agrees.

q_lurker

@Chris_QPW has captured my perspective accurately. I've offered to Quicken what I see as a possible approach. With that, I intend to drop out of commentary on this idea.