Budgeting in GnuCash

[Joshua Sled]

On Fri, Dec 01, 2000 at 02:46:12PM +1100, Ben Stanley wrote:

| I wish to use the budgeting to exert rigorous control over my expenditure, in 
| order to *limit* it, not merely to track it. 

Limitation is hard when the program is not the originator of transactions.
In my example, bills are set up to be paid by Bank of America, and
when I d/l my monthly statement, they appear.  If/once OFX support is
implemented, then this will change... but most people probably pay their
bills independent of GnuCash; day-to-day and other spending is even worse.
At the time GnuCash learns of most transactions, it's hard/impossible to
exert any influence about spending habits.

At this point, however, recommendations and restructuring can be done.
"You've overspent in category 1, but underspent in category 2, so you're
okay for this month.  Would you like to change the size of these categories
in your budget to be more appropriate?"   If no, then the user is aware
that they need to limit spending in category 1.

GnuCash can not imbue the user with willpower, but can help them know
when and how they need to exert it.

Others have mentioned the idea of a budgeting tool limiting spending;
Matthew Vanecek <linux4us@home.com>, for instance, says:
  "I want a big ol' bat that'll bash me over the head when I exceed the
   budget!! (trying to buy a house. :/).  Seriously, I'm thinking Budget as"

The idea was brought up on IRC that we could do something like
"rm `find ~ -type d -iname porn\*`", but this seems excessive. :)

| I suppose that this is where the 
| money in envelopes method comes into its own. 

Yes.  Personally, I never want to touch paper money again, but I see
how this idea has it's merits.  In this case, I think the budgeting tool
allows people to determine how much money should be put in the envelopes,
as well as recommending how much shouldn't be put in the envelopes [for
savings], and how those envelopes should be readjusted over time.

| 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)... 

Yes.  Maybe some PalmPilot application can help, here, but I'm trying
to keep that idea out of my head for the moment. :)  It can also help
with creation of the budget in the first place, but PocketQuicken may be
enough... and I digress...

| 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:

Yes; I'm not there, yet.  I haven't even really looked at the GnuCash
codebase.  I'm trying to keep my ideas independent of that [and of outside
influences such as Quicken/Money] for the moment.  This will change, soon.

I expect such a document will come about towards the end of the month, maybe
the beginning of next month.

| 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.) 

Yes.  I've only given this cursory mental time as of yet, but I think
for various reasons it's external to the account tree.   But I need to
see what's up with the existing GnuCash structures before saying any more.

| Where will the budget information be stored? (I heard a rumour that the data 

Somewhere near the "top level", about the same level as the account tree.
The budgeting categories can span multiple expense accounts/categories,
so they should be external... I think.

| 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.

At some level, the budgeting structures will just be structures, which
generally lend themselves well to being in a database.   I don't think
this will present itself as a hard problem.

| 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.

Ack!  They seemed to have gotten an excessively-wrong granularity, then.

| 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.

Maybe.  A report-based approach is useful, insomuch as it's relevant
to the moment.  It's also generally lightweight in terms of the user
point-of-view, and sometimes just that passive information is good.

It's become clear that while the natural time period to work with for
budgeting is the month [bill cycles, payment cycles, &c], and it's important
to recognize and support that, the budgeting UI should be available at
any point in time with nearly-equal functionality... you should always
have an up-to-date picture of your finances, even if it just says that
you have expenses A, B and C upcoming, and if those are paid as expected,
then you will have $X, $Y and $Z after each...

But the thing that excites me is when it stops becoming a report and instead
becomes a chance to interact: what happens if A, B and C becomes A, C, B?
Or A, C, <salary deposit>, allowing a delayed B to be done...

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

No... a) I want to thoroughly and completely tackle this problem, and b)
I just like making relatively structured documents.  At some point, I'd
like to write a structured document editor, but that idea has morphed into
something a bit more -- complex -- than I'm willing to do at the moment. :)

A bit about me [for the list in general, if they've read this far :) ]...

I graduated in May 99 from UC Berkeley, with a BS in Electrical Engineering
and Computer Science [EECS]; there, I was a member of the eXperimental
Computing Facility [xcf.berkeley.edu].  I now work for a Berkeley- [soon,
Oakland-] based start-up [biometrics at point-of-sale for financial
transactions] as a software engineer.  I've been using linux for about 5
years [after realizing OS/2, however awesome the object-oriented interface
and OS internals were, was dead].

...jsled