Budgeting in GnuCash

[Ben Stanley]

Joshua,

I'm glad you are looking into this. You seem to have put in some serious 
thought. I wish to add some comments, though.

   A budget is a tool by which a user can compare expected expenses to
   the history of actual expenses, for the purposes of better allocating
   income. Once realistic budgetary limits are obtained, the user can
   then project forward to plan for future expenditures. The goal with
   any future-based financial tool is to manipulate the difference of
   income to expenses, in order to further utilize available financial
   resources.

I wish to use the budgeting to exert rigorous control over my expenditure, in 
order to *limit* it, not merely to track it. I suppose that this is where the 
money in envelopes method comes into its own. It's pretty difficult to limit 
expenditure when everything is actually stored in one place (bank account, 
cash), and the allocations are stored separately to where the spending 
decisions are made (at the mall)... 

I think that you've managed to capture the idea of what a budget is. However, 
you have not indicated much about your method of implementation. Here are 
some practical questions:

Will you use a completely separate set of data structures to represent the 
budgeting information? (This seems inevitable if we are to escape using the 
recurring transactions hack.) 

Where will the budget information be stored? (I heard a rumour that the data 
file format was being expanded to find a place for this kind of information - 
how far away is this?)

How does all of this interact with the GNUCash requirements of being able to 
store the information in an SQL database? Storing the budget as extra 
information may add considerable complexity to the separate back-end problem.

As for user experience flow, my wife and I have already drawn up a budget of 
spending - by reviewing our previous expenditure. We have tried to use the 
budgeting component of Microsoft Money (a 1995 version) without any 
success... of course I hope we will be able to come up with a better 
solution. I think that the lack of success with the Microsoft approach was 
that it took, essentially, a report approach to budgeting. It had poor 
support for regular expenses and regular contributions - it allowed you to 
set an amount per year. It then allowed you to compare your current 
expenditure against your yearly goal. Of course, it's easy to 'look good' 
toward the beginning of the year, but run out of money half way through, 
because it did not take time into account. It is important to ration the 
funds as you go, and to incorporate time into the reports.

Looking again at what I have said above, I think that the biggest problem was 
probably the lack of support for examining the budget at the current point in 
time - and comparing it with where I should be right now, not at the end of 
the year. Given this, I think that the implementation done as reports 
probably had little to do with it's failure in our case.

If you want to discuss my and my wife's opinions of how a budget should work, 
we are happy to do so. drop me an email.

You have put a lot of work into that design document - are you doing it as 
assessment for an educational institution?

Ben.