Quicken for Mac v6.1 Released

Quicken Marcus

We've started to roll out Quicken for Mac v6.1.

Reconciliation History and Re-Reconcile
A key highlight of this release is the new Reconciliation History and Re-Reconcile feature. Starting in v6.0 we started saving your reconciliation sessions which will now appear in the history window. The goal of this feature is to give you visibility into any discrepancy between your reconcile history and your current transactions so you can quickly spot issues. 

Re-reconcile will show you all transactions that were added, deleted, or changed during a reconciliation session.



Save Reports Consistently
Reports will no prompt you to save them if you expand or collapse disclosure triangles in a report or change the columns to make sure you want those changes saved. You will also be able to quickly save a new custom report after making report changes.


Quick Pay and Check Pay Improvements (US Premier or above customers only)
We've added 2 small improvements to Quick Pay and Check Pay. First off, we will now display the last payment amount for a payee that you've paid before making it easier to figure out what to pay.  We've also added a new Arrive By option in check pay so you can define the date when you want the check to arrive by.

We've also made a number of quality improvements.  Take a look and please report any issues in this release in this forum post. A number of us on the Quicken Mac development team will be monitoring this post to be able to jump on any issues quickly.

UPDATES

• 1/26 - Started the roll out to a small number of customers. If you want to download the release now, select the Check for Updates menu item under the Quicken main menu.
• 2/2 - Released an updated version.

glennmacc

These changes are greatly appreciated (especially the reconciliation history).  So far they are working fine for me, though all of my accounts are currently reconciled, so I have not tested the re-reconciliation process.

Glenn

Jon

In the Connected Services preferences, I have unchecked "Use posted date for matched transactions", and this seems to be throwing off the Reconciliation History.

I made a credit card purchase this month which didn't post until the day after the end date on the monthly statement. The date I entered for the purchase was the day before the end date on the statement. So my Quicken balance on the statement end date doesn't match the statement balance I reconciled to because of this transaction that had not posted yet. Reconciliation History shows the mismatch but there doesn't seem to be anything I can do other than change the date on the transaction to the posted date. The re-reconciliation screen doesn't show the "missing" transaction, it only shows the transactions that were already marked as reconciled.

I guess I expect Quicken to identify transactions that straddle the statement end date and make an adjustment for them. Without that, the reconciliation history is going to be full of mismatches that it thinks are errors but really aren't.

Quicken Marcus

Jon said:

In the Connected Services preferences, I have unchecked "Use posted date for matched transactions", and this seems to be throwing off the Reconciliation History.

I made a credit card purchase this month which didn't post until the day after the end date on the monthly statement. The date I entered for the purchase was the day before the end date on the statement. So my Quicken balance on the statement end date doesn't match the statement balance I reconciled to because of this transaction that had not posted yet. Reconciliation History shows the mismatch but there doesn't seem to be anything I can do other than change the date on the transaction to the posted date. The re-reconciliation screen doesn't show the "missing" transaction, it only shows the transactions that were already marked as reconciled.

I guess I expect Quicken to identify transactions that straddle the statement end date and make an adjustment for them. Without that, the reconciliation history is going to be full of mismatches that it thinks are errors but really aren't.

Interesting. Can I confirm that I'm understanding the issue correctly. 1) You reconciled an account. 2) You then turned off the "Use posted date for matched transactions". 3) This then changed the dates on your reconciled transactions and reconcile history detected these as changes and there is no way for you to fix these in the re-reconcile screen. Is that correct? Let me message you directly and would you be willing to share some screenshots with me so that we can get a better understanding of the issue you're seeing?

Jon

> @Quicken Marcus said:
> Can I confirm that I'm understanding the issue correctly. 1) You reconciled an account. 2) You then turned off the "Use posted date for matched transactions". 3) This then changed the dates on your reconciled transactions and reconcile history detected these as changes and there is no way for you to fix these in the re-reconcile screen. Is that correct?

Not quite. I have always had "Use posted date for matched transactions" turned off. Quicken did not change the "Date" field on the transaction, it is the date I entered. The "Posted Date" is whatever Quicken set it to.

I replied to your PM with some screenshots attached.

jacobs

@Jon  I'm trying to understand, too. You have a credit card purchase near the of the month, but it didn't post until after the first of the month, right? So your statement for the month does not include this transaction, but your Quicken register does. When you go to reconcile, the reconcile balance from the statement doesn't include the transaction, and when you check off which transactions cleared in the month, you leave that purchase uncleared -- so your reconciliation should work with no discrepancy, right. The next month, you come to reconcile and this transaction, dated in the prior month is still unreconciled, so it's in the list of transactions to check off in the reconcile window. And it's included in the actual transactions on the credit card statement, so again your reconciliation should work with no discrepancy.

What I've described is something that happens for my credit cards most months; there's almost always something I've recorded in Quicken which hasn't posted by the statement ending date. In my case, I'm entering transactions manually, so there is no "posted date" in Quicken, and I don't have problems.

You indicate that you manually entered the transaction in Quicken. You then subsequently download from the financial institution, and the downloaded and manual transaction were matched? Did the match happen automatically or did you have to drag one over the other? In either case, since you've told Quicken to ignore the posted date, the transaction should have retained the date you entered manually, and should still show as unreconciled.

Are you saying that after the download and matching, Quicken now says your previous reconciliation was off? That certainly shouldn't be the case. After you've reconciled a month, there's no reason you can't enter an additional transaction in that prior period, and have it show up in the next reconciliation as uncleared -- without affecting the prior reconciliation.

Post back if my description here isn't what actually happened, so we can understand what you're experiencing. 

Jon

@jacobs, it sounds like your understanding is basically correct. I'm pretty sure Quicken automatically matched the transaction in question, I rarely have to manually match them up with drag & drop. I'm also certain that the transaction was already entered in the register before I reconciled. I should probably also mention that although I'm regularly downloading transactions from the bank, I only reconcile the account once a month using the statement balance.

Quicken has never had a reconciliation problem with these kind of transactions before, it's only showing up as an issue in the new Reconciliation History window. It seems as though it is looking at the register balance on the reconciliation date and expecting that the balance I reconciled to should match that. It isn't checking to see if the register balance includes transactions that hadn't posted yet on that date.

Austin@

@Quicken Marcus I really love the new Reconciliation History and the consistency with how reports are saved. One small refinement that would improve what happens when reports are edited would be to have the red "close" button in the top left corner of the report window display a dot when the report has been modified from the saved version. This is standard macOS behavior and clues a user in even before they go to close a report that they will be prompted to save the changes, as there have been modifications that have occurred. Here's an example from Pages. After editing a saved document, the little black dot appears in the red close button to indicate that the file has been modified and that the user will be prompted to save or not save when closing the document.



Obviously this is a picky refinement and doesn't affect the functionality of reports in Quicken, but it would be a nice touch that would bring Quicken's interface behavior in line with standard macOS behavior.

Thanks again for all your hard work improving Quicken Mac. It's greatly appreciated!

Quicken Marcus

Jon said:

@jacobs, it sounds like your understanding is basically correct. I'm pretty sure Quicken automatically matched the transaction in question, I rarely have to manually match them up with drag & drop. I'm also certain that the transaction was already entered in the register before I reconciled. I should probably also mention that although I'm regularly downloading transactions from the bank, I only reconcile the account once a month using the statement balance.

Quicken has never had a reconciliation problem with these kind of transactions before, it's only showing up as an issue in the new Reconciliation History window. It seems as though it is looking at the register balance on the reconciliation date and expecting that the balance I reconciled to should match that. It isn't checking to see if the register balance includes transactions that hadn't posted yet on that date.

Jon, thanks for posting this issue. We figured out what was going wrong in your specific situation and have decided to fix it by simply not including uncleared transactions that overlap reconciliation sessions in our determination as to whether there is a discrepancy. Our original thinking was we wanted to expose transactions that were accidentally added in the past that conflicted with already reconciled transactions. However, we've decided that these types of errors will be easily discovered when you do a normal reconcile since all uncleared transactions appear in every reconcile session. This is the primary reason we don't include a start date. We're going to focus the Re-Reconcile feature on just those situations where previously reconciled transactions are changed in some way or are deleted. This also solves the problem of showing a discrepancy in the Reconciliation History even when there really isn't a discrepancy just because you downloaded new transactions. It's sort of the situation you're in where your previous reconcile session is still correct.  It's really not in error.  However, we're showing it in error because a newly downloaded transaction just happens to be dated earlier than your reconcile session. In any case, the issue you ran into will be solved. Thanks again for reporting it and for providing the screenshots to me in a direct message

Quicken Marcus

Austin@ said:

@Quicken Marcus I really love the new Reconciliation History and the consistency with how reports are saved. One small refinement that would improve what happens when reports are edited would be to have the red "close" button in the top left corner of the report window display a dot when the report has been modified from the saved version. This is standard macOS behavior and clues a user in even before they go to close a report that they will be prompted to save the changes, as there have been modifications that have occurred. Here's an example from Pages. After editing a saved document, the little black dot appears in the red close button to indicate that the file has been modified and that the user will be prompted to save or not save when closing the document.



Obviously this is a picky refinement and doesn't affect the functionality of reports in Quicken, but it would be a nice touch that would bring Quicken's interface behavior in line with standard macOS behavior.

Thanks again for all your hard work improving Quicken Mac. It's greatly appreciated!

That's really interesting. Thanks. I'll file a ticket.  Sometimes it's these small little things that make all the difference.

smayer97

Quicken Marcus said:

Jon said:

@jacobs, it sounds like your understanding is basically correct. I'm pretty sure Quicken automatically matched the transaction in question, I rarely have to manually match them up with drag & drop. I'm also certain that the transaction was already entered in the register before I reconciled. I should probably also mention that although I'm regularly downloading transactions from the bank, I only reconcile the account once a month using the statement balance.

Quicken has never had a reconciliation problem with these kind of transactions before, it's only showing up as an issue in the new Reconciliation History window. It seems as though it is looking at the register balance on the reconciliation date and expecting that the balance I reconciled to should match that. It isn't checking to see if the register balance includes transactions that hadn't posted yet on that date.

Jon, thanks for posting this issue. We figured out what was going wrong in your specific situation and have decided to fix it by simply not including uncleared transactions that overlap reconciliation sessions in our determination as to whether there is a discrepancy. Our original thinking was we wanted to expose transactions that were accidentally added in the past that conflicted with already reconciled transactions. However, we've decided that these types of errors will be easily discovered when you do a normal reconcile since all uncleared transactions appear in every reconcile session. This is the primary reason we don't include a start date. We're going to focus the Re-Reconcile feature on just those situations where previously reconciled transactions are changed in some way or are deleted. This also solves the problem of showing a discrepancy in the Reconciliation History even when there really isn't a discrepancy just because you downloaded new transactions. It's sort of the situation you're in where your previous reconcile session is still correct.  It's really not in error.  However, we're showing it in error because a newly downloaded transaction just happens to be dated earlier than your reconcile session. In any case, the issue you ran into will be solved. Thanks again for reporting it and for providing the screenshots to me in a direct message

@Quicken Marcus I see a real problem with this approach... it misses one key use case of re-reconciling... that is when you reconciled but then need to actually add one or more transactions that was/were not included in the first reconciliation. A couple of examples of this would be where you have 2 transactions that cancel each other out, e.g. a credit card charge and refund within the same period, or a single transaction that is has a net zero amount, maybe used for record keeping.

Neither of these would cause the original reconciliation to fail. But I have run into these scenarios many times over the years. I even intentionally use the last scenario for tax purposes and other situations regularly to add transactions after the fact of the initial reconciliation.

So, if you exclude transactions that were not part of the original, you are missing an important use case and make it impossible to re-reconcile with additional transactions. BTW, this is how QM2007 works, for good reason ... and it has always been flawless.

Unless I have missed or misunderstood something, it does not sound like you are using the same algorithm to not only identify discrepancies but to also allow for such scenarios (that are not discrepancies) where additional transactions need to be added. If so, I ask that you please reconsider this design.

Another way to put this, is "...all uncleared transactions appear in every reconcile session" and so it should be during re-conciliation... any transaction that would qualify for a given period during a normal reconciliation, should also show up during re-reconciliation of the same period, irrespective of whether or not it was there in the first reconciliation. (I hope my wording makes sense).

jacobs

@smayer97  I'm confused by your example: "a single transaction that is has a net zero amount, maybe used for record keeping." What matters here is the date of the transaction -- placing a note where you want it in time, or perhaps creating offsetting expenses and credits on a specific date. But how does the it matter when that transaction is reconciled? The point of a reconciliation is to reconcile -- match -- two sets of transactions, in this case between what's in Quicken and on a bank/credit card statement. A zero dollar transaction can't ruin a reconciliation, and it shouldn't matter which month's reconciliation it's lumped in with.

(What's not clear to me from what Marcus wrote is whether you will be able to re-reconcile and add such a transaction to a prior period which is already reconciled. Currently you can: if you have such a transaction that's added after a reconciliation, then Reconciliation History won't show a discrepancy -- because there is none -- but you can still click on the period and re-reconcile it to include this after-the-fact transaction. It's not clear if Marcus is saying you won't be able to re-reconcile a period which has no discrepancy.)

smayer97

What's not clear to me from what Marcus wrote is whether you will be able to re-reconcile and add such a transaction to a prior period which is already reconciled.

That is the issue I am raising... that is why I highlighted that section of his statement.

jacobs

I got that. But I was also questioning why it really matters. A zero-dollar transaction doesn't affect any reconciliation, so why would it matter what reconciliation it's included in?

Mike_jMGS

I had a similar problem where a transaction was in the register but not in the Re-Reconcile window list. I did not want to adjust the balance as the transaction was there but, quicken did not recognize and did not include it in the Re-Reconcile. There was no way to add a new transaction only to auto adjust the balance which does not help if the transaction was payment as the source account needs to be correct too. I ended up deleting (right mouse clicking in the Re-Reconcile window) many months of reconciliations and starting over which then recognized all transactions in that time period. This new feature may help if you accidentally delete a transaction but useless if at a later date you find an error in the original reconciliation.

What transactions fall into "were added, during a reconciliation session." ?

smayer97

jacobs said:

I got that. But I was also questioning why it really matters. A zero-dollar transaction doesn't affect any reconciliation, so why would it matter what reconciliation it's included in?

The date! to maintain context of the entry, both in the register and in reports, but is only determined after the fact.

smayer97

@Quicken Marcus  P.S. BTW, I really appreciate that you have implemented this feature since I raised it back in Sep 2016 here, which has been a part of QM2007 for the longest time. And it has been enhanced over the QM2007 version to identify specific transactions at issue, as appropriate, with useful editing functions. Nice!

It was/is such a critical and helpful feature... and a Mac ONLY feature! That's definitely one up over QWin...

Thanks! and way to go!

smayer97

@Quicken Marcus Now that this is in place, any possibility of carrying forward the reconciliation history from QM2007?

smayer97

RE: Reconciliation History

Can someone confirm if it is possible to unreconcile a transaction in the window? If so, how?

What about unreconciling multiple transactions at one time within the window? If so, how?

(I am not currently set up to verify this.)

Mike_jMGS

@smayer97 Not sure if this is what you are asking but you can right mouse or Control-click on an entry in the Reconciliation History and delete.

jacobs

smayer97 said:

RE: Reconciliation History

Can someone confirm if it is possible to unreconcile a transaction in the window? If so, how?

Yes. Click on the green reconciled check mark. You get this warning dialog:



If you click OK, the reconcile window clearly displays that you have edited this item by coloring the line yellow, making it Edited in the Change column, changing the green check mark to a deeper green check mark (not sure I understand that UI design; why not remove the check-mark), and a Revert button:

smayer97 said:

What about unreconciling multiple transactions at one time within the window? If so, how?

To the best of my knowledge, no. But you could always go to the register itself, Shift-click or Command-click multiple transactions, and change the status to Not Cleared. (I don't want to test how that affect the reconciliations, because I've already gotten my test file into a messed-up state doing multiple re-reconciles and bumping into the issue Jon wrote about and Marcus acknowledged above. I will wait until their next dot release to experiment with this further.)

EDITING for clarity: I messed up my reconciliations, but was able to fix them with some additional clicking. But since Marcus has said they're going to make a change, I don't want to draw more conclusions from testing the feature until they release their next iteration of it.

smayer97

@jacobs thanks for that.

BTW, does the BACK button revert any and all changes made in the window?

jacobs

@smayer97 I'm not sure what you mean by the Back button. There's a Back button on the Re-Reconcile account screen that lists transactions; "Back" here takes you back to the reconciliation set-up screen which shows the starting and ending balances and reconciliation date, and where you can edit the ending balance if you need to (similar to the regular Reconcile window).

I don't think there's a way to cancel out to multiple changes you've made in the re-reconcile window; it preserves the changes you've made if you close it. This is the same as the regular Reconcile window works. If you've marked several items as cleared in the Reconcile window, there is no "abort" to discard all changes; you can undo your actions in the Reconcile window, or you can go to the main window and manually change the status of any transactions you wish to uncleared, cleared or reconciled.

smayer97

@jacobs thanks for confirming both these things. That is what I suspected.

@Quicken Marcus  so there appears an inconsistency between the register and the re-conciliation window in handling unreconciling transactions. I suggest that at a minimum, they work the same... allow selecting multiple transactions in the re-reconciliation window and be able to unreconcile them in one step, just like in the register. 

I'd also suggest that there be a CANCEL button to the entire re-reconcile window to revert ALL changes and be able to exit, and therefore the "are you sure" confirmation dialogue box when unreconciling an individual transaction be removed, as it would become redundant since the whole purpose of the Re-Reconciliation window is to adjust any entry in the list. This is how QM2007 works so you can abort any changes. It is a much safer approach.

Quicken Marcus

smayer97 said:

Quicken Marcus said:

Jon said:

@jacobs, it sounds like your understanding is basically correct. I'm pretty sure Quicken automatically matched the transaction in question, I rarely have to manually match them up with drag & drop. I'm also certain that the transaction was already entered in the register before I reconciled. I should probably also mention that although I'm regularly downloading transactions from the bank, I only reconcile the account once a month using the statement balance.

Quicken has never had a reconciliation problem with these kind of transactions before, it's only showing up as an issue in the new Reconciliation History window. It seems as though it is looking at the register balance on the reconciliation date and expecting that the balance I reconciled to should match that. It isn't checking to see if the register balance includes transactions that hadn't posted yet on that date.

Jon, thanks for posting this issue. We figured out what was going wrong in your specific situation and have decided to fix it by simply not including uncleared transactions that overlap reconciliation sessions in our determination as to whether there is a discrepancy. Our original thinking was we wanted to expose transactions that were accidentally added in the past that conflicted with already reconciled transactions. However, we've decided that these types of errors will be easily discovered when you do a normal reconcile since all uncleared transactions appear in every reconcile session. This is the primary reason we don't include a start date. We're going to focus the Re-Reconcile feature on just those situations where previously reconciled transactions are changed in some way or are deleted. This also solves the problem of showing a discrepancy in the Reconciliation History even when there really isn't a discrepancy just because you downloaded new transactions. It's sort of the situation you're in where your previous reconcile session is still correct.  It's really not in error.  However, we're showing it in error because a newly downloaded transaction just happens to be dated earlier than your reconcile session. In any case, the issue you ran into will be solved. Thanks again for reporting it and for providing the screenshots to me in a direct message

@Quicken Marcus I see a real problem with this approach... it misses one key use case of re-reconciling... that is when you reconciled but then need to actually add one or more transactions that was/were not included in the first reconciliation. 

So, if you exclude transactions that were not part of the original, you are missing an important use case and make it impossible to re-reconcile with additional transactions. BTW, this is how QM2007 works, for good reason ... and it has always been flawless.

Thanks for these comments. We took them to heart.  We also observed other problems with excluding the cleared transactions while tweaking the behavior such as adding an adjustment would immediately disappear because it wasn't a reconciled transaction, etc. The change we've implemented in 6.1.1 which we'll be shipping shortly is that cleared transactions will continue to appear in the re-reconcile screen just like regular reconcile but they will not be counted as a discrepancy on the History screen since they were not part of the original reconciliation session. The original issue where some cleared transactions weren't appearing in the re-reconcile screen but were impacting the discrepancy calculation has also been fixed. The calculation at the top of the reconcile screen will include only the transactions that appear in that screen. The bug that was in 6.1 was that the calculation was using a subtly different set of transactions that could be different based on posted date and entered date. We think these changes will make this work a lot better for most people in 6.1.1 but we also expect to continue to refine this new feature in future updates to make it better. As always, thanks for the great feedback.

Quicken Marcus

smayer97 said:

@jacobs thanks for confirming both these things. That is what I suspected.

@Quicken Marcus  so there appears an inconsistency between the register and the re-conciliation window in handling unreconciling transactions. I suggest that at a minimum, they work the same... allow selecting multiple transactions in the re-reconciliation window and be able to unreconcile them in one step, just like in the register. 

I'd also suggest that there be a CANCEL button to the entire re-reconcile window to revert ALL changes and be able to exit, and therefore the "are you sure" confirmation dialogue box when unreconciling an individual transaction be removed, as it would become redundant since the whole purpose of the Re-Reconciliation window is to adjust any entry in the list. This is how QM2007 works so you can abort any changes. It is a much safer approach.

Great suggestion. Is the idea that you would want to clear all transactions and sort of start from scratch? Should we add a Clear All Reconciled Transactions button?  Or do you think the most common use case would be to un-reconciled a group of transactions?  Can you tell me more about why you would want to do this so we have a better understanding of the goal?

smayer97

Quicken Marcus said:

smayer97 said:

@jacobs thanks for confirming both these things. That is what I suspected.

@Quicken Marcus  so there appears an inconsistency between the register and the re-conciliation window in handling unreconciling transactions. I suggest that at a minimum, they work the same... allow selecting multiple transactions in the re-reconciliation window and be able to unreconcile them in one step, just like in the register. 

I'd also suggest that there be a CANCEL button to the entire re-reconcile window to revert ALL changes and be able to exit, and therefore the "are you sure" confirmation dialogue box when unreconciling an individual transaction be removed, as it would become redundant since the whole purpose of the Re-Reconciliation window is to adjust any entry in the list. This is how QM2007 works so you can abort any changes. It is a much safer approach.

Great suggestion. Is the idea that you would want to clear all transactions and sort of start from scratch? Should we add a Clear All Reconciled Transactions button?  Or do you think the most common use case would be to un-reconciled a group of transactions?  Can you tell me more about why you would want to do this so we have a better understanding of the goal?

So just to be clear so we are on the same page... the thought behind the CANCEL button is NOT to undo the entire reconciliation but rather if one starts a re-reconcile and part way through realize you just want to undo any and all changes, the button would revert back to the last reconciled state and simply not apply any of the changes, so really just a REVERT ALL and EXIT.

Any ability to unreconcile a selection of transactions could be handled just like in the main register... as I think that unreconciling a group would be more common IMO. This would allow someone to select either a group of transactions or even all transactions and unreconcile them all in the same fashion (so for this last one, do allow SHIFT-click, CMD-click and even CMD-A for selections in the re-reconcile window to select any individual or all transactions). Then a user could simply right-click and select unreconcile.

Another option would be to allow reconciled transactions to be unreconciled in the window simply by clicking their green reconciled flag. QM2007 does it this way.

BTW, in QM2007, you can actually click and hold the reconciled flag on one transaction then drag down the list to unreconcile multiple transactions at a time. So that is an alternative to unreconcile a group of transactions.

Hope that makes it clearer.

Garry@

@Quicken Marcus

I have had a problem both before and after v6.1 was released.

I have tried to enter a transfer of shares transaction. I selected “One Security” and selected the security.  I then tried to click on the “Transfer to Account” drop down.  The drop-down did not open but, instead a message dialog was displayed saying “No “Transfer to Account” selected”.  That dialog cannot be dismissed.  It re-displayed immediately after I click on “OK”.  No matter what I do it redisplays again and again.  I have attached a copy of the dialog.

.

This prevents me from closing Quicken; entering more detail on the transaction; accessing any other accounts; etc.  The only way to overcome this is to force quit Quicken.  Force quitting doesn’t seem to corrupt my data.  The transfer transaction is saved as a “Buy” transaction which I have deleted after re-opening Quicken.

Can this be fixed soon ?

Quicken Marcus

smayer97 said:

Quicken Marcus said:

smayer97 said:

@Quicken Marcus  so there appears an inconsistency between the register and the re-conciliation window in handling unreconciling transactions. I suggest that at a minimum, they work the same...

Great suggestion. 

So just to be clear so we are on the same page... the thought behind the CANCEL button is NOT to undo the entire reconciliation but rather if one starts a re-reconcile and part way through realize you just want to undo any and all changes, the button would revert back to the last reconciled state and simply not apply any of the changes, so really just a REVERT ALL and EXIT.

Thank you. This helps me better understand the ask.

Quicken Marcus

Austin@ said:

One small refinement that would improve what happens when reports are edited would be to have the red "close" button in the top left corner of the report window display a dot when the report has been modified from the saved version. 

Austin, our report software developer agreed with you 100% and it was easy to do so you'll see your suggestion in the v6.1.1. release that we just shipped.

Austin@

Quicken Marcus said:

Austin@ said:

One small refinement that would improve what happens when reports are edited would be to have the red "close" button in the top left corner of the report window display a dot when the report has been modified from the saved version. 

Austin, our report software developer agreed with you 100% and it was easy to do so you'll see your suggestion in the v6.1.1. release that we just shipped.

Thanks @Quicken Marcus. Much appreciated!