[GNC] GnuCash and Swedish accounting legislation

[doncram]

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.
>