Budgeting proposal

Greg Troxel gdt at ir.bbn.com
Wed Apr 16 09:46:37 CDT 2003

I don't see why available credit is linked to budgets, unless you mean
projecting available credit at future times.
In that case, I wonder if budgets should be represented as a special
kind of Scheduled Transactions.  Is it the case that one wants to ask:

  If all the budgeted transactions happen as expected, what will be
  the account values at future time T?

So there could be a way to temporarily apply future budgeted
transactions for report purposes.

A nuance is that if one has a budget of $100 for gasoline for a month,
and it's the 20th, and has spent $40 on gasoline, then it isn't clear
what should happen when predicting total gasoline spending for the end
of the month.  $100 is a good guess, and 30*($40/20) would also be
reasonable (from the earned value/estimate at completion mentality).

I'm not trying to suggest that this all be done at once, but I want to
raise a few complexities in the hopes that the budget architecture
will admit (later) clean solutions:

It would be nice to have a way to automatically derive budgets from
history.  This raises the issue of having multiple budgets, a
descriptive budget based on history and a normative budget based on
what you have decided to do.

In my homegrown (crufty, and I'm moving to gnucash) double-entry
bookkeeping program, I represent budgets for some things by
transferring a fixed amount of money from my main proprietorship
equity account to a subaccount, e.g. $100/month to proprietor-amaint
for auto maintenance.  These expenses are bursty, and I don't expect
any particular month to come close to the budget.  But, the average
over a year is interesting and has reasonable predictive value, modulo
cars getting older.   I have not tried to use this mechanism to
predict future account values, but the notion of an average expense
and keeping track (on a permanent basis) of how the average to date
and the expected value differ is appealing to me.

        Greg Troxel <gdt at ir.bbn.com>

More information about the gnucash-devel mailing list