Argh, i misspoke i guess, "adjusting entries" is the more accurate term than "closing entries" for these accruals. But implementing the adjusting entries is in fact part of "closing the books", and I think my usage is not so bad. However, in the language of intro accounting (the only place that closing of temporary accounts is ever mentioned AFAIK), "closing entries" means exactly what Adrien said, not what I said. I'm sorry. However, I don't think anyone in an organization ever speaks of "closing entries" that way, I am pretty sure that "closing entries" and "adjusting entries" in practice would both be understood to be what are defined as adjusting within intro accounting. And closing the books or closing the year is what the bigger process is called, not "adjusting the year" or anything like that.
>From one intro source "*Closing entries* , also called closing journal entries, are entries made at the end of an accounting period to zero out all temporary accounts and transfer their balances to permanent accounts. In other words, the temporary accounts are closed or reset at the end of the year. This is commonly referred to as closing the books". And "*Adjusting entries*, also called adjusting journal entries, are journal entries made at the end of a period to correct accounts before the financial statements are prepared. This is the fourth step in the accounting cycle. Adjusting entries are most commonly used in accordance with the matching principle to match revenue and expenses in the period in which they occur." (two short quotes from www.myaccountingcourse.com/accounting-cycle, which is basic stuff, simply not copyrightable, even in very long passages) So, in GnuCash-speak and in introductory accounting in general, closing means zeroing out temporary accounts, etc. In the bigger world, I think closing means what are called adjusting entries in introductory accounting, and a bit more. However it is called, there is great meaning attached to the end-of-period position achieved by these entries and all other review/modifications. This matters a lot, especially to anyone being paid a bonus depending upon the earnings number reported. And it needs to be covered in documentation/teaching of GnuCash to be understandable to more persons, and the ending position should be lock-able, IMO. Don On Mon, Aug 10, 2020 at 6:17 PM doncram <donc...@gmail.com> wrote: > 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.montele...@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@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. >> > _______________________________________________ gnucash-user mailing list gnucash-user@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.
