Registers and reports do not match

LeaningTower

Ran a (saved) report for income and deductions. The numbers seemed "off" so I looked at the register and found more trouble. The net amount displaying in the register is correct. However, that amount does not match the net amount that displays when I open up the paycheck. (I use the Quicken tool to record gross income on my checks and all deductions.) In fact, most individual amounts in the paycheck are wrong.

For example, I viewed my last paycheck for 2020 in the check register. The net in the register might say $2000. But the net when I open up the paycheck might show $1800. And the indivdual amounts do not match the stub. They actually match my current 2022 paychecks.

This is rendering my reports useless! Arrghh!

How can I diagnose and fix this problem?

LeaningTower

Tried calling Quicken tech support and the agent doesn't understand. He says "so the transactions dont match?" He suggests i review and edit the transactions that downloaded incorrectly. He still didn't understand when I tried explaining these are old transactions the somehow became corrupted. Does the owner/maker of Quicken train their support people or just put throw in front of a phone and computer?

Frankx

Hi @LeaningTower

Which version of Quicken are you currently running?   There were a couple of Quicken releases recently (namely 39.17 thru 39.21) that were flawed and caused payroll transactions (including those posted years earlier) to be altered retroactively.  Please see this link for additional information on this issue - LINK.

The problems that caused prior payroll transactions to change were fixed with a new release - 39.23, however that release does not correct or reverse the damage that was done.  Quicken recommends that users download the new release and either restore a backup made prior to their upgrading to 39.17 and then move forward from that point in time, or manually correct all affected/corrupted transactions.

Frankx

LeaningTower

Hi Frankx

I am currently running R39.23

Thanks! You were more helpful and informative than the two techs and one supervisor I spoke with. I specifically asked the supv (Maria) if other users reported similar problems or if it is a known issue. She claimed she looked for a known issue and there isn't one.

Can you tell me how I can determine when I upgraded to one of the problematic releases? Is there some kind of log file in Quicken that records upgrades? If I know when I upgraded to 39.17 thru 39.21, I'll know how far back to go to restore a backup. Thank G'd I back up weekly. It may minimize the pain.

Sherlock

LeaningTower said:

Hi Frankx

I am currently running R39.23

Thanks! You were more helpful and informative than the two techs and one supervisor I spoke with. I specifically asked the supv (Maria) if other users reported similar problems or if it is a known issue. She claimed she looked for a known issue and there isn't one.

Can you tell me how I can determine when I upgraded to one of the problematic releases? Is there some kind of log file in Quicken that records upgrades? If I know when I upgraded to 39.17 thru 39.21, I'll know how far back to go to restore a backup. Thank G'd I back up weekly. It may minimize the pain.

If you allowed Quicken to update itself, there may be an automatic backup saved in the automatic backup directory with with the previous release in it's name which would give you a clue.   It should look something like:

QData-R-39.17-2022-03-04.QDF-backup

Frankx

Hi again @LeaningTower

Quicken automatically makes a backup file right before you do any program update, and that backup file will have that last version's name in the filename.  The last "safe" version was R38.30, so in order to find a backup file from before you upgraded, you just need to look for a backup file with "R38-30" in the file name.  It will look something like this:  yourfilename-R-38.30-2022-03-04.QDF-backup

Let me know how that goes.

Frankx

miklk

The date most people had access to the version with bug was march 4 so backup should be there or earlier

LeaningTower

Hi Frankx

Thanks again.
most of my backups appended the date/time into the filename. But I also found:
FILENAME R37.67 on 2/6/22 and FILENAME R39.21 on 3/14. None of the backups between those two have a version appended.
So it seems safe to guess that the back up immediately prior to R39.21 on 3/14 will be my best option.

Frankx

Hi again @Leaning Tower,

so from this last post, you seem to have gone from v37.67 to v39.21.  Since v39.21 is the first update having the problem, I agree that the "back up immediately prior to R39.21" will work for you.

Once again, let me know how that goes.

Frankx

LeaningTower

Thanks miklk. My application doesn't update automatically, so it looks like I may have gotten thebad update a little later.

But if this restored backup is still problematic, I'll know to look for one earlier than 3/4.

It's not November, but here's a list of things I'm grateful for: guys like you on this board who can help when the living brain donors in Quicken's tech support can't; and, ironically, tax season, which is how and why this came to my attention now. If I hadn't run historical salary reports, I wouldn't have discovered this error until... I don't know when I might have discovered it. But I likely would have had to re-enter months worth of data instead of just 4 or 5 weeks worth.

Quicken should have notified its customers that a known bug corrupted old data. And they should have done so loudly. If they monitor this forum, it's not too late to mitigate the damage many customers have suffered.

miklk

This bug was very "unfortunate"

Good luck 

LeaningTower

Don't think I'll get to the work tonight, but I'll update you tomorrow. Hopefully with good news.

LeaningTower

> @Frankx said:
> Hi again @Leaning Tower,
>
> so from this last post, you seem to have gone from v37.67 to v39.21.  Since v39.21 is the first update having the problem, I agree that the "back up immediately prior to R39.21" will work for you.
>
> Once again, let me know how that goes.
>
> Frankx

Hi Frank
For some reason the restored 3/12 backup still has the same problem. But a backup from 3/5 looks good.

I have to run a transaction report from the original file from 3/5 to date with the categories, memos, etc. and re-download a month of data. Could've been a lot worse. Thanks again

waukman

I have seen the same issue. I had one bank account that was over $50,000 over when I ran the net worth report. After restoring to an earlier version of a backup that issue has been fixed however, I still have about 6 accounts that are 'off' by one cent. I am running R39.23 build 27.1.39.23. Is anyone at Quicken looking at this 'issue' since it does make you question the accuracy of other 'reports'.