On Thu, 30 Mar 2000 16:12:12 EST, the world broke into rejoicing as
Patrick Baker <[EMAIL PROTECTED]> said:
> 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.
I'm a "math geek" who has studied the unusual (or not!) area of *discrete
calculus.* None other than Donald Knuth has written a notable work on
this; the joint authored book with several other TeX_related luminaries
entitled "Concrete Mathematics."
There is *some* merit in treating the idea of budgeting as if it involved
some notion of "velocity," with "continuous" equations. It is quite
convenient to look at macroeconomic activity in this way.
It is, however, *not* accurate to look at personal budgeting in such a
continuous manner, because our activities do *NOT* involve continuous
transfers of cash. Personally, I get paid exactly twice a month.
99.999% of the time, the "velocity" of money is $0. Two seconds per
month, the velocity is positive, at some thousands of dollars per second.
At other times, the velocity is negative, at tens or hundreds of dollars
per second.
Thanks, but no thanks. I would MUCH rather look at my finances in a
discrete manner.
Admittedly, we could head to even "higher" calculus, with integrals
involving Dirac functions and the likes; it may be integrable and all,
but I rather think it makes a lot *MORE* sense to stay with discrete
math, where the point is to have a decent scheduler to indicate when
cash flows are expected.
> 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.
I'd *surely* be game to take an approach like this to my tax bill; it is
*quite* fair to treat it thus:
--> Twice a month, I earn income on which I have some estimate as to how
much tax I owe. And I pay something to the government to prepay
this.
There are two ways to look at this:
a) I'm just plain paying taxes each time.
So:
DR CR
Bank 2000
Income 3000
Income Tax Expense 1000
b) I'm accruing a tax bill each time, and paying into an asset account, of
prepaid taxes.
Thus:
DR CR
Bank 2000
Income 3000
Prepaid Income Taxes 1000
Along with:
Income Tax Expense 900
Income Taxes Payable 900
[It's $900 because I'm consistently overpaying; what I expect I *truly*
owe is only $900/period...]
At the end of the year, this would build up so that the balance might
look like:
Assets:
Prepaid Income Taxes $24,000
Liabilities:
Income Taxes Payable $21,600
Expenses:
Income Tax Expense $21,600
And then, when the *actual* bill turns out to be $22,000 (since I was
overoptimistic), the transaction to clean things up is thus:
Tax Refund:
Cash $2,000
IT Payable: $21,600
Prepaid Taxes: $24,000
Income Tax Expense: $400
which clears out the payable/prepaid accounts, reflects the money that
the IRS (or CCRA, or whomever...) sent me, and fixes up the tax expense.
> 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.
The term for this sort of thing is "Fund Accounting," and tends to be
associated with not-for-profit organizations.
It usually arises when an organization receives funds where some specific
sort of tracking is mandated. For instance, a church may hold a building
program, where contributions are required to be spent on (surprise) building
a building. Or a symphony orchestra may receive a government grant where
the money is required to be spent on a particular tour.
> 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.
This is, indeed, one option. Unfortunately, pushing the functionality into
the engine pushes a whole lot of complexity into both engine and register.
And adds complexity to the user interface. Whole lotta complexity goin' on.
Another option would be thus...
Create, for each "project" that you're saving for, *two* accounts.
Suppose we're looking at "Honeymoon." The plan is to save $300/month
over the next 12 months to pay for this "Project," and the savings should
sit in the Savings Account.
Create two accounts:
a) An asset account ("BANK") entitled "Savings - Entailed", with a long
description of "Savings being entailed for Honeymoon."
b) An expense account entitled "Honeymoon Savings."
Then create 12 transactions, one for each month, whereby an expense
of $300 is applied to Honeymoon Savings, with the other side of the
transaction going to the "Savings - Entailed" account.
This has the result that the overall "Bank" balance, when both "Bank"
accounts get added together, shows off the intent to save up for the
project.
On the other hand, it does *nothing* to diminish the ability to
reconcile the true bank account.
> 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.
Doubtless so...
--
"Besides a mathematical inclination, an exceptionally good mastery of
one's native tongue is the most vital asset of a competent
programmer." -- Edsger W.Dijkstra
[EMAIL PROTECTED] - <http://www.ntlug.org/~cbbrowne/lsf.html>
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
