"correcting" transactions

[John Sowden]

On 02/21/2014 12:26 AM, David wrote:
> Thanks, Liz.
>
> John S.-- since you've raised the issue, how would you go about ensuring that an electronic record is secure, original, and untampered?
>
> David T.
>
>
>
> _____________________________________________
> From: Liz <edodd at billiau.net>
> Sent: Fri Feb 21 00:06:56 PST 2014
> To: gnucash-user at gnucash.org
> Subject: Re: "correcting" transactions
>
>
> On Thu, 20 Feb 2014 19:25:01 -0800
> "John R. Sowden" <jsowden at americansentry.net> wrote:
>
>> I have been reading a lot recently about correcting, removing, etc.
>> transactions. This is typically a no no in accounting. I am not a
>> CPA, but I have a general idea of GAAP (generally accepted accounting
>> practices). It does not allow for removing or editing existing
>> transactions without an audit trial. A simple was to do these things
>> is to create "reversing entries" as general journal entries with
>> explanations. If the business owner is the only person using gc, and
>> the resulting reports is only for his/her use, this is more of a
>> formality, but if a bookkeeper/embezzler is using gc, this allows
>> transactions to be hidden/altered. Not a good thing.
>>
>> John
>>
> It's difficult to alter paper records and make them look right.
> Forensic science experts have ways to determine that the pen was not
> the same, the paper was different.
> So required adjustments were made in the way you describe.
>
> Computer files are alterable. You cannot prove that file.gnucash is the
> same today as tomorrow.
> If I wish to alter my books I have far more ways to do so than with
> paper, and it is far, far harder to detect.
>
> Audit trails are not the complete answer to preventing fraud and
> embezzlement with computerised bookkeeping. They may appear to be, but
> we assure you that you need to make copies of your files regularly and
> have them notarised eg have the checksums calculated and notarised on a
> regular basis AND burn copies to read only media, with copies kept in
> more than one place.
>
> Liz
> _____________________________________________
Thank you for the 'scientific'  response.  I'll write a response as I 
think through your response - a dangerous process.  First of all. I 
write database programs for my company, internally.

For some reason I did not see Liz' message.  Let me start by responding 
to it, and then  yours.

  Let me start that I am a small business person with about 45 years of 
experience.  Secondly I run a security company.  In other words, I am 
looking for and aware of violations of honestly that occur in the 
business world.  One of those in in accounting.  The solutions to _most_ 
security issues are simple and expensive:

use proper locks on door and windows.
restrict your security system code and premise keys.
restrict access to private data, on a need to know basis,
if you have a bookkeeper, send your bank statements to a different 
address than you office.
If you use a computer to print your checks, print the numbers on the 
check and compare the number to the check printer number on the check.
pay careful attention when the bookkeeper goes on vacation.
Pay even more attention of the bookkeeper never goes on vacation.

Lets get back to gc.

Notarizing documents only verifies, based on the honesty of the Notary, 
that the document was signed by the person identified by the Notary.

Back to accounting.  There is a long stretch between the sole 
proprietorship with 10,000.00 US in sales
vs. a publicly held corporation.   We are not dealing the the latter.

The accounting program should not allow random edits or deletions of 
transaction.  Period.  It should allow for proper edits so users can 
relay on the program's results.

We seem to be more interested if "features", such as copying data from 
Quick Books, or connections to our banks, than the basic integrity of 
our accounting system.

Remember, it all starts with:

Equity = Assets - Liabilities

Re: the question of how to keep the program secure, I'll give it a try.

Prior to exit of the data entry in the program, a CRC of the datafile is 
created.
Upon entry, the CRC is checked.  If it fails, a warning is presented to 
the user.
No edits or deletions to the transaction database is allowed. Period.
No changes to the account balances are allowed except via valid 
transactions. Period.

In other words, alterations to the transactions database, from which all 
reports are created can only be created via valid transactions.

Part of my concern here is that some of those who use gc in this world 
understand all of what I am talking about.  Others rely on gc as being a 
reliable accounting program that hey do not have to question.  It is 
those who I am concerned about.

There is no complete answer to stopping fraud.  New methods of defeating 
the normal process are invented constantly.  The only answer to this is 
to constantly be aware of violations and to report them to a central 
database when they can be analyzed by those smarter than us (there is 
always someone smarter than ourselves).

John (The Messenger)