[GNC] envelope method, equity sub-accounts, cash vs. hybrid vs. accrual accounting

[doncram]

The idea of "envelope method" then is to mirror the model of budgeting and
control done by real life envelopes holding the cash allowed to be spent in
each budget area.  This is an inspiring model/image.  The physical model is
very visual, very clear... each envelope of cash is a continuous visible
indicator of how much more can be spent in that category.  It is alarming
if one runs low or empty.  If overspending really does have to be done,
then cash must be "borrowed"/transfered from another envelope/budget
category.  In a household where one person has the envelope for groceries
vs. another has the envelope for clothes purchases, there would be
"transaction costs" or punishments of having to beg other person to fork
over some of their budget.  I see the appeal of trying to make an
accounting/budgeting system follow that.  However....

If implemented by putting budget amounts into separate real accounts where
spending is controlled, say into separate debit cards where an attempt to
overspend one will simply be denied by the debit-card device at a store,
then that would be a pretty good implementation of the model.  To actually
overspend one budget area would require negotiation/transaction costs to
implement a transfer of some balance of another debit card.  In effect a
revision to the budgets.  And actual, perhaps observable balances in each
debit card, would constantly reflect how much budget slack there is in each
category.  This would give the same information as a regular accounting
system, if it was continuously updated for each new transaction, that would
report how much expense occurred in each budget category, and continuously
presented that with the budget amounts for each type of expense.  So budget
slack, difference between budget vs. actual expense in each category would
be clear.  But this multiple debit card system would not require the
accounting transactions to be recorded continously, either manually or by
an automated system which analyzes the apparent expense type for each
charge coming in.  The actual accounting could be done later.

A virtual implementation, say by designating that the asset of a
checking/debit card account is to be understood as divided into a
subaccount assets, one for each expense type (each budget category), would
seem to mirror the envelopes model, where each separate envelope of cash is
indeed clearly an asset.  But... for this virtual system to work, each new
charge of any type would have to be reflected by an entry (manual or
automatic) changing the balance of the proper subaccount.  You could
"pretend" that you are limited in your spending by the remaining balances
of each subaccount.   But again, this would provide the same information,
the amount of budget slack available in each category, as a regular
accounting system where new charges are properly charged to each expense
type, and where there is a continuously updated report of budget vs.
actuals.  No more and no less information, but the entries implementing
reductions in the separate subaccounts aren't proper accounting
transactions.   And proper accounting would have to be implemented later.
In the regular system, the equivalent transactions are just processed as
charges to various expense types, and accounting is done, and the same info
is available.  Is this analysis correct?  Maybe i misunderstand, please
advise.

A further point to consider is that in real-life budget counseling courses,
and in courses like a "Work of Art" program for artists in Minnesota, USA,
what is taught is budgeting by expense type, and then recording the actuals
in each expense type. I have been interested in such for many years.
The course and its manual to improve business skills of artists has one
session/chapter about "record keeping" covering budgets, at
https://springboardexchange.org/workofart/ . An envelope-type system is not
ever taught, AFAIK, i think because it is not better, and it is not as
natural, as regular accounting compared to budgeting by same expense
categories.  Which is what GnuCash and Quickbooks and other packages all
provide, I believe.

I do think the "envelope method" has great natural appeal, and deserves to
be considered in larger discussion about how budgeting can be done.  Like
among other budgeting methods like  "Zero-base budgeting" (and when I look
it up, also there is "Activity-Based Budgeting", "Incremental Budgeting",
"Value proposition budgeting", "Cash flow budgeting", which emphasize
different things in setting budget amounts).  But if I was teaching how to
budget to persons who have never done budgeting before, I would just go
with regular tracking of actuals by expense type, and budgeting in those
expense categories.  Hmm, sorta like the visual appeal of a multiple cash
envelopes system, which has some good psychological aspect, could the
software give happy/rewarding or funny/negative sounds like in a video
game, when charges go through within or exceeding budget amounts?  I
honestly think that would be good.  And such systems should use lots of
visual reporting/charts, like showing red/bad or green/good, etc.

Does this help?  Does it fully address the idea of envelope method?  Maybe
not.

Don


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

> The virtual accounts should not be included in a Balance Sheet. Neither
> will they affect an Income Statement.
>
> Trying to include them in either would of course, make those reports
> incorrect.
>
> Once again, I'm not advocating putting these in the tree under Equity.
>
> Let's take the example of Envelope Budgeting. (since that was the
> original case)
>
> I 'allocate' my earnings periodically to various envelopes based on a
> formula to meet my needs for various categories of expenses. The money
> doesn't physically go anywhere, is not paid to anyone and is neither an
> expense or liability at this point. It is still my asset. I just want to
> remind myself it isn't available to spend on anything but the intended
> purpose. (leaving any remainder open for contingencies)
>
> The virtual accounts allow me to do this. (and they should be asset
> accounts as noted)
>
> When I make the real-world expenditure (or incur the expense if accrued)
> is when the expense gets recognized just as if the virtual accounts
> never existed. And yes, that might be in one lump, because that is what
> really happened.
>
> That's the entire point of the virtual tree. To specifically *not*
> record that expense until I'm really suppose to when it actually
> happens. ('happens' here might be paid, or it might mean incurred)
>
> I don't think cash vs. accrual has any bearing on this. I can follow
> accrual methods and still want to earmark assets but not want actual
> liabilities or expenses to be overstated, or assets to be understated at
> any point in time.
>
> Certainly, a built-in budgeting option along these lines would be nice.
> I use the Budget Module as-is, but it doesn't quite work the way I need
> it to for this method.
>
> Regards,
> Adrien
>
> On 8/9/20 5:25 PM, doncram wrote:
> > Okay i think i understand more, from Marilyn Kimple's case and now from
> > searching about "envelope method" in gnucash-user postings (which Adrien
> > Monteleone pointed me to, thanks!), where Adrien and David Cousens and
> > Micheal Novack have a number of postings, including in responses to Eric
> > Bowen.  Envelope amounts seem to me to mean equity subaccount amounts,
> > which are displayed to remind one that there are purposes/dedications of
> > funds/obligations out there which need to be remembered.
> >
> > My new take on this:  the issue is that Marilyn and Eric and others have
> is
> > that they are generally following cash accounting and are not explicitly
> > adopting accrual accounting.  But they see/know that there are
> significant
> > real-life requirements/purposes out there (e.g. accumulated obligation to
> > tithe, perceived requirement within a nonprofit to keep a contingency
> fund,
> > accumulated requirement to pay taxes eventually related to activities of
> > current and earlier periods), which aren't covered in their
> implementation
> > of Gnucash accounting so far.   What some want to do is to use
> subaccounts
> > within equity to indicate those obligations.  I think this is because
> they
> > feel that the obligations are not precise enough or legal enough or
> > otherwsise real enough yet to recognize expenses and liabilities for them
> > (which would be accruals, i.e. recognitions of expenses (or revenues)
> > before cash has changed hands).  And these users and some advisors here
> are
> > not yet onboard about full adoption of accrual accounting in these cases.
> > So then some come in with ideas about "virtually" recognizing "virtual
> > liabilities", i.e. to partition out an equity subaccount for tithing
> > obligation or tax obligation or otherwise, out of the entitiy's equity.
> So
> > that the Balance Sheet will show the obligation, reminding them that the
> > full amount of their assets less explicit liabilities (if any) is not
> > available for spending on other purposes.   Okay, there are numerous
> > practical problems with this.  For one, it seems that a separate
> accounting
> > system (e.g. a spreadsheet) has to be run offline to keep track of what
> > these "virtual obligations" are.  That side spreadsheet might also keep
> > track of "virtual expenses" being incurred for given periods, i.e. it is
> > recognizing the changes of obligations.  The Gnucash accounting system
> will
> > only sort of recognize that real expenses have been incurred, and that
> > cumulative obligations have grown, when at some future date the tithing
> or
> > tax or whatever obligation is actually paid.  On that date there will be
> a
> > huge tithing or tax expense recognized.  No one else has complained
> AFAIK,
> > but I think it is a problem that Income Statements for any given period
> do
> > not show the growth "virtual liabilities" as as expenses, and that
> Balance
> > Sheets should show the "virtual liabilities" as real liabilities, which
> > they are.  And it is, in my experience anyhow, totally non-standard to
> have
> > equity subaccounts this way.
> >
> > The solution is simple:  recognize that those circumstances are exactly
> > what accrual accounting addresses, and adopt accrual accounting relating
> to
> > these purposes, so maybe ending up with a hybrid between "pure" cash
> > accounting and pure accrual accounting.  You don't have to be perfect in
> > recognizing all other types of potential accruals (say, you don't have to
> > recognize capital asset purchases and then follow a depreciation schedule
> > for them), in order for you to choose to use accrual accounting to do
> what
> > it does well, on a matter or two that are of significant importance to
> you.
>
>
> _______________________________________________
> 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.
>