[GNC] closing of accounts, and locking, "not needed in Gnucash"? Needed!

doncram doncram at gmail.com
Mon Aug 10 20:17:51 EDT 2020


Thanks Adrien!  My replies interspersed.  Mainly it seems I use term
"closing" differently than you do.

On Sun, Aug 9, 2020 at 6:44 PM Adrien Monteleone <
adrien.monteleone at lusfiber.net> wrote:

> On 8/9/20 5:51 PM, doncram wrote:
> > In the recent thread with Marilyn Graves, and also in previous threads,
> it
> > has been asserted that closing of accounts at the end of a period is not
> > needed.  But it is needed!
> >
> > It has accurately been pointed out that Gnucash or other modern
> accounting
> > software does not need users to go through manual steps a) to close out
> > temporary account balances (for every revenue and expense account) to a
> > temporary net income account, and b) to close the temporary net income
> > account to a retained income account within equity.  That is so;  the
> > software does that automatically.
> >
> > It may be true (I think it is true) that for an entity that strictly uses
> > cash accounting and does not recognize accruals of any kind, that no
> other
> > closing entries are needed.
> >
> > But, for any entity with full accrual accounting, or with any small part
> of
> > accrual accounting, it is normally necessary to make closing entries,
> > typically dated December 31, to update accruals.  Often requiring use of
> > information not available until later:
> > *use of info from bills known already plus bills coming in during
> January,
> > to make an accurate statement of Accounts Payable as of December 31.
>
> How does the 'Close Books' function in GnuCash accomplish this?
>

I don't think it does.  The person closing the books probably has a
checklist of types of journal entries that need to be put in, which would
be included in what is taught in accounting education as being closing
entries.  After the year is really closed, you want to lock the prior year
info.  (See also "[GNC] GnuCash and Swedish accounting legislation"
thread).  Closing is about getting all that done, finalizing, and then
locking.

If you use the Business Features, your AR and AP accounts are maintained
> properly. If I run a Balance Sheet as of 12/31, I'll see what their
> balances were on that date. No special entries needed.
>
> If I get a bill in January for December services, I simply enter the
> bill with a December posting date. (so it is recognized in the proper
> period)
>

Feels like you are disagreeing, but we are not disagreeing, except in
defining what "closing" means.

Sure, you're right, nothing further in AR and AP is needed if all invoices
in and out are known and were posted using the Business Features.  Do note
that your process of back-dating the posting is probably reasonable, but
also could be considered "falsification" per some views in the
BotanyBayGarden previous thread.

And actually in real life the nonprofit BotanyBayGarden does not post
invoices, which requires two steps;  it just enters cash when received and
when paid out.  But then, logically, a journal entry establishing a total
balance of AR and of AP, based upon side tally of the invoices that were,
or should have been, open on December 31, needs to be entered.  Actually
Quickbooks does not allow a journal entry to do this, AR and AP can only be
increased by posting invoices.  So perhaps a dummy invoice of the total of
AR amounts could be put in, to get by that.  Would Gnucash allow the
journal entry or force creation of an invoice? I dunno.

Alternatively, I can post it with the January date, but posted against
> an Accrued Expenses account with that account containing the expense
> transactions dated when incurred - December. Running the report
> afterwards will properly show the AP balance.
>

That would avoid the "falsification" charge.  Not necessarily better, IMO.

> *if capital assets are being recognized, record depreciation for the year,
> > putting in at December 31.
>
> Done manually anyway as an expense against the asset. This isn't part of
> the 'Close Books' function.


Well it is part of a normal closing checklist:  Review a separate
spreadsheet of capital assets and calculations of depreciation, and enter
it.  Yes the depreciation expense could have been entered lots earlier (as
a journal entry dated December 31, say, when the depreciation is going to
be recognized.  At closing is time to check that, and to check whether any
partial-year depreciation is needed for any new capital asset, etc.  Good
for you if you already did it in advance. :)

>
>
> *if tithing obligations are being accrued, do an update
>
> Again, a manual entry. There is no need to reverse and re-enter
> balances. The balances just continue.
>
> If you run a Balance Sheet as of 12/31 and another as of 1/1, you'll see
> everything is as it should be without any special entries.
>
> > *about taxes due, perform a good analysis of tax obligations stemming
> from
> > the year (i.e. by going through your process of filing tax forms with the
> > government), and then recognizing any additional tax expense if the
> amounts
> > recognized during the year were not enough (or show a negative tax
> expense
> > on December 31 if too much has been recognized), in the process making an
> > accurate Taxes payable balance.
>
> Handled by the Tax Report. No closing entries necessary.
>

Maybe.  I suppose that creates a tax expense equal to the amount of taxes
charged by the government?  Great.

Side comment: recognizing Deferred Tax Assets and Liabilities (not relevant
for nonprofits and most small businesses) would require closing entries.
Tax expense, if defined as what the govt says you owe for earnings in the
year, reflects, say, accelerated depreciation for recently purchased
capital assets which the govt wants to incentivise, and generally follows
cash accounting (e.g. an unpaid account payable is not counted as valid
expense for tax purposes, only cash paid out to vendors is accepted;  an
account receivable is not recognized either, sort of because they are not
real/verifiable enough for the taxman).  Technically, for US GAAP or IFRS
reporting, one must also run a calculation (which can be done in a side
spreadsheet) of "Deferred Tax Liabilities" which include obligations you
know you have to pay (e.g. the tax on the revenue you already recognize in
AR or elsewhere, but for which you haven't received cash payment, and the
additional tax you will actually have to pay in later years of life of the
capital asset because you took acceleration now) and "Deferred Tax Assets"
which reflect your having paid taxes sooner than you should have (e.g. if
you received advance payment on a contract, where you have not yet done the
work and "earned" it).  Adjustments for DTA and DTL actually make your
financial statements more acccurately reflect reality, and are required if
they would be substantial/material.  Surely this is way beyond what the Tax
Report would provide.  These can be entered as journal entries in GnuCash,
in educational setting, are otherwise probably not recognized by small
firms using GnuCash.

Note, to be clear, the 'Close Books' function in GnuCash does only one
> thing - it zeroes all expenses and income to Retained Earnings. That's
> it. Nothing more.
>
> Since the Balance Sheet already can calculate RE from all of the book,
> you don't need to periodically close. Closing was a process of obtaining
> numbers for reporting and carrying forward amounts from previous periods.
>
> But that only matters with paper and ink.
>
> You don't need to specifically make entries to carry balances forward -
> because you aren't moving to a new file that would make this necessary.
> (though you *could* do so, some here on this list practice this, but you
> don't *have* to operate that way)
>
> Okay.  We only differ on semantics of what is included in "Closing".
Right about not having to close temporary accounts, carry balances forward.


> >
> > And so on, for other accruals.  And when you are really satisfied, then
> you
> > should lock transactions up to December 31, so that in the future neither
> > you nor anyone else can accidentally enter transactions that are
> > miss-dated.   Except perhaps changes could be allowed by use of a
> > password.  Within past Gnucash development, there has been refusal to
> allow
> > such locking, but it is an essential, crucial part of accounting, IMO.  A
> > big credibility issue for Gnucash, relative to other accounting software
> > that does allow for such, because it is so basic to professional
> accounting
> > practice.   I am not sure of current state of affairs on this.  One
> > objection to allowing locking, which I recall, is that programmer-types
> > would know how to bypass the locking so it would not be a perfect
> control.
> > However it obviously would be a control that helps avoid accidental
> changes
> > or changes by uninformed data entry staff.
>
> A preference to discourage preventing inadvertent entry and possibly
> editing already exists, though the UI for it could maybe use another
> option or be improved.
>

As just was clarified for me in "[GNC] GnuCash and Swedish accounting
legislation" thread, there is a relative date lock available in GnuCash,
but a fixed date feature, requested by some for many years, is not
available.  This does not match the normal accounting process need for
year-end (fixed date) locking.  During all of the current year, I want to
be able to go back and edit transactions, say to revise/correct where an
expense is charged, even well after the item is cleared in
reconciliations.  I really really want prior year info locked, and some
freedom with all of the open year.

> If you do not update your accruals on December 31, then Income Statement
> > periods ending on that date and Balance Sheet of that date will be
> > misstated.  If you want quarterly reports to be accurate this way (not
> > generally necessary) then you need to perform similar closes on
>
> Looks like you trailed off, but I don't see how those reports will be
> inaccurate without 'updating accruals'. What does that even mean anyway?
> Remember, unless you're starting each year with a new clean file (not
> necessary) then there is nothing to 'update'. It is already up to date
>

Right i didn't finish the statement: if you want Quarterly or Monthly
reports to be fully accurate, i.e. including all accruals, you have to go
in and make the closing entries on the last day of such periods.  Like 1/12
of depreciation needs to be recognized on January 31.  For the nonprofit
BotanyBayGarden, only the year-end/annual reports need to be done up so
properly.

Closing in my terms (which I think are usual terms) probably needs to be
covered in documentation/teaching about how accounting in GnuCash is done
or can be done.  At least for all entities for which accruals are needed in
order for the financial statements to make sense, which is all entities,
probably, IMO.  I don't know of any business, even single-person ones that
I know of, which is purely cash-basis, where there might truly be no
accruals to review.

Regards,
> Adrien
>

Thanks, this does clarify for me how I need to state things within
GnuCash-speak language.  In official GnuCash-speak, then, no closing
entries *as defined in GnuCash-speak* are needed.  Unfortunately this seems
to deny that closing as defined elsewhere exists, and seems to support,
perhaps, not having a lock for the closing date (as if "closing date" is
not a meaningful thing, as if there is nothing special about any date, as
if fixing financial reports by closing at year end is not important).
However in organizations as I know them, closing is an important process
involving a lot of attention, and when that is done, there is particular
need for a fixed-date lock feature to apply to the very real closing date.
As part of how people work together, as part of how organizations work.
Thank you!

Don

> _______________________________________________
> gnucash-user mailing list
> gnucash-user at gnucash.org
> To update your subscription preferences or to unsubscribe:
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> If you are using Nabble or Gmane, please see
> https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
> -----
> 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