I've been thinking about budgeting issues for a while, since I have never
found a financial application with the budgeting implemented in a clean
way. To me, a budget amounts to specifying the "velocity of money". By
that, I mean that you are specifying the flow per unit time which is going
into various expense accounts. For instance, as you work at your job, you
are paid so much per hour (or for the salaried among us, per year). This
is then *your money*, except that your company hasn't gotten around to
paying you yet. So in my mind the budget account Salary has a money
"velocity" associated with it. You tell the program that you're going to
receive 36,000 / year and at the end of January, and the program
automatically deposits ~$100 / day into that account. That way it makes
sense when the program transfers money from the Salary account into the
budget account. The money didn't come from nowhere, but came as a result
of the "integration" (for you math geeks) of the velocity of the money
over the correct period of time.
It works the same way with expenses. As you use electricity, you owe the
electric company money at the rate you use the electricity. So your
Utilities:Electricity account gets debited at a certain rate. When you
get a bill, you (hopefully) bring that balance back to zero by depositing
money into it.
Bringing it back to the discussion about the honeymoon account, you know
that you want $5000 on December 15. So you plug in that planned expense
into your account, and specify how you would like to save for it (evenly
from now until then, or maybe ramping up in the last couple of months
because there are other expenses which will end by then). The program
computes the budgeting function, and at each day, your balance becomes
more and more negative, until you put money into it (or maybe the program
could do this automatically). The object is to keep your expense/income
accounts at $0.
This then brings us back to the question about reconciling the accounts.
If you were to transfer money inside GnuCash, then it would become
difficult to reconcile your accounts, as has been pointed out in previous
emails. The subaccount solution is in some sense suboptimal because you
might have multiple accounts (investment and savings) and use multiple of
them to save for the honeymoon. Because this is the case, what is
necessitated is an idea of budgeting transactions versus actual
transactions. When you get a paycheck, all of it gets deposited into your
checking account, but then you can make a "budgeting transfer" to the
honeymoon account, postdated to the date of your honeymoon. If you later
break off your engagement and decide to spend your money on a car, you can
make a budgeting transfer from the honeymoon account to the car account.
This feature makes budgeting priority changes easier to deal with. If you
had an unexpected car breakdown, you could decide to put off that
vacation by transferring money out of that account and into the car repair
account.
You could view your accounts "with budgeting transactions"
or "without budgeting transactions". Of course this would necessitate
painful changes to the engine, but could result in a very clean budgeting
framework for future financial planning functions.
Of course budgeting could be done in a report framework, but as was
pointed out, the psychological matter of seeing negative balances helps
many to do better planning.
-Patrick Baker
On Thu, 30 Mar 2000, Scott Haug wrote:
> On Thu, Mar 30, 2000 at 12:28:15PM -0600, Rob Browning wrote:
> > Scott Haug <[EMAIL PROTECTED]> writes:
> >
> > > I'm not sure why you would treat it as a liability, but to be honest
> > > I have no accounting background so maybe that is the best way. I
> > > just treat my savings goals as bank accounts. They're merely
> > > logical accounts used to meet a certain monetary goal, and since the
> > > money in a savings goal doesn't actually leave the physical account
> > > it was transferred from, I still consider it an asset and "Cash On
> > > Hand."
> >
> > But if you really are transferring the money in gnucash from a bank
> > account to a savings account, how can you reconcile with your bank
> > statement each month? Those transfers will never show up in the bank
> > statement, and so the balance will always be wrong, or am I missing
> > something?
>
> Having a "wrong" balance is kind of the point. Its not a real account, its a
> virtual or logical account set up so you can "set aside" money for a large
> purchase or debt, such as a vacation or school tuition. The balance reflected
> in a goal account should indicate to yourself, "that money shouldn't be used
> for anything else", and having the goal account's balance factored into the
> bank account's balance helps to achieve that. I don't know about anyone else,
> but I have a pavlovian reaction when I see a negative balance in my personal
> financial app, even if I know I have a positive balance in my actual physical
> account.
>
> My original solution was to set up a separate goal account that stood apart
> from the bank accounts, and make transfers from the bank account to the goal
> account. If I remember correctly, this is more-or-less how quicken sets them
> up. The problem is, as both you and Lauren pointed out, is that these
> transfers aren't reflected in your monthly statement, making reconciliation
> somewhat difficult and confusing. Using quicken, I usually factored that in
> and would reconcile those transactions anyway, but I only had one goal account
> at a time, so it wasn't too difficult. Multiple goal accounts, however, might
> make this more than unreasonable.
>
> Lauren's solution is much more elegant, and it better takes advantage of the
> superior structure already in place in gnucash. She suggests setting up a goal
> account as a sub-account off a regular bank account, and debiting from the goal
> account to a liability account (which makes sense to me, thanks Lauren!) to
> represent setting aside money for the goal. The beautiful part is you don't
> have to worry about these transactions showing up in your checking account,
> since you're never actually touching the bank account. Therefore, monthly
> reconciliations would work just like normal, without having to factor in any
> goal account transactions. It gets better: the goal account's (typically)
> negative balance would be factored into the bank account's balance on the main
> window (since it's a sub-account), giving you the desired effect of a
> (perceived) smaller balance without any fuss. The only minor downside of this
> method is that for it to be most effective, these goal accounts must be tied to
> a single bank account, whereas a separate, standalone goal account could
> receive transfers from any bank account. But I believe its worth it for not
> having to mess with it come reconcilation time.
>
> > If I'm right, then to do "savings goals", we'd probably need another
> > abstraction. Maybe you'd have a "real balance", used for
> > reconciliation, that ignores savings goal transfers, and then the
> > "normal balance" that gnucash shows you by default that includes the
> > savings goal transfers. This would probably require a new account
> > type and some ugly, and possibly incorrect, monkeying around in the
> > engine. Not sure off the top of my head...
>
> I don't think this is necessary. As mentioned, making a goal account a sub
> account of a bank account (so many accounts!) is almost a perfect solution, and
> doesn't require any code changes to gnucash, since its framework has been so
> well designed! A new account type wouldn't hurt to help delineate a goal
> account from a bank account, but it would have the exact same semantics as a
> bank account and would be a different account type in name only.
>
> Anyway, I don't think these goal accounts would be used enough by most people
> to deserve drastic, confusing changes to the stable structure already present.
> What we have is sufficient. What /would/ be useful would be a druid that could
> step people through setting one up, creating the requisite sub-bank
> account/liability account combo. But it would basically just automate
> something that isn't all that difficult to do manually.
>
> > --
> > Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
>
> -Scott
>
> --
>
> --
> Gnucash Developer's List
> To unsubscribe send empty email to: [EMAIL PROTECTED]
>
>
>
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
