Budgeting - Let's decide what we want!

[Matthew Vanecek]

On Fri, 2003-08-29 at 15:59, Andrew L. Gould wrote:
> On Friday 29 August 2003 03:04 pm, Matthew Vanecek wrote:
> > On Fri, 2003-08-29 at 14:13, Jesse Guardiani wrote:
> > > Matthew Vanecek wrote:
> > > > The 'Virtual Accounts' is the proper way to implement budgetting.  A
> > > > budget is a separate entity.  It's relationship to your accounts is
> > > > very loose and malleable.  You can associate a Budget account with an
> > > > actual account of a completely different name.  The budget is editable
> > > > separate from the accounts it is supposed to be guiding.
> > >
> > > OK. Fair enough. Would my idea help people stay within their budget
> > > accounts then? I use a variation of what I described in managing my
> > > accounts against a flat file budget. It works pretty well. But what I
> > > described earlier would make what I do even easier.
> >
> > I think some people already do some of what you mention.  I don't think
> > they move money around at reconciliation time, but I could be wrong.
> >
> > Only self-discipline can help a person remain within a Budget. =P
> > However, automated reports comparing Budget to Actual seems to me more
> > effective.  Take your flat-file budget, or spread sheet budget.  How do
> > you compare that to your actual cash flow?  Well, you open the file, and
> > you open Gnucash, and you look at the two, or perhaps get a limited
> > transaction report from Gnucash.  The basic process of *doing that*
> > needs to be implemented--we don't need to design a new process.
> >
> > I'm afraid that your proposal would add way too much complexity to the
> > system for too little benefit.  It would also not be very scalable.  If
> > you maintain the Budget and the Accounts as two separate unrelated
> > entities, you create many possibilities with respect to planning, data
> > extraction and exporting, and reporting, that simply don't exist if you
> > tie the Budget to the Accounts too tightly.  The only relationship that
> > exists between the Budget and the Accounts is the same as when you
> > compare your flat-file to your Gnucash accounts:  You mentally decide
> > that row A in flat-file is the row for Expenses:Movies.  Only in the
> > program, the same relationship would be a user-definable attribute of
> > the Budget category.  You could just as easily decide on row B instead,
> > and you also have the freedom of changing the dollar amount in your
> > flat-file...or creating multiple flat-files.
> >
> > Now, please realize, there are many opportunities for exploiting the
> > relationship (or lack thereof), that would make the whole thing useful.
> > Over/Under reports, forecasting, etc.  But they all result from the
> > relationship, not the data.  Having the Budget and Accounts w/o tools to
> > exploit the relationship relegates us back to the "look at the file,
> > look at the Gnucash account" mechanism, or to the sub-accounts
> > work-around.
> >
> > Am I making sense, or just typing too much?
>  
> Caveat:  I haven't installed Gnucash yet; so I don't know how my comments 
> fit/conflict with the development model.
> 
> You're both making sense; but I think the subject can be simplified a little.  
> A budget, at any level, serves the following purposes/functions:
> 
> 1. Planning tool for the next accounting period.
> 2. Sets financial goals.
> 3. Acts as a financial expression of organizational priorities.
> 4. Facilitates variance analysis.
> 
> It's true that entities will create their budgets at various levels of detail; 
> but the only way to accomplish all 4 functions above is to create 
> relationships between budget line items and 'live' accounts at the chosen 
> level of detail.
> 
> If you create a budget as a second set of books, you can start the budgeting 
> process with the projected balances for the current year.  You can then add 
> transactions for expected changes in the following year.  The accounts can 
> then be summarized at whatever level the user wishes to monitor.  Since the 
> Map of Accounts for the Budget and Actual Books are identical, matching the 
> two for comparison shouldn't be too difficult.
> 

That's pretty much right on the money (hehe :-) ), except conceptually
you don't want to think of it as a second set of books.  Although,
programatically, it could be implemented much the same as the account
hierarch (w/o the registers, of course).  Also, the budget categories
don't necessarily have to map to accounts.  The mappings should be
user-definable and not required, to allow for greatest flexibility in
planning.  The knowledgeable user will realize this, hopefully, when
running reports that include unmapped relationships...


-- 
Matthew Vanecek
perl -e 'print $i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);'
********************************************************************************
For 93 million miles, there is nothing between the sun and my shadow except me.
I'm always getting in the way of something...