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, <donc...@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.montele...@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@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. > _______________________________________________ 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.