Budgeting - Let's decide what we want!

[Andrew L. Gould]

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 my 2 cents.

Best regards,

Andrew Gould