Possible scurity flaw on closing date

User987654321 · ‎November 07, 2022

We have been using QuickBooks on a computer with the date format as DD-MMM-YYYY. As the file admin, I had set the closing date to 30-09-2022 (September, 30, 2022), meaning that we had closed the month of September 2022 and no user could change any record before that date. When Windows was reinstalled, we opened the company file on the same computer. The date format had been reset to MM/DD/YYYY, but I had confirmed that the computer system time and date were correctly set to 11/07/2022 (November 7, 2022). When I opened the company file, the closing date showed as 12-09-2022 (December 9, 2022), which is a future date, and I immediately got two errors that admin needed to enter the closing password to save a record (probably an automatic logging entry that the file was opened today). Moreover, nobody could add any transactions for today, let alone correct any errors in the month of October. When we changed the system date format to show 07-Nov-2022, then in fact the closing date showed as 30-09-2022 and October transactions could be changed plus today's transactions could be entered. The date format should NOT affect the actual closing date, and which transactions can be changed. Plus 12-09 (Dec 9) and 30-09 (Sep 30) can not even be misunderstood as the reverse of each other, so something else is going on.

In this case, we did not lose any integrity of data because the closing date was moved to a future date. However, if the date format were normally MM/DD/YYYY and somebody changed it to the one we use DD-MMM-YYYY, then it appears that the closing date would be changed to an earlier time and users could modify entries in a period that was already closed by the admin. This appears to me to be a security flaw.

We are using Quickbooks Desktop Premier 2020, Nonprofit edition.

I would appreciate a reply about whether this is a security flaw and what would be done about it.

BigRedConsulting · ‎November 07, 2022

Yes, this is a security bug. Depending on the closing date entered, the date might advance to the 12th month, or might retreat all the way back to January of a given year, allowing wanton edits in the file during periods that are supposed to be closed.

It's actually amazing how lame this is, because dates in QuickBooks are usually stored internally as numbers, something like 44871 for today, but seems like the date here is stored as text and then - sometimes - adjusted if the resulting date is invalid.

For example, if you set the closing date to August 1 while the computer date format is DD/MM/YYYY, set it so to "01/08/2022", save it, and try to record a new transactions in July 2022, you'll get a message saying that the transaction date is before the closing date. So far, so good.

But then if you change the system date format to MM/DD/YYYY, reversing the month/day order, then even while QuickBooks is still running and the transaction form is still open (or restart QuickBooks. It doesn't matter), then you can record the transaction in July without getting any messaging!

This is because after making the system date format change, when reviewing the closing date, QuickBooks still displays "01/08/2022" as the date, only now it thinks that means January 8, not August 1!

And so, now the user can add/edit/delete transactions all the way back to January 8.

Brilliant, Intuit. Totally brilliant!

View solution in original post

ChristieAnn · ‎November 07, 2022

Hi there, User987654321.

Welcome to the QuickBooks Community. Please know that we aim to deliver customer satisfaction at all times and fix and address an issue as soon as possible. With this, may I ask for additional details on what specific error message you received when opening the company and while trying to manage your closing date? I'll appreciate it if you can provide screenshots of your end so I can present accurate information

For now, you can open this article to view various details on how QuickBooks performs certain year-end adjustments based on your fiscal year start month: Close your books in QuickBooks Desktop.

Please don't hesitate to click the Reply button below and add extra information about your concern. I'm always here to assist you further, User987654321. Have a great day!

User987654321 · ‎November 07, 2022

@ChristieAnn

I am not referring to year-end or closing transactions. I am referring to the closing date in the settings (under Accounting) for which a password is needed to change anything prior to that date.

Basically there is no error message. The effective closing date simply changed. You can test this by changing the Windows system date format and then open the settings and see the closing date; it’s different. (When I get to my computer next, I will try it again; since today’s date is different and it might show some other result.) And in fact, it would not let me change any transactions for today itself (because the effective closing date changed to something in the future). As soon as I changed the system date format back to the one we used to use, the closing date reverted back to our regular closing date. The security flaw is if somebody normally uses the other system date format and changes it to what we normally use; then they could presumably change some transactions which were before the closing date set by the admin.

BigRedConsulting · ‎November 07, 2022

Yes, this is a security bug. Depending on the closing date entered, the date might advance to the 12th month, or might retreat all the way back to January of a given year, allowing wanton edits in the file during periods that are supposed to be closed.

It's actually amazing how lame this is, because dates in QuickBooks are usually stored internally as numbers, something like 44871 for today, but seems like the date here is stored as text and then - sometimes - adjusted if the resulting date is invalid.

For example, if you set the closing date to August 1 while the computer date format is DD/MM/YYYY, set it so to "01/08/2022", save it, and try to record a new transactions in July 2022, you'll get a message saying that the transaction date is before the closing date. So far, so good.

But then if you change the system date format to MM/DD/YYYY, reversing the month/day order, then even while QuickBooks is still running and the transaction form is still open (or restart QuickBooks. It doesn't matter), then you can record the transaction in July without getting any messaging!

This is because after making the system date format change, when reviewing the closing date, QuickBooks still displays "01/08/2022" as the date, only now it thinks that means January 8, not August 1!

And so, now the user can add/edit/delete transactions all the way back to January 8.

Brilliant, Intuit. Totally brilliant!

User987654321 · ‎November 07, 2022

So how does this get fixed? I’m new to the community, not sure what’s the best thing to do?

BigRedConsulting · ‎November 07, 2022

@ChristieAnn

RE: Please know that we aim to deliver customer satisfaction at all times and fix and address an issue as soon as possible.

With that in mind, why didn't you just duplicate what the OP reported in QuickBooks and confirm the bug? I did. It was easy.

And, with a little thinking about it, I pointed out how it can actually be worse than what the OP discovered. Also easy. This bug goes back at least to QB 2019 where I tested it. I expect it also exists in QuickBooks 2023.

BigRedConsulting · ‎November 07, 2022

@User987654321 RE: So how does this get fixed?

I'd not hold your breath.

User987654321 · ‎November 07, 2022

@BigRedConsulting

Actually, if I understand you correctly, then it’s not past or future, but QuickBooks (with the opposite date format) actually interprets the closing date as December if the day is greater than 12. Since we always use the last day of the month for closing, then changing the system date format would mean it would always show as December. So we would have a problem only when the closing date is in the month of December:

31/01 would be interpreted as Dec 1

29/02 as Dec 2

31/03 as Dec 3

...

30/11 as Dec 11

31/12 as Dec 12 - only this is a past date from the one we would have set.

And this would be true for anybody changing the system date format from DD/MM to MM/DD and vice versa.

Is that right?

BigRedConsulting · ‎November 07, 2022

Yes, that is also true: If the day of the month is > 12 in the old format, then when QB starts interpreting it as a month instead of a day of the month, it sets it to 12 (December), the largest month.

But if it doesn't hit that case, if the day of the month is 1 - 12, then it doesn't seem to change the date saved as text (it seems) but just starts reading it as a different date.

Topics

Training

Community

Resources

Possible scurity flaw on closing date