[Bulk] Re: new user of Gnucash - questions
John Ralls
jralls at ceridwen.us
Sat Mar 26 01:30:49 EDT 2011
On Mar 25, 2011, at 9:12 PM, David T. wrote:
>
>
> --- On Fri, 3/25/11, William Colls <william.colls at rogers.com> wrote:
>
>> From: William Colls <william.colls at rogers.com>
>> Subject: Re: [Bulk] Re: new user of Gnucash - questions
>> To: gnucash-user at gnucash.org
>> Date: Friday, March 25, 2011, 2:37 PM
>>
>>
>> On 11-03-25 03:38 PM, Elizabeth Dodd wrote:
>>
>> <SNIP>
>>
>>> Modern computerised accounting does not have any end
>> of month or end of
>>> year close of books. "Closing Books" at end of year is
>> still popular
>>> but its not a necessary part of computerised
>> bookkeeping. Certainly you
>>> can enter transactions continuously and perform the
>> end of year
>>> functions weeks or months later.
>>> Gnucash does have a close books function for the end
>> of the financial
>>> year.
>>
>> <SNIP>
>>
>> Not entirely true. I have worked with several modern
>> systems that very much had the concept of "closing" built
>> in. The important point about closing is that once a period
>> is "closed", you can no longer post transactions into that
>> period. This means that you may reliably know the state of
>> affairs at a given moment in history, and be sure that
>> no-one has tampered with the information. This has
>> signifigance in a legal context: possibly compliance with
>> Sarbanes-Oxley compliance, Public reporting and so on. While
>> I doubt that many of the users of GNUCash have signifigant
>> S-OX issues, it is something to consider.
>
> The point raised in the lists here historically is that, from a legal perspective, it is very difficult (if not impossible) to guarantee in an electronic environment that a given data set has maintained its integrity. As Derek hinted, the only true guarantee is to create an immutable copy on CD.
>
> Any software package that suggests that you can "freeze" a data set ignores the many alternatives one might use to undermine that (e.g. a text editor or even altering hex codes), and therefore cannot honestly be defended in a court of law. [Heck, even a CD could be reburned with a new data set on a machine whose system date has been altereed].
>
> Ultimately, true legal admissability will depend more on human assurances of system integrity (by 'system,' I mean a broader concept) than on how (or whether) a software package freezes data.
>
We're veering off into "not-Gnucash" land here, folks.. Gnucash very simply is not the appropriate program for a company that has outside auditors. There are no administrative controls, all users are equal and can change history at will, the CoA is
highly mutable (a feature for our SOHO target user-base, a major failure for everyone else), there are no audit functions,
the logging is minimal and not traceable to a particular user.
Gnucash is for personal and (very) small businesses where there are only a couple of people with their fingers in the books, and where there are external means of making sure that nothing funny is going on (like the owner is the only one who can sign checks and has time to know what each one of them is for and to whom it's being paid). If that doesn't describe your operation, then you need a different program, and you're probably going to have to pay for it.
Regards,
John Ralls
More information about the gnucash-user
mailing list