budgeting

Josh Sled jsled@asynchronous.org
Sun, 30 Sep 2001 16:47:07 -0700


On Fri, Sep 28, 2001 at 03:04:06PM -0500, Todd T. Fries wrote:

| Spreadsheet.  Wife and I work on this together, and she only understands
| Windows, so it's in excel. ;-(  However, I was charged with finding a program
| that fixes the problems we've thus encountered.  So I have hope! ;-)

>From my perspective, budgeting functionality in GnuCash seems at _least_
3 months away... just for reference...

| Currently we have a list of categories and sub-categories of places our
| money goes.  Income (my check), taxes, social security, groceries,
| communications, etc.  With breakdown of 1-2 levels in most cases,
| imho very similar to the 'account name' sub-account concept.

And would you agree that, while similar to the account hierarchy in
concept and perhaps application, the budgeting hierarchy shouldn't be
forced to be the same as the expense hierarchy?

|                                     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

Okay, so to summarize, here: the primary sheet in the budgeting
spreadsheet is a list of budgeting-categories [either in or out],
with a time-period-based [generally monthly, here] allocation amount,
and a per-time-period actually-used amount.  The difference in the two
determines the carry-foward amount between time periods.

| And on another 'sheet' we have a running log of the money we bring in
| and spend.

I don't see how this is substantially different from the above... a little
more detail, please?

| I'm very much tempted to setup expense accounts to be the budget, so we
| can track things that way.  It would be very helpful if somehow I could
| 'expense' something twice.  Aka if I could write that the money, via an
| electronic debit at a grocery store, disappeared from the checking account,
| and was listed under both 'groceries' and 'Walmart'.  I suppose I could
| create an expense category 'groceries' and have 'Walmart' underneath of
| it, but this doesn't help if I want the higherarchy to be:

But that's not quite right, it seems.

The fact that a transfer of money occured is encoded in one split [Memo:
Walmart, split's account: checking, split's action: "debit" or "electronic
debit" or something]; the fact that it was for groceries is encoded in
the balancing split [memo: "food", account: expense.groceries]... with
subsequent splits for any finer granularity you want on the line-items
of the grocery receipt.  Is there really a call for "Walmart" to have
first-order involvement in the transaction?

It seems like the goal here is to be able to say "we spent $x at Walmart,
and $y at S-Mart", which I think can be done with a Transaction report
[which doesn't seem to exist, yet] which can look at a subset of the
transactions ... say, those which reference "Walmart"/"S-Mart" in the
Memo field...

| So until we 'save' enough to open a savings account, we're stuck keeping
| track of it being 'available' somewhere between the checking, paypal, wallet,
| and purse accounts, if you know what I mean.

Yes, I know what you mean... [see below].

| I'd like to have, as I'm sure is common for others, the ability to specify
| a budget effective for a period of time, that is pretty much the same for
| each period of time beyond.  

Yes... it seems like a good use-case for the budgeting subsystem is
along the lines of "let's take the existing/active budget and 'convert'
it over to a perhaps-substantially-similar budget for the next N months".

| We deal with a budget on a monthly basis,
| although things like eating out would be nice to deal with on a weekly basis,
| and other things, like car tag fees, on a yearly basis.  

Indeed... this is a somewhat tricky problem about all this.  I think
people want to deal with a budget on a monthly scale, most of the time.
But, as is obvious, there are yearly [and multi-yearly] expenses which
should be handled by the budgeting system, even when the month-to-month
budget changes.  And, people also want to be able to see on a daily basis
where they sit WRT their budget...

:I

In fact, I think that's why you have the
base-a-new-budget-on-the-previously-active-budget... because there's a lot
of data about longer-term budgeted things that wants to be preserved and
respected while the weekly- and monthly- things may shift around over time.

| We also are
| saving money for a few things, such as future 'hopefully not but everyone
| knows how it goes' car repair, house, income reserve (economy suggesting

Definitely want to support different savings goals, yes... and as Nato
points out, these may be "capped" in useful ways [we should save until we
have 3x<monthly_income> saved for our emergency fund, then stop allocating
toward that].

So, there are Savings Goals.  Savings goals have the properties of:
. goal/amount [or open-ended]
. time-horizon [to know how much we should allocate per time-period]

| it is possible to keep track of 'pools' of money independent of what
| account it is in?  For example, we have 'educational savings' since my wife

Hmmm.  It strikes me as both useful and not-useful... depending on the
situation.

Example: We have two accounts A and B.  We have two savings goals, X and Y.
Let's assume that they're both at their goals; X is $1000, and Y is $2000.
We have all $1000 of X in A, and $1000 of Y in A.  The remaining $1000
of Y is in B.  Thus, A contains $2000, and B contains $1000.  However, we
could equivalently say that A contains all of Y, and B contains all of X...

However, this assumes that the accounts are equivalent, whereas in
reality they are likely not.  For instance, 'A' may be a less-liquid or
less-accessible account, in which it is not desireable to place allocations
toward short-term-needed savings goals.

So, we have to have knowledge of the Savings Goal, and knowledge of the
accounts in which money may be stored.   There's also some integration with
interest and the time-value of money... we shouldn't have to put $100/mo
towards A if interest is going to be made on the previous allocations... and
then, after the Savings Goal cap is reached, there is further income from
interest associated with that savings, which should be handled in some way.

The time-value of money should be respected for planning out-flows as
well; it is definitely useful to accelerate loan-repayments such that the
principal is reduced quickly [within any penalty-inducing rules/limits
related to the repayment schedule]...

This is making my head spin, a bit.  I need to review my engineering
economics text and likely some other accounting sources.  I also think
we're beginning to get close to a budgeting/financial-planning line in
the ether that's a bit tricky; we don't want to overload the feature set
of this so it becomes impossible to build.  OTOH, there are definitely
aspects that people would find useful...

I think my original plan had it correct: there should definitely be
phases of implementation of this.  The initial phases should have
the basic support for budgeting, and later phases can have the nifty
financial-planning features.  We'll figure out in the course of that
where things should go and how they can/should be done.

| So for budgeting, it would be nice to keep track of money 'in' and 'out'
| for a given month, and sub-categorize each to the nth degree.

Yes... a primary requirement of the budgeting system is knowledge/use of
the "direction" of money, as budgeting deals with money "in motion".

| As well as carry forward money, but not for all categories.

Another primary requirement.

| I don't know if this helps, but .. hopefully it provides some input you
| were requesting!

It definitely helps; thanks for the [continued, hopefully] input! :)

...jsled