Budgeting proposal

[Dave Fancella]

On Thursday 17 April 2003 07:22 am, Matthew Vanecek wrote:
> I think you misunderstand me.  BudgetCategories bear the same name as
> its associated Account merely out of convenience.  The fact that you use
> the same name for a BudgetCategory as its associated Account is only to
> provide a little sanity.  You could easily have different names for
> BudgetCategories.  There would, of course, have to be a dialog in which
> to associate a BudgetCategory with an Account.  Also, a Budget does not
> track how the money is spent.  A Budget tracks how you *want* to spend
> the money, as you say above.  It is not an overlay, though.  It's a
> separate beast.  You can mirror the Accounts, or not, as you wish
> (although it is much easier to mirror the Accounts).

Mmmm........  Let's see if I've got this straight.  Now, mind you, I may not 
have any idea how accounts are *supposed* to be organized, I just know how 
mine are.  :)

Expense accounts exist so that you can see exactly what you spent money on, 
right?  And Income accounts exist so that you can see exactly where your 
money came from.  The purpose of budgeting is to make a plan for where you 
will spend your money.  Typically you start by budgeting your income, basing 
it on paychecks or whatever your income is.  Then you create a series of 
Expense budgets that should take care of all of your needs.  After creating 
this budget, you want to use it as a guide to keep you from spending too much 
money, and you want to use it to track where you do spend your money.

The more I think about it, the more I have to disagree with a budget being a 
separate entity entirely.  If your budget isn't linked to an account, or the 
account it gets linked to over time changes, then the usefulness of your 
reports is going to suffer because the meaning of the budget categories will 
change, and the meaning of the accounts will change.  If you change the 
meaning, the report won't be consistent about the information it's 
presenting, since the underlying assumption in all historical reporting is 
that the meanings don't change.  As an example, in my house the gas and water 
bills are together on the same bill, so I have an expense account for that.  
When I move, I might get gas separate from water, or even gas combined with 
electricity, which is how I've usually seen it.  It won't be accurate anymore 
for me to track gas and water expenses with the same account, because that 
account won't be worthwhile anymore.  (Ideally, thouhg, the bill would be 
split everytime to reflect how much gas is on it, and how much water is on 
it, and gas and water would be budgeted separately, but since I didn't do 
that up front, I'm not changing it now)

I don't mean to be so disagreeable, especially as the newcomer to the list, 
but I think it's important to hammer down whether or not a budget is a 
separate entity in the first place.  The implementation is going to depend on 
this.  :)

>
> For a business, I guess, the change tracking capability would be pretty
> useful.  I'm not sure how truly useful it is for the typical person,
> though.  Still, if it's there for the business, there's no reason the
> private sector couldn't use it.

It would be useful for me, since my wife still hasn't learned when not to 
double-click on stuff and tends to wonder around with her pointer going click 
click click.  There's no telling what kind of damage she might do to the 
budget if it was actually easy and useful to use, so being able to track 
changes means I could say "look woman, quit screwing around!".  :)

> The setup I'm thinking about *does* allow for multiple Budgets, which is
> the main reason I came up with that method.  Also, if you treat a Budget
> hierarchy as a separate entity from the Account hierarchy, it becomes
> significantly easier to track changes, etc.  Although, since you can
> have multiple Budgets, you could just create a new Budget. ;)
>
> > > As for your columns idea to show the budgeted amount and the current
> > > Account balance, I like that idea.  To implement it, you would just
> > > mark a given Budget as default (with appropriate date reasonability
> > > checks, of course), and you could see the difference.  This would
> > > require, though, that the Account balances be captured for the same
> > > period for which the Budget is effective.  I think, in the short term,
> > > that a dynamic report would be easier to write, though.
> >
> > I was actually thinking that you would just query the transactions for
> > the specific time period, kinda like this:  (note: I've no idea how
> > GNUCash handles queries right now, here's some broken SQL)
> >
> > SELECT * FROM Utilities:Internet WHERE DATE <in the budgeted range>
> > Summary=SUM(Amount);
> >
> > (my SQL isn't real good, I know)
> >
> > Basically, get all the transactions for the specific budget for the
> > specific time period, total them up, and show that.
>
> That'd be a change on the main user interface, which is why I think it
> would be relegated to a report.  I think the desire is there to maintain
> the current account balance in the interface.  You could make it a
> configurable option, though.  For the short term, however, I feel that
> this type of information will have to be in a report (I'm not speaking
> to the rightness or wrongness of one vs. the other--only to reality and
> necessity).  Unless you did the work, maybe....

I would really like the columns in there, for budget-at-a-glance, but I see no 
reason why it should be an option that's turned on by default.  :)

> I'd prefer two date fields: A from and a to.  We might could utilize the
> Lots framework to support projects (although right now they are/will be
> used for securities, they seem to loosely fit the need for tracking a
> project, too...different discussion).  Now that I think about it, Lots
> would probably be a better way to track project expenditures.  You could
> have EITHER a from/to date, OR a Lot.  That depends on being able to
> associate any given transaction/split with a Lot, though, as opposed to
> just securities transactions.

I'd prefer dates myself just because it would simplify a lot of the math.  If 
it becomes necessary to change it, though, it shouldn't be that hard.

I've been thinking about credit limits, actually, and it seems like a credit 
limit is similar, although not exactly, like projects.  You get a certain 
amount of money for the life of the card (barring credit increases, of 
course), but it's revolving.  Presumably in a project budget there's no way 
to deposit money back into the project, or at least it's not very common.  
With credit cards you will be depositing money into the account whenever you 
pay your bill.  I don't know if they should be linked, though, because 
although functionally similar, they are conceptually different beasts 
entirely.

> Some people already do something similar to this, by having sub-accounts
> of their bank accounts, and splitting money into the sub-accounts.  When
> they pay the Electric bill, the transfer money from Assets:Bank:Electric
> to Expenses:Utilities:Electric.  It's a pretty nifty way to work around
> the lack of budgeting capabilities.  Instead of anticipation, you have
> current balance.

Is this an "industry standard" way of doing it?  The real problem I'm seeing 
with that, though, is that you'd have to transfer money from your bank 
account to your Assets:Bank:Electric, and your bank register wouldn't show 
the real amount.  I was thinking more like being able to deposit money out of 
thin air into your expense accounts (perhaps from A/R?).  It seems like if 
there's a standard way of dealing with budgets then regardless of what we 
might actually think about budgeting, we should first implement the standard 
process.  Maybe I should go to the library or something....heh.

> Your trying to make the budget too much like the accounts.  They really
> are two totally separate things.  You don't transfer monies around in a
> Budget.  You simply adjust allowed amounts.  There is no double entry in
> a Budget.  I'm pretty strict, so I probably wouldn't adjust amounts, but
> others would want to increase, say, Budget:Expenses:Electric, and
> decrease, say, Budget:Expenses:Movies.  You can't really impose a
> requirement for a "balanced transaction", though, in a Budget.

I tend not to adjust amounts either, and my wife's always saying "We spent too 
much, do we need to change it?" and I say "No, look at the bottom line, we're 
still in our budget.  Give it a couple more months and let's see how it works 
out, we can change it then if we need to."  That might still be more often 
than some people, though.  :)  But being able to move money around between 
budget categories opens up a few possibilities for types of budgets.  For 
example:

My auto budget is fairly straightforward.  There's insurance ( $0 ), gas 
(split for 3 cars right now), and service ($50).  It's the last one that gets 
you, though.  If you every have to do any real work on a car, you'll be 
damned lucky if you can pay less than $50.  So the idea is that every month, 
the $50 is spent.  Every year or so when we actually have a major expense on 
fixing a car, the money would be there because it built up every month.  Of 
course, I suppost just transferring the remaining balance in the service 
budget to a separate service account for safekeeping would do the same 
thing...  Um, never mind?  (As you said, why didn't I think of it before?)

> > How do paper accountants handle budgeting for companies?  Is there a
> > standard procedure?
>
> The accountants don't, really.  My manager creates a budget based on
> planned projects.  It details salaries, raises, software licenses, group
> outings, etc., that are planned for the year.  Portions of the Budget
> are approved, others are disapproved.  The final Budget is what he uses
> to spend money.  The financial people can run reports and compare his
> Budget with his actual expenditures (and so can he).

So the accountant just says "how much did we spend?", gets the number and 
looks at some scrap of paper his manager gave him and does the math in his 
head?  :)  Ok, it's probably a bit more involved than that....  but I see 
what you're saying.

> The Budget really is its own little entity.  It's changeable, portable,
> and can bite you in the butt. On the other hand, it's nice to know how
> much money you plan on having, and how much you plan on spending.
> However, it's association with the Accounts is only incidental (albeit
> important).  What happens in the Accounts doesn't affect the Budget, and
> what happens in the Budget doesn't affect the Accounts.  It's the
> *comparison* of the two that will  make you cringe. =P
>
> Hopefully this all makes sense.  The point is, you don't need the
> Accounts to create a budget.  You could just as easily create a Budget
> in Gnumeric, and plug in numbers on occasion from Gnucash to get your
> progress in the Budget.  Hmm, wonder why I hadn't thought of that
> before...

I've sorta got an idea here...  does GNUCash have any plugin API or anything?  
I'm wondering, if it did, then I could make a budget plugin rather than 
budgeting as an integral part of the application.  That would leave room not 
just for other implementations, but it would also make something that would 
allow for a lot of other things, such as plugging into a CRM or something.

Anyway, to continue.  :)

If Budgets are a separate entity, then a way is needed to store the amount of 
the budget, the length of the budget, mmmm, and I think that's it.  (the tree 
structure is assumed to be part of the architecture no matter what :) ).  
Next we need a way to do math with the budget and accounts.  Traditionally, 
in financial apps anyway, this is done by linking every single transaction 
with a budgetted category, and in some applications (can we say Quicken? :) ) 
it gives the illusion of being double-entry.

Now, from a UI point of view, I think it would be confusing (and I *really* 
don't want to have to explain this to my wife) if you have to chose both an 
account (that might look like a category) and a budgeted category for every 
transaction.  Now, I do have a tendency to put the category in the Payee 
field, but some people really do care about having the Payee field reflect 
reality, where I don't, and I even have some blank ones.  So, ideally, a way 
should be found that makes the difference between a budget and an account 
seamless to the user.  As far as I'm concerned, I'll be happy just putting a 
budgeted amount on each expense/income account, and leaving the other 
accounts alone with budget.

Is there a specific situation(s) that would require the budget and accounts to 
be kept separate entities?  Would it be reasonable for the sake of a 
practical implementation and UI to marry the two?

I'm not opposed to any specific way of doing it, I'm only opposed to not doing 
it.  :)  And I'll be happy to contribute whatever code I can to doing it, but 
since I don't know jack about the GNUCash source tree, it would take some 
time for me to familiarize myself.  In fact, I intend to start the 
implementation as soon as there's agreement on it.

Dave

-- 
"I slipped inside the oval office,
I slipped in oh so fast,
Grabbed the president by the necktie
And wiped my funky ass, hey"
                -Soulhat, "Bonecrusher"