[GNC] Gnucash Close Books option

[Peter S. Shenkin]

Hi,

I'm just forwarding the response from "Michael or Penny Novack" to the
list; it was just sent to me directly.

Overall, I think it will be easiest for me to just use "Close Books"
annually. Per Derek's suggestion, if you have to correct the closed year,
"you can delete the closing transactions and re-run the Close Books to
recreate the (edited) transaction".

So the procedure, as I understand it, would be:

   1. Close year X and proceed with year X+1
   2. Notice an error in year X accounts
   3. "Unclose" year X by deleting the closing transactions.
   4. Modify year X as desired.
   5. Close year X again.

-P.

On Tue, Apr 20, 2021 at 10:29 PM Michael or Penny Novack <
stepbystepfarm at comcast.net> wrote:

> Since several things, I'll do little by little. But first, "closing the
> books" goes back to the old, days of pen and ink on paper bookkeeping
> (what I learned). With  bound books, usual to begin the new year with a
> fresh volume. Also, the P&L report had to be created manually and came
> into existence in the process (first all income and expense accounts
> closed to the special "profit and loss" account and then that closed to
> equity).
>
> Gnucash, like most other accounting software, can produce the P&L
> whenever you like without closing the books.
>
>
> > What I don't understand (based on this writeup
> > <https://wiki.gnucash.org/wiki/Closing_Books>) is exactly how it works.
> >
> >     - Following closing the books on year X, will the Dec 31, year X
> >     balances still reflect the year-X income and expenses, or will they
> have
> >     been zeroed at that point?
> If you FIRST make a copy of the file (maybe name pre-close-YE-202x) and
> then close the books and make a second copy (maybe name
> "post-close-YE-202x) you will have preserved both before and after the
> close operation.
> >     - If so, it would be difficult to go back and correct something that
> was
> >        done mistakenly during year X, would it not?
> THAT is a whole other kettle of fish. Traditionally you do not "go back
> and correct" but instead make a correction entry. when the error is
> discovered*. But as I just noted, if you kept a pre close copy you could
> change entries (and then rerun first copy, close, second copy) if you
> are being less fussy/formal about your bookkeeping with PERSONAL books.
> If keeping books for an organization or business, consider doing it the
> :right" way.
> >     - Does the new Equity result appear on Jan 1, year X+1?
> >        - If the two results appear on different days, it would appear
> that
> >        Gnucash can't do this by means of a transaction, because a
> > transaction (as
> >        I understand it) takes place at a single moment in time.
> >        - I have heard that to get around this, some accounting software
> >        creates a fictional date (like Dec 32 or Jan 0) on which it
> performs the
> >        transferring transactions, so that Dec 31, year X reflects the
> closing
> >        balances for the year and Jan 1 is initialized with the new
> > balances. But I
> >        think there would have been mention of this if that is the way
> > Gnucash does
> >        it.
>
> ROFLOL, yes that's what we did where I worked. But it was our own in
> house software and the calendar program "knew" that some dates were
> "special". Most applications like gnucash can't do this because they use
> ordinary date validation. If you look again at what I wrote about before
> and after copies you will see that you can have in effect TWO December
> 31sts, the pre close 31st and the post close 31st.
>
> Michael D Novack
>
> * This provides and example of WHY I was told not to create finish
> reports directly out of gnucash (as a software pro, although just with a
> reading knowledge of LISP could have handled the Scheme). The point is,
> going to need to insert annotations in the financial reports presented
> to the board(s). If going to need the ability to edit anyway, why not
> just export raw reports and then when in the editor deal with pretty
> printing, fonts, etc. a the same time adding any necessary annotations
> << correction of an error in a previous time period would almost always
> need a notation >>
>
>
>