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

[doncram]

Hey, a breakthrough maybe, as I just found an example "envelope budget"
style report, in
http://richwithnojob.com/wp-content/uploads/2017/05/IMG_4816-169x300.png ,
a May 2017 blog posting titled "How I’m reducing my budget by $1k this
month." at WordPress blog-site "Rich With No Job".  The blogger is
explaining use of "GoodBudget" app on their iphone.  I do like the
"envelope budget" style report showing where they are, at mid-month, in
their spending on numerous discretionary categories (including monthly
budget of $500 for "Books/personal development", $60 for drinking out, $50
for drinking in, $60 for lunches out).  It is visual and data-intensive,
showing for each category its budget, its actuals so far, the budget slack
remaining, and, interestingly, a tick mark showing how far along in
spending they would be if spending evenly over the month.  If their actuals
bar runs past that, a little suggestion is made "You're behind by $21.02.
Stop spending for two days?".

Clearly some do enjoy the "envelope" concept, and there's no reason not to
present a report this way.  The sole user of the system apparently must
enter each spending transaction they make and use pull-down to categorize
it.  "Turns out that manually entering this stuff makes you very conscious
of what you are spending", they note.  Their entry is exactly the same as,
in the regular conceptual view, their entry of an expense transaction.
This app is where they are doing their accounting.  Actually, I would
really like it, in a multi-person organization, if each authorized spender
was promptly recording such entries, and if those could be swept back to a
regular accounting system at least once a day.  And I would like it if each
of them could see the status report, right at the place and moment of
almost making a new expenditure.  If they go ahead and spend, and this is
the transaction that brings the category over-budget, then I'd like for the
app to make an unpleasant sound, or scold them, or give them an electric
jolt!  It really could be the trigger for sending out an email or other
notice that brings scrutiny, or for requiring a review meeting.  And in
many settings, this would work fine even with once-a-day updating of their
data.  Another nice feature is a second report listing all the recent
transactions in this category.  That would really help put one spender I
know on notice, with no excuses that they thought some refund transaction
say, was going to go through or the like, freeing up slack, when the
transaction log is showing it already did go through.  Or helpfully letting
them know some big, anticipated expense had already gone through, so the
slack shown is really available.  Or showing them that, rats, another
spender just got in their expense first and now there is no slack. This app
is providing all the info that is immediately relevant, which is still just
a very small part of all accounting and budget info, without requiring the
user to wade through big reports to try to look up these data and then do
computations in their head.  It is very simple, really nice, and is within
the envelope budget conceptual world if they choose that configuration of
reporting.

Most of this sounds just like defining a nice app, which could be separate
from GnuCash, only requiring access to the current GnuCash data once a day,
say, perhaps not requiring any code change in GnuCash at all.  But it
should also be able to go in and change the GnuCash data itself, to add the
new transactions entered by the users.  I would hope that duplicate entries
coming in this way vs. entries coming from banking, could be handled
automatically. Programming-wise, would receiving new data actually require
GnuCash to change, or could the app's system simply operate upon the
organization's data files.  I do think it would be really cool, if GnuCash
could accommodate this.  Am I correct that GnuCash development does not
cover multiple-device systems, that the GnuCash system would not itself
include the app. Anyhow,  Christopher et al., now does this sound like what
you want?

Don


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

> Thanks Christopher for pointing me to that discussion, which is roughly
> about requesting an envelope method be implemented into GnuCash.
>
> I am just beginning to test the budget features within GnuCash.  What i
> see at first looks reasonable: when you begin to create a new budget it
> provides a big spreadsheet view, with columns for months going forward, and
> rows for each of your revenue and expense accounts, and you can start
> editing in what your budget is for each expense for each month.  This seems
> normal and useful.  The documentation (GnuCash Tutorial and Concept Guide's
> chapter 14 on Budgets and its section on budget reports within chapter 10
> Reports)  doesn't go very far yet.  It doesn't give any example, and the
> reports it mentions sound like they are only reports of budgeted numbers
> put in, but those named reports .  It doesn't mention any report showing
> Budget vs. Actual amounts for a given period, but I assume something like
> that must exist.  I will test more, and hopefully will find that it is a
> pretty complete, normal system, i.e. implementing budgeting as covered in
> managerial accounting textbooks.
>
> One can do budgeting and compare budgets to actuals in a spreadsheet
> outside of GnuCash;  it would be nice if the GnuCash features do in fact
> give nice reporting of budgets vs. actuals, etc., that might meet the needs
> of some small nonprofits or businesses.
>
> About implementing some "envelope method" approach, I think that would be
> very radical, and that it would not be reasonable to devote programming
> effort to it before it was proven to be useful in real life. I haven't see
> it demonstrated in a spreadsheet-based example, even.  Are there such?  My
> first browsing finds no academic articles, and only a few blog-type
> mentions.  One of those is by a person named Chris Lam asserting it is a
> thing (
> https://smallbusiness.chron.com/double-entry-accounting-vs-envelope-system-34783.html ),
> but it sounds like it is meant as a thing for a firm which does not have
> double-entry bookkeeping.  If it is a thing, I suspect it is only a thing
> for entities like households that wouldn't be using GnuCash.  There is blog
> "How to Use the Envelope Budgeting Method" at
> https://www.thebalance.com/what-is-envelope-budgeting-1293682 , which
> claims software exists and links to a blog at
> https://www.thebalance.com/you-need-a-budget-4-budgeting-software-review-1293601 which
> recommends use of YNAB software (You Need A Budget) This blog article gives
> no example reports but describes  a process involving your setting envelope
> amounts (equivalent to your setting budget amounts for each type of
> expense) and then entering transactions as the period goes along, so that
> the software can report how much remains in each envelope.  This seems
> equivalent to, and no better than, a regular budget vs. actuals report,
> which likewise shows the budget slack for each type of expense.  Even if
> there is no substantial difference, perhaps there is a way for YNAB to
> format reports which seems nicer for some?  Andrew Marder in
> https://blog.capterra.com/simple-small-business-accounting-using-the-envelope-method-to-save-time-and-cash/
> describes a small business literally using envelopes, upon which each
> expense/usage of cash is written, with the receipt being put inside.  He
> observes this may be a gentle way for a mini-business to start, on the way
> to getting a real accounting system.  Another article,
> https://www.moneycrashers.com/envelope-budgeting-system/ , by Casey
> Slide, a self-described stay-at-home mom, is actually recommending to
> switch from a regular budgeting system (in which there may be no real
> prevention of overspending), to a system with cash only, literally, put
> into real envelopes.  With no use of credit/debit cards at all. This is
> just like the classic recommendation that to get control of their spending,
> a person should start by cutting up all their credit cards, so they can't
> run up charges.  And further they're supposed to really stop spending in
> one category when its envelope is empty, without borrowing from another.
> This is, like, motivational, not practical;  I guess it could work for,
> like, the classic example of a rich woman having a big allowance from her
> husband, where her spending is really discretionary, when the husband gets
> mad and limits her to only spending from an allowance for the month given
> in cash, with resolve that he won't give her more.  Any nonprofit or small
> business is not like that, cannot operate that way even as an exercise for
> any period of time, but cause it just can't stop spending in a category
> when spending has to be done.
>
> Christopher, thanks.  If you could expand on any advantage of what the
> reporting might look like, or explain any advantage for an
> envelope-inspired approach, that would be great.  Or could you point me to
> any article/blog that actually gives example reports?   But I am not any
> more convinced that any envelope method should be mentioned anywhere in
> GnuCash, much less implemented in some way in software.  Not that it
> matters what I think, but I am interested. Anyhow, thanks for directing me
> further.
>
> Don
>
>
> On Tue, Aug 11, 2020 at 9:05 PM Christopher Lam <christopher.lck at gmail.com>
> wrote:
>
>> 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.
>>>
>>