Future allocated money, aka Envelope Budgeting

Mike or Penny Novack stepbystepfarm at dialup4less.com
Fri Feb 2 08:21:26 EST 2018

On 2/2/2018 7:04 AM, Wm via gnucash-devel wrote:
> On 31/01/2018 16:09, Christopher Lam wrote:
>> Hi Matt- I thought this should move to the devel list, because of 
>> technical details, and this discussion will be very speculative.
>> I had a thought about how envelope budgeting could work: "divide your 
>> paycheck into separate envelopes for different purposes".
>> A solution: *Create another type of transaction.*
>> There's already u(n)reconciled, (c)leared, (y)reconciled, (v)oid 
>> transactions. And (f)rozen I believe is unused. Let's create a new 
>> type - (b)udget. But the balances are handled differently.
I disagree that the time is yet ripe for this discussion to be on the 
developer's list. It should be there only AFTER the "what is wanted" has 
been fully defined from the user perspective. The reason some of you 
think the time IS ripe is that you are missing some of the potential 
complexities of the behavior desired << you are considering only the 
special case where the amounts are equal >>  That I can see "special 
case" is that although I don't use "envelope budgeting" I frequently am 
dealing with an analogous situation where the amounts are sometimes 
equal and sometimes not*.

To see this limiting the context of "envelope budgeting" we need to 
realize that there are two types of envelope budgeting, strict << CAN'T 
use more than what is in an envelope >> and less strict where if an 
expenditure DOES use more than what is left in an  envelope the 
remaining portion comes from some other envelope of general funds. I 
contend that this IS the real situation that most people using "envelope 
budgeting" face. Yes, you may have allocated a certain amount for the 
envelope for "dining out" or other discretionary activity BUT if the 
envelope say for "gasoline" doesn't contain enough to fill the tank you 
are likely to decide to skip going out for dinner rather than give up 

I am suggesting that IN GENERAL going to use manual adjustment/choices 
so the call to automate premature unless can deal with those issues.

Michael D Novack

* Examples from my world (accounting for non-profits)
      The organization has a fund for "zero turn mower for orchard Y". 
The fund has built up to a balance of $2400 by the time the mower is 
purchased for $2700. All the funds in the special account are used plus 
$300 of general funds.

      The organization sells tee shirts as a fund raiser. For 
non-profits, gross sales and cost of goods sold are line items on the 
990/990-EZ. So the sale of a tee shirt is a debit to cash, a credit to 
gross sales, a debit to cost of goods sold, and a credit to tee shirt 
inventory << but presumably the latter two amounts are less than the 
first two or would not be making a "profit" >>

      And yes, I am able to do a "two side split" transaction, but even 
for me might be quicker/easier to do it in two simple transactions.

More information about the gnucash-devel mailing list