undo close books?
Geoff Jankowski
geoff.jankowski at me.com
Sat Oct 5 13:35:03 EDT 2013
David
A very clear explanation of the issue.
For those of us that need to lock their accounts, we can work around the limitations (not intended pejoratively) of Gnucash by paper records and file copies suitably named but it would be a real benefit and would open a much larger (professional) market for Gnucash if these changes were to be made.
Geoff
On 5 Oct 2013, at 08:12, David Cousens <davidcousens at bigpond.com> wrote:
> There seems to be some confusion between the concepts to balancing the
> books, reconciliation, adjustments, closing the books for a period and
> locking of records and/or files and the purposes of and reasons for
> doing/using each. My apologies in advance if the following is exceedingly
> verbose and has a good dose of teaching mother to suck eggs and also for any
> omissions and errors in my synthesis of the extended argument.
>
> Balancing the books is inherent in the double entry bookkeeping system and
> the accounting equation and in the recording of a transaction as a debit of
> one account and a credit to another account.
>
> However an individual account does not necessarily have to be balanced (in
> the sense that the sum of debits and credits to that account has to be zero
> in an individual accounting period), whether the period is weekly, monthly,
> quarterly, semi-annually or annually. E.g. this is not generally true for
> long term asset accounts or similarly long term liability accounts. However,
> over the period of the lifetime of the asset or liability, it will become
> true when the asset is written off or disposed of or depreciated to zero
> value.
>
> It is generally true of income and expense accounts which are used primarily
> to record transactions which relate to objects or services whose "lifetime"
> is generally less than or equal to the accounting period is use (determined
> by a combination of business needs, external (e.g. legislative) and internal
> reporting requirements and conventions of accounting practice), but only
> because the closing transactions transfer the balances out of these accounts
> into an equity account. There is no inherent zeroing of an account in the
> recording of the transactions
>
> Reconciliation as used by accountants and businesses is primarily a
> methodology for reconciling external records (bank statements, invoices
> received and sent , receipts etc.) of transactions against the internal
> records recorded in the books/accounts, i.e. making sure the taxman and
> shareholders and other stakeholders will be happy with your accounts as
> presented to them. It is frequently done at a sub-period e.g. weekly or
> monthly in an annual accounting period so that the task is done in small
> manageable chunks ( and errors don't creep in as a result of fatigue).
>
> Adjustments are generally made at the end of an accounting period, prior to
> closure of the accounts. These generally correct the accounts records to
> ensure income is recorded in the period in which it is earned and
> expenditure is recorded in the period in which it is incurred (accrual
> accounting), not necessarily when the cash changes hands (cash accounting).
> E.g., you pay your insurance for the year in March and your accounting
> period runs from June to July. Unless the tax legislation in your
> jurisdiction allows your business to use cash accounting, the portion of the
> premium from March to the end of July is recorded in the current annual
> period and the remainder is recorded in the next annual accounting period.
> The adjustments reflect the fact that even though the cash was handed over
> in March, the expenditure is incurred across two accounting periods. They
> may also be used to remove non-business income/expenditure from your
> business records.
>
> Closure of accounts is the process used to determine the profit /loss
> surplus/deficit for non-profit organisation, increase or decrease in net
> worth for an individual) over the period. It is not just a requirement of
> accountants per se, but a consistent method for extracting the profit or
> loss for any period when the books were actually physically kept in books.
> It generally takes place after both reconciliation and adjustments have been
> carried out and involves transactions which make the account balances of the
> temporary (income and expenditure) accounts zero at the end of the period by
> transferring the values of those balances to an equity account profit/loss
> summary account, which records profit and loss for the period . Further
> transactions to record tax liabilities ( which may depend on profit or
> loss), distributions to owners/shareholders etc., retention of earnings
> within the business, often take place during or after closure of the
> accounts. The closing balances of the fixed (equity, asset and liability
> accounts) then become the opening balances for these accounts for the next
> accounting period.
>
> It may be argued that a report of profit and loss for any desired period
> can be produced from the computer records and that closure is not really
> required, however it also involves the transfer of profit/loss into equity
> to establish the net worth of the business after taking out distributions to
> the stakeholders in the business by dividends and or owner withdrawals of
> capital from the business.
>
> Locking of records or accounting periods or files is intended to prevent
> changes to records which have already been reconciled and/or closed. If
> these processes have been done correctly, in principle there should be no
> need to alter past records. In practice, who completes their annual tax
> return on the last day of the financial year and often vital information
> arrives after completion of a given period not necessarily within it.
>
> Michael Novak's point about file and record locking and absolute security is
> clearly valid, however there may be value in a user being able to restrict
> alteration of records to the current period being worked on simply to
> prevent accidental entry of records into previous periods. Who has not
> accidentally typed the wrong date into an entry? That then makes two
> periods incorrect, the one it accidentally went into and the one it was
> supposed to go into. Realising you have made the mistake is necessary before
> you can start the search to find and correct it. As an accountant if you
> are coping with shoebox bookkeepers you may also not always be supplied with
> the data in an ordered or complete form. As a business formal records do not
> always reach you on time, get lost, misfiled etc.
>
> Preventing the deliberate alteration of past records is difficult and not
> even desirable. However having the ability to restrict the period for which
> data entry is currently being carried out to a set range of dates (and to
> change that range as desired or needed) could perhaps meet the user
> requirements that Geoff Jankowski has identified of minimising the
> likelihood of adding an incorrect transaction, while still using a single
> file for multiyear periods, with the clear reporting advantages that has.
> For those sufficiently confident that they never make mistakes, an open date
> range could be set. I am not sure how difficult this would be to implement
> and whether the developers are willing to consider implementing such a
> restriction on data entry, but it would obviously involve a fair bit of the
> existing engine code.
>
> This wouldn't require file or record locking and the use of snapshot
> backups appropriately labelled and consigned to CD, DVD or print out could
> any meet external requirements for permanent unalterable record keeping as
> both David and William suggested.
>
> David Cousens
>
> -----Original Message-----
> From: Derek Atkins [mailto:warlord at MIT.EDU]
> Sent: Saturday, 5 October 2013 12:51 AM
> To: Tommy Trussell
> Cc: GNU Cash User
> Subject: Re: undo close books?
>
> Tommy Trussell <tommy.trussell at gmail.com> writes:
>
>> One thing that you CAN do to "lock" changes to an account in GnuCash
>> is to BALANCE the account. Then (unless you have chosen to ignore the
>> warnings,
>
> And by "BALANCE" you mean "Reconcile", right?
>
>> which you can always reset) GnuCash will warn you before you make any
>> sort of change to the accounts, even to the text of transactions
>> (which wouldn't affect the balance).
>>
>> For example I often balance even my Cash in Wallet account; not so
>> that I don't accidentally change old transactions, but so that I can
>> have an estimate for the money I have spent but neglected to record.
>> However, having all my current asset accounts balanced makes it much
>> less likely I will change an old transaction. (Sometimes need to
>> update a description on a balanced transaction, so I acknowledge what
>> I'm doing and proceed. I never change the transaction amounts on a
>> balanced account because that would cause trouble.)
>
>> Please remember to CC this list on all your replies.
>> You can do this by using Reply-To-List or Reply-All.
>
> -derek
>
> --
> Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
> Member, MIT Student Information Processing Board (SIPB)
> URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
> warlord at MIT.EDU PGP key available
>
>
> _______________________________________________
> gnucash-user mailing list
> gnucash-user at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> -----
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.
More information about the gnucash-user
mailing list