Skip to content

I suggest you ...

← Feature Request

Prevent accidental changes by locking a fiscal period

One problem with Gnucash is that a user may accidentally change a transaction in a previous month or year. For example, it is possible to delete a transaction that should not be deleted. Also, if a user enters the wrong date in a new transaction (e.g. when typing the date, the year is wrongly entered) the transaction will enter the register in a previous period, but the user may not know where it went. Thus the accounts could be in error due to an accidentally deleted transaction or incorrectly entered transaction.

In my experience training people to use Gnucash in the non-profit sector this has frequently happened.

SUGGESTED SOLUTION:
Add a feature where the entries in a month may be locked and password protected. Thus, after the data-entry clerk enters all the transactions for a month into Gnucash, the finance manager locks all the transactions with a password unknown to the data-entry clerk.

The lock would not prevent reports from being generated or data from being viewed, it would only prevent data from being changed in the locked period.

If subsequently, transactions in a previous month need to changed, the finance manager's password will be needed to unlock that month.

Such a lock could prevent both accidental changes to the accounts in a previous period and intentional attempts to manipulate the accounts to the data entry clerk's personal advantage.

232 votes
Vote

We're glad you're here

Please sign in to leave feedback
Signed in as (Sign out)
Close
Close
You have left! (?) (thinking…)
Nila Akash shared this idea  ·   ·  Report…  ·  Admin →
How important is this to you?

We're glad you're here

Please sign in to leave feedback
Signed in as (Sign out)
Close
Close

We're glad you're here

Please sign in to leave feedback
Signed in as (Sign out)
Close
Close
Submitting...
An error occurred while saving the comment
  • Martin Zaske commented  ·   ·  Report

    For Germany this would help a lot for working under "Grundsätze ordnungsmäßiger Buchführung". Very very important.

  • Fan commented  ·   ·  Report

    This is one of the most important features Gnucash needs to have and it will users a lot of time when accidental typo happens. This was requested more than 12 years ago but still is unavailable.

    As a workaround, I am using the feature of "Day Threshold for Read-Only Transactions (red line)" to prevent myself from making typo. This, however, is not a ideal solution. The absolute date is more important than the relative date.

  • Arman commented  ·   ·  Report

    The inability to close off accounts and periods after statements have been received is really limiting. I ended up rolling my own custom balance assertions script that makes sure balances match my statements, but this is just a hack (https://github.com/armanschwarz/gnc_tools).

    Having balance assertions or some kind of "lock" feature is really essential, I wouldn't be using gnucash if it weren't for the balance assertions script that I wrote, but I would much rather this be a proper feature in the tool.

  • Patrick commented  ·   ·  Report

    Agree on the need for this; being able to close the books on a month/quarter/year should be possible. Overriding it should be as well, but as a very deliberate task. Not sure how it would work from a personal finance perspective though.

  • Anonymous commented  ·   ·  Report

    Any progress or ETA on this? This is an extremely helpful feature.

  • Alexey Pakseykin commented  ·   ·  Report

    Mistakenly modifying entry in the past is the most common source of problem for me (if not the single one). As previously said, years of data to review drains a lot of time due to a mistake which is very easy to make.

    I don't find password protection necessary. The feature is primarily needed as protection from mistakes rather than protection from unauthorized modification. Consider the simplest implementation without password first - it will immediately save time for many users.

    Adding password should be a separate feature (because it goes far beyond - simple password will only add false sense of protection from unauthorized modifications as users have direct access to data files).

  • Anonymous commented  ·   ·  Report

    I would suggest just specifying the red line with a hard date, rather than by a number of days. If I close out a year in January, I want all transactions after Dec 31 in the prior year to become read-only. It doesn't really matter how many days ago. It matters when my last hard-close was (typically at the end of a year, a quarter, or a month)

  • Dean Gibson commented  ·   ·  Report

    This feature is partially available in 2.6.5 with the "Red Line" option in "Properties" ("File" pull-down menu), but that only specifies a number of days (which of course can be set to 30 or 365 to detect "wrong month/year" issues). It's not a big issue with me, but given the code for the "red line" feature, this shouldn't be that difficult to implement.

  • Anonymous commented  ·   ·  Report

    This feature is essential. It is very easy to make a change to an entry from years back or enter the transaction in a wrong date and you have to go through years of data to find out if you can.

  • Will Palmer commented  ·   ·  Report

    After a single typo last-night, I now need to go through all my accounts for the year, line-by-line, and compare with printed records. This feature is absolutely essential.

  • James commented  ·   ·  Report

    Couldn't agree more! This would be a very useful feature.

  • James Pang commented  ·   ·  Report

    Accidents do happen: '7th August 2001' as 7/8/01 and '8th July 2010' as 8/7/10... Hahaha... that came to my mind after reading it... Yup, this definitely could make a difference. Good job

  • Anonymous commented  ·   ·  Report

    I would really like to have this feature, if it's not already available.

Feature Request

Categories

Feedback and Knowledge Base

(thinking…)