[GNC] GnuCash and Swedish accounting legislation

Tue Aug 11 06:14:19 EDT 2020

If you want a fixed date burn a cd or use other ways of verifying the 
files like md5sum

All of this fixed date stuff is just security theatre if you can access 
the source and pretty much the same even if you can't.

One of the attractions of gnucash is you have access to all your 
accounts, not just what some commercial company says you can have.

On 11/8/20 8:35 am, doncram wrote:
> Both fixed date and relative date locking are needed, let me chime in to
> say, with reasons that may not have been considered so far.  Relative (same
> as number of days?) should be a mild locking, like just a notice that can
> be over-ruled ("The transaction is more than 60 days in the past, are you
> sure you want to change it?).  This is a simple control to help avoid data
> entry mistakes.  In another software, that feature helps me surprisingly
> often.
>
> The fixed date locking should be stronger, ideally requiring a password.
> The previous year would be locked only when the Treasurer or
> other authorized person is really finally signing off on all reporting,
> after performing all necessary closing entries to recognize accruals (see
> my comment in separate thread "closing of accounts, and locking, "not
> needed in Gnucash"? Needed!") and reviewing the financial reports
> thoroughly.  This matches up to how nonprofits and businesses have to
> operate.  For a nonprofit, the final financial statements would be given to
> board , and used in applications for grant funding, and in filing
> IRS-required financial statements which are eventually published online at
> Guidestar, and so on.  One doesn't want incompatible versions being printed
> out and reported publicly, ever!  One really needs to finalize the previous
> year, for many purposes.  This allows a nonprofit (or business) to separate
> some duties (e.g. a cash withdrawal transaction can not be removed later by
> the office-person who took the cash). It can help even a single person
> business, too, in making sure that past-years data is fixed (and so
> financial statements and tax info is fixed), unless you really really want
> to change it for some reason (I can't think of any good reason though).
>
> About the Swedish legal requirement, I say kudos to them for requiring it.
> It seems a very good thing, to insist that any organization which will file
> reports will have the basic control that the transactions are locked.  It
> is good practice to ensure that any organizationsthen defines a change to
> prior year to be verboten, and it is therefore a detectable "crime" if that
> happens.  The requirement should be easy to achieve, and it has some value
> towards ensuring good info.  It's like requiring double-entry accounting,
> always having entries that balance!  The fixed date lock may suffice to
> meet this requirement.  It seems to me that the further locking feature
> (already discussed?), which prevents editing of any existing transactions,
> but allows journal entries, would be really helpful.  So that late changes
> would be clearly identified.  So that informal internal audit, or external
> formal audit, could focus especially on those late journal entries, as it
> should properly focus upon all unusual entries (including all or almost all
> journal entries).  It would be useful to have a software feature that
> allows one to compare one saved version of data vs. current version of
> data, to detect any "crime" and then take action on it.  The threat of
> being detected itself dissuades "crime" of unauthorized changes.  Trust but
> verify.
>
> Informational note:  Many participants here may not be aware, but U.S. GAAP
> and International IFRS standards have specific severe provisions about
> making changes to any previous year's data, especially but not limited to
> any change that affects reported earnings.  Any substantial revision would
> be publicly embarrassing and require issuing revised financial statements
> very publicly and explaining.  Revisions might be (appropriately) avoided
> by argument that, oh, this change may be necessary for accuracy but is not
> material enough to warrant a public revision, so do let's make the
> correction within the next year's accounting without mentioning it.  *And
> even if/when a revision to a prior year is implemented, it is done by
> adjustment of current year balances, without changing the past year's
> accounting!*  Say a significant amount of accounts receivable should have
> been written off, but such expense was not recorded.  A restated Income
> Statement and a Balance Sheet and a Statement of Cash Flows, all taking
> that into account would be issued, but the correction in the accounting
> system is to make a journal entry only in the current year reducing
> retained earnings by that amount and reducing accounts receivable.  Getting
> to where you would have gotten if the proper entry had been made in the
> prior year. Because the prior year's data really really is locked.  I
> mention this by way of supporting idea that fixed date locking is a
> regular, usual, basic feature of an accounting system.  IMO it should be
> allowed in Gnucash.  It would certainly help for use of Gnucash in
> accounting education, where it would be the last step in demonstrating how
> accounting is done for a firm for a year.
>
> I hope this adds some useful new(?) substance to perennial discussion of
> fixed date locking.
>
> Don Cram
>
> On Mon, Aug 10, 2020 at 11:42 AM Stan Brown <the_stan_brown at fastmail.fm>
> wrote:
>
>> On 2020-08-09 20:24, John Ralls wrote:
>>> I think my proposal--using relative dates like beginning of the current
>> month--fits your use case perfectly and would save you the annoyance of
>> having to update the specified date every month and the risk of possibly
>> forgetting.
>>
>> Not so much. I need to accrue taxs at the end of (for example) July, but
>> I don't have the statements necessary to compute the tax amount until
>> several days into August. So neither a fixed "beginning of current
>> month" not a fixed "beginning of previous month" would be idea for me.
>>
>> Seems to me it would make the most sense to let each see decide whether
>> to do number of days, fixed date, or relative date.
>>
>> --
>> Regards,
>> Stan Brown
>> Tehachapi, CA, USA
>> https://BrownMath.com
>> https://OakRoadSystems.com
>> _______________________________________________
>> gnucash-user mailing list
>> gnucash-user at gnucash.org
>> To update your subscription preferences or to unsubscribe:
>> https://lists.gnucash.org/mailman/listinfo/gnucash-user
>> If you are using Nabble or Gmane, please see
>> https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
>> -----
>> Please remember to CC this list on all your replies.
>> You can do this by using Reply-To-List or Reply-All.
>>
> _______________________________________________
> gnucash-user mailing list
> gnucash-user at gnucash.org
> To update your subscription preferences or to unsubscribe:
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> If you are using Nabble or Gmane, please see https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
> -----
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.