budgeting

nigel_gnucash-devel@unos.net nigel_gnucash-devel@unos.net
Fri, 28 Sep 2001 21:27:30 -0700 (PDT)


On 28 Sep, Todd T. Fries wrote:
> Larry,Josh.
> 
>> Maybe the best thing to get this started is your input on how you have
>> done budgeting [spreadsheet/paper/program-based], and how you _want_
>> to do budgeting.
<snip>

This is where I think I'll throw my two cents in...

> Maybe I should 'text picture it' (greatly simplified):
>                                     August    September  October
>                  Allocated Total  Spent Left Spent Left Spent Left
> Income            1000     1000   
> taxes              300      700    300    0   300    0     0  300
> social security     50      650     50    0    50    0     0   50
> groceries          200      500    172   28   210   18     0  218
> communications     100      400    100    0   100    0     0  100
>                             400
<snip>

What we're currently doing is kinda like that.  I call it "the bucket
system".  It's like the old-fashioned cash "envelope system" (where you
put all your cash in labeled envelopes), but more modern.

We basically say how much we want to set aside each month for a specific
item, and where we'd like to cap the funds for that item (i.e. the
"size" of the bucket).  In Todd's example above, whatever money they
don't spend on groceries in a month gets carried over to the next month.
We do that, too, but we don't want to do it indefinitely, so we cap it.

For "Auto", for example, we set aside $100/month and hope that covers
fuel, maintenance and repairs.  If we only spend $45 this month, we'll
put another $100 in next month and have $145 to spend next month.  If we
don't have any serious maintenance costs (cross fingers), we'll
eventually reach our $500 cap, at which point we'll stop putting money
into the "Auto" fund (assuming that $500 is enough to cover any
"regular" maintenance and that any major repairs are going to have to
come out of "Savings" anyway).  The following month we then have an
"extra" $100, which flows down our chain of buckets and into a category
which doesn't always get filled (like "Discretionary").

At that point we *know* that we have $500 sitting in the bank, and we
don't have to stress about minor repairs or maintenance.  I don't
necessarily care *where* that money is physically located, though,
because I can move money around at will in physical accounts.  So the
"buckets" are logical entities completely separate from any specific
physical account.  (A side effect of this is that when I charge
something to a credit card, I count is as "spent", but it's still
actually located in my savings account, so I accrue interest until I pay
the bill, and I'm *guaranteed* to have the money around to pay my credit
card bill, which means no finance charges).

The whole "bucket system" is actually a little more sophisticated than
that, but that'll do for now.

And now, to gnucash...  >)   To pull this off in gnucash, I think we
need another field in the register, which I'll call "category" for now.
If we tracked a "category" (notice: separate from expense - I track my
video rentals and movie tickets separately from an expense perspective,
but I budget $40 for "Entertainment" every month) for every expense,
it'd be trivial to write a report which read a file containing your
monthly allotments and caps, then processed all your expenses and did
the math for you.

Right now I do it using a *much* ickier and complicated procedure.  I
can make it work in gnucash, so I know the basic philosophy is sound,
but without hacking some new code (which I don't have time for right
now), I'm forced to use a really kludgy manual system which I won't
describe here.


What would be the objections to adding a field to the register?  How
much pain and suffering are we talking about?  Could we add another
"style" of ledger, maybe, so that people who don't *want* the category
don't *have* to use it?

Honestly, I'm willing to write some code for this, and was planning to
at some point, I just really don't have the time right now.

Have fun,

Nato