--NzB8fVQJ5HfG6fxh
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Following are my collected thoughts about introducing budgeting into
GnuCash. This is one of my biggest itches at the moment, and I feel
like scratching.
I apologize for the double-inclusion. I want to satisfy my use of
tables/lists in providing structure in the document, as well as obey
standard mailing-list [sub-]sectional-quoted-reply practices.
Thus, I've inlined the `lynx -dump` formatted version for replying,
and attached the original HTML I wrote [which looks much nicer, and I
encourage you to read first [in Mozilla, natch :) ]]. The two tables
used are deliniated below by '<table>'...'</table>'.
Cheers...
...jsled
-----
Budgeting in GnuCash
jsled, 2000.11.09T0112, 2000.11.20T2337
Preface
This document describes an approach to take at the problem of
introducing functional budgeting into GnuCash. It presently borrows
few ideas from GnuCash, and can be considered a general take at the
problem of budgeting. It is not a design document, by any stretch of
the reading; that will come later. It is more a set of notes relating
to budgeting, and the basics of a framework for how budgeting might
work.
In this vision, budgeting is a primary, optional function of GnuCash.
It is an important tool for the user who wants to have a good grasp on
their financial state; it is not a type of report. Budgeting is not
strictly for people with income barely meeting their expenses [though
the tool should be useful to them], nor strictly for the user with
"extra" income looking for a way to reach their numerous savings
goals. It should be flexible and functional enough to serve both
users.
Budgeting
"budget" [Merriam-Webster]
Main Entry: 1bud-get
Pronunciation: 'b&-j&t
Function: noun
Etymology: Middle English bowgette, from Middle
French bougette, diminutive of bouge leather bag, from Latin bulga, of
Celtic origin; akin to Middle Irish bolg bag; akin to Old English belg
bag -- more at BELLY
Date: 15th century
1 chiefly dialect : a usually leather pouch, wallet, or pack;
also : its contents
2 : STOCK, SUPPLY
3 : a quantity (as of energy or water) involved in, available
for, or assignable to a particular situation; also : an account of
gains and losses of such a quantity
4 a : a statement of the financial position of an administration
for a definite period of time based on estimates of expenditures
during the period and proposals for financing them
b : a plan for the coordination of resources and expenditures
c : the amount of money that is available for, required for,
or assigned to a particular purpose - bud-get-ary /'b&-j&-"ter-E/
adjective
A budget is a tool by which a user can compare expected expenses to
the history of actual expenses, for the purposes of better allocating
income. Once realistic budgetary limits are obtained, the user can
then project forward to plan for future expenditures. The goal with
any future-based financial tool is to manipulate the difference of
income to expenses, in order to further utilize available financial
resources.
Functional Areas
The basic idea of a budget is as follows:
1. Define recurring expenses.
2. Sum.
3. Subtract from income.
4. Adjust so difference is >= 0.
... but we can do much better.
Basic
The basic concepts in a budget are income, recurring expenses and
time. Income can be fixed [as in salary or loans] or variable [such as
in primary/suplemental income via a "as-desired" employment situtation
or gifts/winnings]. Recurring expenses [now: "expenses"] can be typed
into one of the following categories:
Expense category types
<table>
expense type examples notes
fixed rent, loan repayment, cable, internet, insurance
variable phone $[30,90], food $[400,600], gas $[25-35, every two
weeks]
seasonal utilities, gifts These will definitely be 'variable' in the
first cut, and maybe will stay as that; but we can do so much better!
:)
sporadic car repair, emergencies, clothing, computer
</table>
Time is hard to nail down. For some categories, the expense is occured
on a fixed date [rent is due on the first of the month; I pay it the
first weekday after the first]. For other expenses or situations, the
expense may acrue during a time-span. For instance, in my three-person
apartment, I make a phone payment during the middle of the month
[around the 20th], then collect payments from my apartment-mates
during some amount of time after this. However, the budgeting system
should not impose dealing with this situation on users with a simpler
situation.
As with most things financial, the budget is a zero-sum game. If you
over-spend in one area, you must find some place to take this from.
Likely candidates are [priority]:
1. Unallocated income/savings [some catch-all category to enable
0-balance].
2. Other budget areas which are under-run.
3. Savings goals [perhaps prioritized themselves; saving for a new
Y-pipe is << important than grad school].
4. Lines of credit/advances == options...
A budget may have a start date, but not necessarily an end date, or
some fixed amount of time for which it applies. For instance, most
budgets will start at some arbritary time when the user decided to sit
down and make the budget, but may actually be based on the history for
6 months past. Or, it may be a budget which won't start until some
future, anticipated date [after planned, upcoming life changes]. Most
budgets will continue indefinitely, but may be modifed along the way;
they will not be used after major financial/life changes occur, and we
probably don't have to deal with that event.
The budget tool must allow the user to explicitly modify expected
expenses based on new info. For example: when I change my wireless
plan from "$40/mo + 200 min/mo + (overtime * $0.30/min) = ~$200/mo" to
"700 min/mo + $90/mo + (overtime * $0.30/min) = $90/mo", the budget
should be able to take this into account from the time of the change
forward. The user will probably have to be queried as to what to do
during the time-span affected by the switchover. I think this
can/should [eventually] use the same mechanism as "What If?" engine
described below.
The default period of operation for the budget tools is one month.
However, we have knowledge of the dates [some/most] expenses occur on,
and can thus look at a day-by-day breakdown as well. Something I'd
like to see is the cash-flow chart associated with a given month,
showing how much should be in my checking account on every day as
income comes in, and expenses are paid out. Extrapolating, I'd like to
see a less-dense cash-flow chart for each of my savings goals over the
months/years [hiding the complexity of day-to-day expenses below some
threshold]...
Advanced
At the advanced level of a budget, the future goals are of primary
importance, but we must look to the past [both near and far] to a)
determine budget constraints and b) further ensure those contraints
are realistic.
A key component of the advanced budgeting system will be planning and
tracking savings for future goals/uses. These goals generally have a
time-horizon, and contributions to these savings goals are not
compulsory, but instead dependent on external pressures of the user.
The savings for these goals in not generally in nicely deliniated
boxes [let's say physical], but often aggregated into one or mulitple
places [the money-market account holding both emergency funds and some
un-allocated portion of long-term/retirement savings waiting to be
moved into a mutual fund, for instance].
Another component of the advanced budget is a new budgetary category
for seasonal/external expenses. These are expenses which are dependant
on time or some external index. This generally applies to fuel, more
specifically to utilities bills, and automobile gas. In an ideal world
these would have externally-accessible indices for tracking, somewhat
like stocks. The projected December gas & electric bill would look for
the current price of natural gas, and multiply by the
historical/expected consumption amount to determine the most-correct
budgetary amount.
Workbench
The Workbench is concerned with "what-if" questions... what if I want
to take a trip to Tahiti... how much longer will it take to save for
the new car?
The main component of the workbench is a set of Changes which can be
in one of two states: inactive or active. Active Changes modify the
budget, and allow the user to play with different ideas. Inactive
Changes sit around, waiting to be applied [natch].
Examples of Changes include:
* analog vs. digital cable
* eating out more/less?
* loan repayment schedule changes [more/less vs. inflation, savings
goals]
* vacations
* investments... [partially] selling for saving goals vs. continued
holding, &c. [but how to handle?]
* conditional bonuses
A simple mockup of this interface is something like...
inactive changes active changes
+--------------------+ +--------------------+
| work more overtime | | increase grad contr|
| trip to tahiti | ---add--> | quit smoking |
| | <-remove- | take lunch to work |
| | | contribute to unice|
+--------------------+ +--------------------+
This allows the GnuCash user to experiment with different
budgeting/lifestyle tactics, showing the net effect of changes on
their goals [and perhaps history, for reinforcement].
General Notes
The budgeting subsystem not be so integrated that is cannot be used in
pieces. For instance, the change workbench should not require that all
expenses be categorized and allocated into budgetary roles. However,
functionality may be limited unless this is done.
User experience, flow
1. "Create Budget" [menu, button]
1. Budget parameters [name, time range [start date, optional end
date]].
2. Link to [subset of] holding accounts.
3. Link to expense accounts root
4. Link to income accounts [perhaps root].
Define as:
o Fixed/salary
o Variable [per hours put in, stuff done]
2. Define recurring expenses, place temporally:
1. Link to expense category [or categories]
2. "learn" [register history]/have user state budget category
extremeties
3. associate with date [range, sub-dates]
4. Explode, re-define "hard" expenses [food, smoking,
entertainment]
3. Apply budget to time frame [repeatedly, at any point in time]
1. Do the math
2. Do overflow math [w/ user input] - over in one area can be
made up for by under/extra in other area.
3. Recommend changes
4. report: update "financial picture"
Development Phases
Phase 0
* requirements - I'd like to talk/interview people I know to have
them explain how a budget should/would work... a user-centric
requirements gathering; hopefully others can do the same.
* UI/screen mockups
* functional spec/design doc [how to implement into existing GnuCash
codebase]
Phase I
* Take into account basic budgetary concepts:
+ recurring, fixed expenses [rent, cable, loan repayments]
+ recurring, variable expenses [utilities bills, phone, daily
expenditures, food, friday-nights]
+ categorized expenses/budgetary categories
o limits
+ savings goals [very limited]
* assign limits to categories on a monthly basis
+ extrapolate into daily expenses
* time-series-based UI
* comparison to history
Phase II
* Savings goals, allocated-asset tracking.
* Better understand grouped expenses [jsled's day-to-day expense
category]
* Something to handle sporadic events [auto repairs, &c].
* Seasonal/external expenses? [Maybe Phase III]
* First version of Workbench/What-If? scenarios/Changes.
* [1]pre-defined categorizations
* Druids:
+ savings goal calculators
+ loan-repayment calculator
+ Mortgage, &c.
* Cash-flow chart [something for the new main window?]
Phase III
* Flesh out Workbench.
* GIGO: allow for better projections by understanding expenses.
+ think of utility bill as: <kWhrs * cost/kWhr> + <therms *
cost/term> + <taxes>, track monthly terms used [perhaps
national/regional average], and multiple by current costs...
+ gas: track auto's gas mileage, and current regional gas rates
+ taxes: while not xforming into a tax-mgmt app, understand at
least the tax bracket, and have an implicit tax-savings-goal
for Apr 15th.
+ food: [2]my food breakdown is a good first cut; refine with
experience.
+ some nightly catch-up input thingy -- for people who want
that much detail on their budget, having something to do with
daily receipts is a Good Thing (TM).
* Remember that savings is only as good as inflation-ROR...
* Flesh out advanced abilities, respond to user input.
My food breakdown
This is an excerpt from my Gnumeric budget worksheet showing how I
calculated a somewhat-realistic amount for monthly food expenses:
<table>
Food Days Cost/day Total Cost
Out/lunches 22 7 154
Out/Dinners [nice] 2 25 50
Out/dinners [normal] 21 6 126
In/Dinners [nice] 2 25 50
In/Dinners [normal] 5 3 15
In/Lunches 8 5 40
Total 60 435
</table>
Standing Questions
Should integrate into register?
* Future expected transactions listed? Non-editable?
* Maybe editable...
+ Should have some may to deal with exceptional|unexpected
conditions.
+ Example:
o High phone bill [special call, installation charges]
My perspective
Were it just me, this is the time frame I'm thinking of...
Phase 0 over the course of the next month+, delivering a design doc in
early-mid January; I have some of the UI mockups whiteboarded here,
and will Glade [read as a verb] them up in the next couple of weeks.
Phase I following after the holidays, probably lasting a month or two
or three... Phases II and III are outside of my scope of
anywhere-near-realistic estimation at the moment, and anyways will be
modified over time to be more correct.
I know there's some very interested developers out there, and some
more will hopefully step up in the next few weeks... so we'll figure
it out.
References
1. http://www.geocities.com/Heartland/Meadows/2419/page2.html
2. file://localhost/home/jsled/stuff/programming/projects/gnucash-budget/gnucash/src/doc/budget2.html#my_food
--NzB8fVQJ5HfG6fxh
Content-Type: text/html; charset=us-ascii
Content-Disposition: attachment; filename="budget2.html"
Budgeting in GnuCash
Budgeting in GnuCash
jsled, 2000.11.09T0112, 2000.11.20T2337
Preface
This document describes an approach to take at the problem of
introducing functional budgeting into GnuCash. It presently borrows
few ideas from GnuCash, and can be considered a general take at the
problem of budgeting. It is not a design document, by any stretch of
the reading; that will come later. It is more a set of notes relating
to budgeting, and the basics of a framework for how budgeting might
work.
In this vision, budgeting is a primary, optional function of
GnuCash. It is an important tool for the user who wants to have a good
grasp on their financial state; it is not a type of report. Budgeting
is not strictly for people with income barely meeting their expenses
[though the tool should be useful to them], nor strictly for the user
with "extra" income looking for a way to reach their
numerous savings goals. It should be flexible and functional enough
to serve both users.
Budgeting
- "budget" [Merriam-Webster]
-
Main Entry: 1bud-get
Pronunciation: 'b&-j&t
Function: noun
Etymology: Middle English bowgette, from Middle
French bougette, diminutive of bouge leather bag, from Latin bulga, of
Celtic origin; akin to Middle Irish bolg bag; akin to Old English belg
bag -- more at BELLY
Date: 15th century
1 chiefly dialect : a usually leather pouch, wallet, or pack;
also : its contents
2 : STOCK, SUPPLY
3 : a quantity (as of energy or water) involved in, available
for, or assignable to a particular situation; also : an account of
gains and losses of such a quantity
4 a : a statement of the financial position of an administration
for a definite period of time based on estimates of expenditures
during the period and proposals for financing them
b : a plan for the coordination of resources and expenditures
c : the amount of money that is available for, required for,
or assigned to a particular purpose - bud-get-ary /'b&-j&-"ter-E/
adjective
A budget is a tool by which a user can compare expected expenses to
the history of actual expenses, for the purposes of better allocating
income. Once realistic budgetary limits are obtained, the user can
then project forward to plan for future expenditures. The goal with
any future-based financial tool is to manipulate the difference of
income to expenses, in order to further utilize available financial
resources.
Functional Areas
The basic idea of a budget is as follows:
- Define recurring expenses.
- Sum.
- Subtract from income.
- Adjust so difference is ≥ 0.
... but we can do much better.
Basic
The basic concepts in a budget are income, recurring expenses and
time. Income can be fixed [as in salary or loans] or variable [such
as in primary/suplemental income via a "as-desired" employment
situtation or gifts/winnings]. Recurring expenses [now: "expenses"]
can be typed into one of the following categories:
Expense category types
| expense type | examples | notes |
|---|---|---|
| fixed | rent, loan repayment, cable, internet, insurance | |
| variable | phone $[30,90], food $[400,600], gas $[25-35, every two weeks] | |
| seasonal | utilities, gifts | These will definitely be 'variable' in the first cut, and maybe will stay as that; but we can do so much better! :) |
| sporadic | car repair, emergencies, clothing, computer |
Time is hard to nail down. For some categories, the expense is occured on a fixed date [rent is due on the first of the month; I pay it the first weekday after the first]. For other expenses or situations, the expense may acrue during a time-span. For instance, in my three-person apartment, I make a phone payment during the middle of the month [around the 20th], then collect payments from my apartment-mates during some amount of time after this. However, the budgeting system should not impose dealing with this situation on users with a simpler situation.
As with most things financial, the budget is a zero-sum game. If you over-spend in one area, you must find some place to take this from. Likely candidates are [priority]:
A budget may have a start date, but not necessarily an end date, or some fixed amount of time for which it applies. For instance, most budgets will start at some arbritary time when the user decided to sit down and make the budget, but may actually be based on the history for 6 months past. Or, it may be a budget which won't start until some future, anticipated date [after planned, upcoming life changes]. Most budgets will continue indefinitely, but may be modifed along the way; they will not be used after major financial/life changes occur, and we probably don't have to deal with that event.
The budget tool must allow the user to explicitly modify expected expenses based on new info. For example: when I change my wireless plan from "$40/mo + 200 min/mo + (overtime * $0.30/min) = ~$200/mo" to "700 min/mo + $90/mo + (overtime * $0.30/min) = $90/mo", the budget should be able to take this into account from the time of the change forward. The user will probably have to be queried as to what to do during the time-span affected by the switchover. I think this can/should [eventually] use the same mechanism as "What If?" engine described below.
The default period of operation for the budget tools is one month. However, we have knowledge of the dates [some/most] expenses occur on, and can thus look at a day-by-day breakdown as well. Something I'd like to see is the cash-flow chart associated with a given month, showing how much should be in my checking account on every day as income comes in, and expenses are paid out. Extrapolating, I'd like to see a less-dense cash-flow chart for each of my savings goals over the months/years [hiding the complexity of day-to-day expenses below some threshold]...
At the advanced level of a budget, the future goals are of primary importance, but we must look to the past [both near and far] to a) determine budget constraints and b) further ensure those contraints are realistic.
A key component of the advanced budgeting system will be planning and tracking savings for future goals/uses. These goals generally have a time-horizon, and contributions to these savings goals are not compulsory, but instead dependent on external pressures of the user.
The savings for these goals in not generally in nicely deliniated boxes [let's say physical], but often aggregated into one or mulitple places [the money-market account holding both emergency funds and some un-allocated portion of long-term/retirement savings waiting to be moved into a mutual fund, for instance].
Another component of the advanced budget is a new budgetary category for seasonal/external expenses. These are expenses which are dependant on time or some external index. This generally applies to fuel, more specifically to utilities bills, and automobile gas. In an ideal world these would have externally-accessible indices for tracking, somewhat like stocks. The projected December gas & electric bill would look for the current price of natural gas, and multiply by the historical/expected consumption amount to determine the most-correct budgetary amount.
The Workbench is concerned with "what-if" questions... what if I want to take a trip to Tahiti... how much longer will it take to save for the new car?
The main component of the workbench is a set of Changes which can be in one of two states: inactive or active. Active Changes modify the budget, and allow the user to play with different ideas. Inactive Changes sit around, waiting to be applied [natch].
Examples of Changes include:
A simple mockup of this interface is something like...
inactive changes active changes
+--------------------+ +--------------------+
| work more overtime | | increase grad contr|
| trip to tahiti | ---add--> | quit smoking |
| | <-remove- | take lunch to work |
| | | contribute to unice|
+--------------------+ +--------------------+
This allows the GnuCash user to experiment with different
budgeting/lifestyle tactics, showing the net effect of changes on
their goals [and perhaps history, for reinforcement].
The budgeting subsystem not be so integrated that is cannot be used in pieces. For instance, the change workbench should not require that all expenses be categorized and allocated into budgetary roles. However, functionality may be limited unless this is done.
This is an excerpt from my Gnumeric budget worksheet showing how I calculated a somewhat-realistic amount for monthly food expenses:
| Food | Days | Cost/day | Total Cost |
|---|---|---|---|
| Out/lunches | 22 | 7 | 154 |
| Out/Dinners [nice] | 2 | 25 | 50 |
| Out/dinners [normal] | 21 | 6 | 126 |
| In/Dinners [nice] | 2 | 25 | 50 |
| In/Dinners [normal] | 5 | 3 | 15 |
| In/Lunches | 8 | 5 | 40 |
| Total | 60 | 435 |
Were it just me, this is the time frame I'm thinking of...
Phase 0 over the course of the next month+, delivering a design doc in early-mid January; I have some of the UI mockups whiteboarded here, and will Glade [read as a verb] them up in the next couple of weeks. Phase I following after the holidays, probably lasting a month or two or three... Phases II and III are outside of my scope of anywhere-near-realistic estimation at the moment, and anyways will be modified over time to be more correct.
I know there's some very interested developers out there, and some more will hopefully step up in the next few weeks... so we'll figure it out.
--NzB8fVQJ5HfG6fxh--