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

Christopher Lam christopher.lck at gmail.com
Tue Aug 11 23:04:48 EDT 2020


The issue of budgets come back from time to time. There are proposals for
shadow/virtual accounts, and also my proposal for virtual transactions;
none have gained any traction over the years.

https://lists.gnucash.org/pipermail/gnucash-devel/2018-January/041529.html

On Wed, 12 Aug 2020, 8:34 am doncram, <doncram at gmail.com> wrote:

> 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.
> >
> _______________________________________________
> 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