[GNC] GnuCash and Swedish accounting legislation

[bengtxyz at gmail.com]

> -----Original Message-----
> From: John Ralls <jralls at ceridwen.us>
> Sent: den 9 augusti 2020 18:02
> To: bengtxyz at gmail.com
> Cc: gnucash-user at gnucash.org
> Subject: Re: [GNC] GnuCash and Swedish accounting legislation
> 
>
> > On Aug 9, 2020, at 2:25 AM, bengtxyz at gmail.com wrote:
> >
> > Would like to revive this old thread since the request made by the OP
> > is still valid for us Swedish users (and maybe German users according
> > to one post in the thread?). I wonder if there has been some
> > development along making transactions "persistent" or
read-only/locked/un-
> changeable?
> >
> > In short the request was made since the Swedish accounting legislation
> > requires transactions to be persistent, i.e. when entered into the
> > ledger it shall not be possible to change it afterward (or rather,
> > entering of the transaction is considered completed when it has been
> > made persistent). To shortcut a long discussion about how silly this
> > requirement is, because you can always change your transactions
> > somehow by editing databases etc., we can postulate that it would be
> > enough to fulfill this requirement if the transactions somehow was
> > made read-only in an irreversible manner from the user interface. I.e.
> > once  a transaction is made read-only, it should not be possible to
> > change it from the UI. ( I also understand that a differently compiled
> > version of gnucash could import the data files and change the
> > read-only transactions, but that would be ok also since the intention
> > is not to fully secure a system against such changes, which is more or
> > less impossible, but make it difficult for the ordinary user to change
> transactions afterwards).
> >
> > Here is the last post in the old thread from 2016:
> >
> > ---
> > On 2 February 2016 at 15:39, John Ralls
> > <https://lists.gnucash.org/mailman/listinfo/gnucash-user> wrote:
> >>
> >>> On Feb 2, 2016, at 8:17 AM, Colin Law
> > <https://lists.gnucash.org/mailman/listinfo/gnucash-user> wrote:
> >>>
> >>> On 18 January 2016 at 08:18, Draug
> > <https://lists.gnucash.org/mailman/listinfo/gnucash-user> wrote:
> >>>> Hi,
> >>>>
> >>>> For quite a while I've used GnuCash for the accounting of my
> >>>> company,
> > but
> >>>> recently I've come to question if it's legal to use GnuCash for
> >>>> that purpose. According to Swedish accounting legislation, you are
> >>>> not
> > allowed to
> >>>> use accounting software that allows you to edit registered
> >>>> transactions (where they use Excel as an example), which to my
> >>>> knowledge is quite
> > easy to
> >>>> do in GnuCash, even after reconcilation. Swedish accounting
> >>>> legislation requires that every mistake is corrected with another
> >>>> transaction, and
> > that
> >>>> the mistake is left intact in the records.
> >>>>
> >>>> Is there anything that I've missed that makes it possible to use
> >>>> GnuCash
> > in
> >>>> accordance with Swedish law? I really want to avoid switching to
> >>>> some proprietary, cloud-based accounting software that costs $12 a
> >>>> month to
> > use.
> >>>
> >>> An email from Geert in a different thread has reminded me that there
> >>> is already code that optionally makes reconciled transactions read
> >>> only. I wonder then whether it would in fact be a fairly simple
> >>> change to the code to make it so that /all/ transactions would be
> >>> locked, dependent on a configuration option that could be set but not
> cleared.
> >>>
> >>
> >> Yes, the locking code is already in place-or more likely, in several
> > places-so it would just take a creation option in the New File
> > Assistant to make a book immediately lock transactions. Like the root
> > account currency, it would be unchangeable once the book is created.
> >>
> >> I don't think we'd want it to be a config option because that would
> > require either that users who want the feature build it themselves or
> > that distros and we provide multiple packages. Building is beyond the
> > ability of most of our target audience, particularly on Macs and
> > Windows, and aside from the distros probably not wanting to cooperate
> > there's a good chance that many users would accidentally get the build
they
> didn't want.
> >
> > Sloppy use of words on my part, I meant a setting rather than a build
> > option, but a creation option would be even better.
> 
> There's already such a facility: Select File>Properties and on the
accounts tab set
> Day threshold for read-only transactions to 1. That makes a transaction
read-
> only the day after it is entered.
> 
> That's obviously trivial to defeat, as a bad user could easily change the
setting,
> edit stuff that they shouldn't, and then put the setting back.
> 
> We've had some discussions about making certain properties settable only
while
> creating the book (principally the root currency). Perhaps this should be
one of
> them.
> 
> It might work, and be even more secure, to use a SQL server (i.e. MySQL or
> Postgresql) backend and after the first creation of the database create a
new
> role with only CREATE, INSERT, and SELECT privileges on the tables and
have
> users log in with that role. There would have to be an admin user with
full access
> in order to accomplish GnuCash upgrades as this sometimes involves
altering or
> recreating tables because of schema changes.
> 
> On the other hand immutable transactions is only one of the controls
usually
> required of accounting software in a large enough organization that
outside
> auditors are involved and that sort of law applies. GnuCash has *none* of
those
> controls so this one feature is unlikely to make GnuCash an acceptable
> alternative. GnuCash isn't designed for that environment and would have to
be
> rewritten from scratch to get there. That's not going to happen and it's
why we
> say that GnuCash is intended only for individuals and small businesses
that aren't
> subject to independent auditing.
> 
> Regards,
> John Ralls

Yes, the read-only day threshold (of 1) would be ideal for this purpose if
it was a creation option of the book. Since the day threshold is
configurable as described above, the feature is not usable for this purpose
now. I put my vote for making such a creation option! 

I think this is what is needed in order to claim that GNC fulfills the
Swedish book keeping requirements in this respect. Many answers here are
based on the assumption that whatever we do in GNC there is always a way to
change a transaction if you have the right SW skills. But I believe that
this is not the problem the legislators try to address, since they also know
that computer records can be changed given enough effort and skills. The
point is, I believe is that the _there should be no way to change a
transaction from within the program_. Compare with using ink for paper
books, making it difficult (but not impossible) to change entered
transactions. 

Using a SQL server and don't allow DELETE for transactions is probably a
good idea also (and probably what is used in commercial packages for this
purpose), but at least I would feel safe to use GNC with a persistent one
day read-only threshold option.

//Bengt