Budgeting Summary 1 - first draft
Stewart V. Wright
svwright+lists at amtp.liv.ac.uk
Mon Sep 8 12:00:14 CDT 2003
G'day All,
The first draft of the summary of this list is now available.
Once again it is sitting at
http://www.liv.ac.uk/~svwright/papers/gnucash/Budgeting_Summary_1.ps
or for other formats (including text and TeX)
http://www.liv.ac.uk/~svwright/papers/gnucash/
I've included it below too...
This is my quick and nasty interpretation of the budgeting thread so
far. It is not a short summary as there have been a number of good
points. However I'm sure to have missed something that someone
believes is vitally important, or down played the significance.
Please, please, please send the list (or me) your suggested changes.
Tear it to shreds, mock my spelling (it is a mix of PROPER English and
American English), ridicule the grammar, but make it the "road map for
budgeting" that we want.
The only request I have is that the changes are limited to _this_
summary, and _this_ last weeks discussion. We can have another
summary next week, but let's try to keep a fixed boundary on the
summary, otherwise it becomes a moving target.
And now, without further ado: Summary the First (draft 1):
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Budgeting in GnuCash
Summary: 1
Abstract
This document is a summary of the discussions of
implementing budgeting in GnuCash[http://www.gnucash.org/] from the
gnucash-users and gnucash-devel mailing lists over 21
August 2003 --- 6 September 2003.
1 Introduction
This is a collected summary of some of the thoughts
expressed in the "lively debate" in the gnucash-users
mailing list
thread[http://article.gmane.org/gmane.comp.gnome.apps.gnucash.user/8148].
I have used the contributions of the various contributors (listed in
[sec:Contributors]) verbatim at times in this document as they have
been posted to the public discussion list. However I will remove,
and/or rewrite, any contribution that I receive a request from the
author. There are times throughout the document where there are
mentions of 'I', these are usually the results of me (SVW) not
rewriting the contributions as thoroughly as they might have
been. However, the thoughts expressed by the contributors stand as
written.
2 Summary
2.0.1 First, Do No Harm.
The addition of budgeting features into GnuCash must
not make the accounting features slower or more
difficult to use.
2.0.2 Complex Things Should Be Possible.
You must be able to model several different scenarios
by creating different budgets for the same period.
2.0.3 My dream Is A Truck.
You must be able to add Budget items that don't have
representation in the accounts hierarchy.
2.0.4 Simple Things Should Be Easy.
You must be able to generate a Budget hierarchy from
the existing accounts hierarchy.
2.0.5 Two Chickens In One Pot.
A budget category must be able to refer to more than
one account. A corollary of this requirement is that
not every account must be tied to a budget category.
2.0.6 Heads Up!
There must be a series of progressively more sever
warnings as budgets limits are approached.
2.0.7 Accounts != Budgets
Once set, a budget should not be "broken" (i.e.
rendered useless) by changes to the account hierarchy
(i.e renaming, re-parenting, deleting.)
2.0.8 The Fundamental Things Apply...As Time Goes By.
Budgets need to obey the rules of double entry
accounting and the fundamental accounting equations.
3 Goals
3.1 Introduction
A number of users have expressed what I will describe
as Goals: attributes that budgeting in GnuCash should satisfy.
3.1.1 Savings goals
How would you fit "savings goals" into a model? A
savings goal isn't an expense (it could be considered
an income, but generally it's a portion of
Income:Salary). Also, what about using budgeting as a
tool to figure out what would happen if you added a
particular expense. For example, "can I afford this new
car if I have to pay $250/mo, and what would that do to
my cash flow and savings goals?" The problem (as I see
it) is that if you tie budgeting specifically to
income/expense accounts then you cannot perform either
of these two functions.
3.1.2 Projects
There is another budgeting feature which I have only
played with and have not really used. This is for
projects or jobs. You can create job templates with
breakdowns into various items. When you start a job of
a certain type you use the template to create a budget
for that job. This seems most appropriate when a
business has a small number of different jobs that are
done repeatedly for the customers.
3.1.3 Extending the Report Structure
You need 2D because of substantial overlap in accounts
between the classes. Each of those classes has a
cumulative budget amount. I can spend my $150/mo on
whatever I want. Sometimes it's computer stuff, more
often, I take Julie out to dinner. If I spend less, I
get to spend more next month.
In short, you need reports that select or sort by
class/action, and reports that ignore class/action.
Some of our customers have three dimensions. For
instance, a property management customer has
accounts,departments,projects. Each department is a
responsibility area of the company. Each project is a
group of properties, e.g. a row house tract. You can
print a profit/loss for each project - to see which
projects are albatrosses, and where they are leaking
cash (can it be fixed? or should it be sold to cut
losses?) You can print a profit/loss for each
department, to see which departments are lean and mean,
and which need some fat trimmed (and where). You can of
course also print an overall profit/loss for the entire company.
4 Overview
4.1 Introduction
Implementing budgeting needs two main parts
1. Tools to produce a budget - forecasting, GUI to set
up budget
2. Tools to monitor a budget - budget vs actual reports
Some users have a need for a month-by-month budget.
Other people have mentioned longer budgets for e.g. an
18 month project. We need to have multiple budgets
simultaneously.
4.1.1 Purpose
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 organisational 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.
4.1.2 Minimal Definition
In a minimal description, a budget is a set of amount &
time-frame pairs associated with a split group. At
present the only split groups that GnuCash supports are
accounts. Do "what we want" to be able to define
budgets for the accounts that we have now? If GnuCash
is ever extended to support Categories (another kind of
split group) the same facilities can be used to set and
report budgets for those.
4.1.3 A tool
The simple approach would be a big step forward, and
many users would probably never ever need more. For
many, a budget has been first and foremost a tool to
track how well (or how poorly) I am following a
financial plan.
Simulations of financial scenarios seem to be quite
another thing - nice, but not essential.
4.1.4 Flexibility is good
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 summarised 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.
Although, in the code, it could be implemented much the
same as the account hierarchy (w/o the registers, of
course). Also, the budget categories don't necessarily
have to map to accounts. The mappings should be
user-definable and not required, to allow for greatest
flexibility in planning. The knowledgeable user will
realise this, hopefully, when running reports that
include unmapped relationships...
4.1.5 Flexibility is bad
To a degree financial software is different. It isn't a
window manager. Letting people get "creative" with
accounting isn't necessarily a good thing. For example
maybe I'm odd and like to change every other entry into
a negative number even though I enter a positive
number. Not exactly the best function for an accounting
system. Just because you can do something, doesn't mean
you should.
You take may budgeting very seriously, and want it very
structured. That is great, and we want a budgeting
feature that CAN work your way to attract your type of user.
4.1.6 Flexibility is ???
We also want it to BE ABLE to be used in a less
structured way because not all home users think the
same way. They WANT to do some changes half way through
the year (and then maybe undo them - or not save the
changes - or have multiple budget files for the same
year) to see if they can afford a vacation. They are
not held to their budget as strictly as a government
is. If they are disciplined they may stick to it, but
if they aren't they won't. Maybe having a "lock my
budget" toggle would be a good little feature?
I think by "structured" we are talking about two
aspects without really being clear about the
distinction: (1) do we allow or not allow an accounting
category to be tied to accounts from more than one
branch of the account tree, (2) do we allow or not
allow changes to the budget in the middle of the
budgeting period.
4.1.7 Versions are good!
You build your budget and save that version. In our
case we call it "adopted", because the board of
supervisors actually adopts it as a plan. You could
call it "Original" or something. This is the budget
that NEVER changes after you create it. Then you have
your "REVISED" budget. This is the budget that during
the year you tweak as things happen.. like pay raises,
unforeseen necessities, raised utility rates etc....
Then you have a "PROJECTED" version. This is basically
your ACTUALS for months that have "closed" and your
"REVISED" budget for months that are "open".
This type of versioning now allows you to see how you
did against your original plan (Adopted/Original), see
how you plan to spend based on some moving factors
(Revised) and see how you are spending and how that
makes things look with your budget as you have it laid
out (Projected).
4.1.8 Account != Budget Category
Budgets categories and Accounts really have very little
in common. You don't use a Budget to reconcile
transactions; you use it to verify if you are spending
too much or too little on a particular expense or
asset, or to see if you income exceeds expectations or
if you have less cash coming in than planned. You can
also use the budget to map out various paths for you
future finances: Do you want to spend more or less
money on food? What happens if I start putting X
dollars in savings, or stocks? A budget is a tool to
help you plan where you want to go.
Accounts are tools to track where you've been. You
don't want or need budget editing built into accounts
--- that would be a grave mistake and highly
unscalable. Not to mention it mixes two completely
different sets of data.
In short, budgets are planning and compliance tools.
Accounts are tracking tools. You don't need accounts to
create a budget; conversely, you don't need a budget to
use accounts. When you have both available, and can
compare your actual to your planned (reports), you can
really take control of your finances. However, they
*are* separate.
Now, for display purposes in the register, I'm sure
there are ways to make it all nice and pretty so that
you can see at a glance your performance against your
budget. That, however, is GUI related, and separate
from the data implementation. The GUI should never,
ever drive how you store your data.
4.1.9 Additional views
Some that I can think of would be
1. forecasts - where will I be in time X. Based on the
starting balance for that category and using the
budgeted targets where will I be in 6 months (for example).
2. planned vs actual - how much do I have left to
spend, or how much did I blow it by last month?
4.1.10 Looking at the future
I see a need for profiling possible scenarios, and how
a future purchase will affect my budgetary needs. For
example, when considering a new house purchase, I need
to know 1) what is a reasonable goal for saving a down
payment, 2) How will my budget need to change to reach
that goal (because, well, my income sure ain't going
up!), and 3) how will the projected future house
payments (and cessation of saving for DP) affect my
financial expectations? These are all valid reasons for
how potential purchases affect your budget, and why you
need a way to profile the different scenarios.
4.1.11 Budgeting assets?
There are circumstances in which budgeting asset
accounts makes sense. For example suppose you hold a
note for $50,000. You expect to receive payments of
principal of $15,000 this year. This is not income but
is an asset conversion. It won't show up in a pure
income expense budget yet you have $15,000 that can be
used for expenses or for capital expenditures, etc.
4.2 Desires
4.2.1 I like it quick and dirty...
I would like to see actual, budget, and variance on the
Accounts view. I would like to see it all at-a-glance,
immediately. Is that realistic?
4.2.2 I like it to vary...
Choosing how to populate the budget by % of income per
period would be a nice feature, but most cash flows
won't be based on percentages.
4.2.3 I like to watch...
I (SVW) want to be able to see all the transactions for
a particular budget category. It's been suggested that
some sort of customised account register with
transactions for a period for all the accounts in that
category may be satisfactory. A right click menu option
could bring up this register for the selected category.
Come to think of it this might go hand in hand with the
suggestion for a planned/actual view of the budgeting
information. If you see that you were over budget in a
certain category for a period you could bring up this
window to see the transactions which contributed to
that situation. Question is, is this something that
should be done by the workbench or in a report
somewhere? Maybe both?
Viewing the transactions that contributed to the actual
amount for a given budget period really isn't
complicated (conceptually). Gnucash already provides a
Search for Transactions capability that can be tapped into.
For a given budget period and category, select "view
transactions for budget category in period X", where
period X represents fromDate to toDate. The Budget
engine formats a query just like the "Search For
Transactions" dialog: "Select transactions where
date-entered between fromDate and toDate and accounts
in (list of linked accounts with sub-accounts)", and
displays them in the typical register. All that is
built in already. All the budget needs to do is hook
into the engine/GUI with the appropriate query.
5 A Plan
5.1 Initial data
This hasn't fully thought this through yet. One might
give the user a choice between:
1. Populate budget from account data.
2. Populate budget from scheduled transactions,
3. Use both 1 & 2 (not sure how this would work in some
cases but worth a think)
There is the feeling that designing a nice robust way
to initially populate a budget will be a project in and
of itself.
5.2 What is needed:
1. Generate a Budget hierarchy from the existing
accounts, or create it dynamically from scratch. This
decouples the Budget from the accounts, and allows
you to add Budget items that don't have account
representation. It also allows you to model several
different scenarios by creating different Budgets.
2. Populate the Budget amounts either dynamically, or
as some sort of average of the related account(s)
over time.
3. To track how your actual cash flow compares to the
Budget, you run reports that draw from a
user-specified Budget and the accounts you want to track.
A lot of people try to look at the money they receive
and spend as the budget that is tracked in the
accounts. That is simply not true. Tracking the money
you receive and spend is accounting. You move money
from income to expenses or assets (usually via a bank
account). A Budget, on the other hand, represents how
you are planning on moving your money around. It can
take as its foundation a history of actual money
movement, but other than some loosely-coupled relations
between Budget categories and Accounts, there is no
relationship between Budget and Account (in
programmatic implementation, not practice). You use
reports to track overages and underages. That's
budgeting in a nut shell. The above concept scale
remarkable well from home users to large businesses. I
don't see any need to have different implementations
for the two user sets. Basically, both need a "how do I
plan to spend the money", "how have I spent the money",
and a "how do the two compare" functionality. Warnings
for over-spending or whatever is simply fluff and
frills built on top of the basic implementation.
5.3 Doing it!
To set up a budget the user would have to enter a value
for each category, a frequency, and the related
accounts, as shown in the table below.
+----------------------+---------------------+---------------+-----------+
| Budget Category | Account | Budget Value | Frequency |
+----------------------+---------------------+---------------+-----------+
+----------------------+---------------------+---------------+-----------+
| Rent | Expenses:Rent | $500 | monthly |
+----------------------+---------------------+---------------+-----------+
| Food | Expenses:Groceries | $50 | weekly |
+----------------------+---------------------+---------------+-----------+
| Holiday in the Sun! | Assets:SGoal:Hol | $2400 | yearly |
+----------------------+---------------------+---------------+-----------+
The budgeting engine would then take these values and
divide them up evenly over the Budget Time-frame, using
the Period as the common time value. For example if the
Budget Period is one month we would get a table like
this. (note: I am using a 4 week month for simplicity)
+------------------+-------+-------+-------+-------+--+
| Budget Category | Jan | Feb | Mar | Apr | |
+------------------+-------+-------+-------+-------+--+
+------------------+-------+-------+-------+-------+--+
| Rent | $500 | $500 | $500 | $500 | |
+------------------+-------+-------+-------+-------+--+
| Food | $200 | $200 | $200 | $200 | |
+------------------+-------+-------+-------+-------+--+
| Holiday | $200 | $200 | $200 | $200 | |
+------------------+-------+-------+-------+-------+--+
Now the user can modify this table to suit their
specific needs. For example October and December might
need higher food budgets in order to accommodate
Thanksgiving and Christmas. (all those hungry relatives...)
As well it might not be appropriate to spread the
holiday out over the entire year. If we are going on
Holiday in April we might want to ramp up the payments
till then and then not have any in that category.
Now you might look at this and say "Hey there aren't
going to be any Holiday expenses till March when I book
my everything included all expenses paid trip to the
tropics. Why spread it out over the year." If
the user only wants to budget the entire amount in
March/April then they are free to but this lets people
like me who know that come March if I haven't saved up
some money, I will have to go into debt (not fun) to
pay for the vacation and be always catching up later.
By associating the Holiday category with both a Savings goalNote: I use the Savings Goal concept as described by
Lauren Matheson here:
[http://www.gnucash.org/gnucash-devel/March-2000/msg00529.php3]
and an Expense account I can on a monthly basis
transfer money from my chequing account into the
savings goal, knowing that when I pay for the trip I
will use the money saved so far.
I think that by defining separate budget categories and
then relating them back to GnuCash accounts we can
accomplish everything that people want. And yet the
infrastructure will sufficiently separate as to allow a
greater flexibility.
As well then every account type will be able to be
budgeted (not just income/expense). I find it very
likely that I will want to be able to set up a category
for my credit cards. This would allow me to make sure
that my credit card balance decreases by a set amount
each month and track that in the budget. Conversely I
will want to know that my Savings Account is increasing
by a certain amount every month.
6 What are the implications for Business Budgeting?
A serious consideration is the differences in
requirements in budgeting for businesses. This needs to
be clarified. Possibly it will be possible to include
in the same framework as that for personal budgeting.
This may be directly, as an extension included when the
demands are clarified, or there may be a need for a
different structure. However some points that have been
raised are:
* A small business should also use a separate budget
process that is more strategic in nature. A budget is
something you would put in a Business Plan.
* A budget is not only for a business plan, but also
for ongoing operations. From corporate to SOHO, you
have to know what you need to spend money on, and how
much income you are projected to have.
* There are multiple levels of budgetary control.
Accomplishing all levels of that control (Cash
Management and Strategic Budgeting for example) in
one process is going to be difficult. It's going to
be difficult to get a consensus of what it should
look like; and it's going to be difficult to develop.
Separating them may be the best way of meeting
everybody's needs.
* If the goal is home user: a more toward loose models
of accounting is acceptable. Ease of use is important
there. Small business: Still keep an ease of use
focus, but try to instill good accounting principles.
Anything beyond small business try to follow best
accounting practices of FASB, GAAP and GFOA.
7 An idea of what it might look like...
[http://www.darin.pwp.blueyonder.co.uk/]
Comments from Darin Willits: Budgets and account trees
should be separate entities. One *is* an essentially
imaginary, pie in the sky concept while the other is
concrete (often depressing...) reality. They are
definitely linked (categories have related accounts)
but are not one and the same.
However my hope is to create a set of data which could
be used in other parts of the application hopefully
enabling a wealth of financial planning features down
the road. But for now we have to start somewhere.
I am still trying to figure out exactly what
information to show in the workbench. It might be that
we need multiple "views" of the same information. An
actual/plan view, a basic budget amount view, and some
others yet to be defined.
8 Problems
8.0.1 Nomenclature...
I would hesitate before calling budgeting entities
accounts, but maybe category is the wrong word as well.
An account is a well known concept from the rest of
GnuCash, and using it in the budgeting engine as well
would probably only serve to confuse the user.
Especially since an "item" (better term maybe?) in the
budget can be linked to one or more accounts. Using the
term "account" both places could get...interesting. :)
8.0.2 Multiple year comparisons
Another problem is multiple year comparatives. What
happens when you decide to "inactivate" an account.
There needs to be a way to do "restatements". That is
allow you to change your chart of accounts from year to
year and then "map" an old year to a new year (for
reporting only). That is if you mapped as you want your
budget, but did not have a mechanism to do actuals the
same way. Your historical budget to actual reports
would be fairly whacked. What I would propose is you
fix your chart of accounts. (i.e. inactivate the old
accounts, make the new accounts) Then charge in the new
year to proper accounts and build budget properly. Then
in the reporting side have a way to do restatements
that say x goes to y.
8.0.3 Mortgages?
What about paying a mortgage? I don't really consider
paying that down to be a transfer of assets (even
though technically it is) -- I just look at it as an
"expense" where I'm reducing the outstanding balance on
the Liability. Obviously my house equity increases at
the mortgage liability decreases, but for my budget I
don't really care about that. I also don't particular
care how I pay for the liability, either, although I do
sort of see your point about where the money is coming
from; transferring from one liability to another seems
not to really do much good (although it might be
important for budgetary reasons?).
9 Glossary
Budget (Simple) A budget is a separate entity from
financial records used for comparison purposes and
tracking at different intervals through a particular
time period.
Budget (Complex) Budgets are strategic planning tools
that are usually documented at the monthly detail
level. Budget variance analyses usually occur monthly
or quarterly. The object is to determine if changes
in operations or business strategy are warranted.
Many entities only analyze the P&L side of the house.
Entities that must comply with loan covenants must
maintain certain levels of liquidity (Acid Ratio or
Days Cash On Hand, for example). These concerns
should be budgeted and analyzed, as they will can
impact the timing of strategic projects or purchases.
This is where budgets and cash management overlap.
Budget Category A discrete budget item. e.g. Food,
Rent, etc. Each category would be related to one or
more GnuCash accounts against which it would be
compared for reporting.
Budget Period The lowest common frequency denominator
for all expenses listed in the budget. Usually this
is one month but it could be a week, a year, or ten
years if appropriate.
Budget Time-frame The duration this budget is active.
Usually this would be one year for a home user, but
could be anything.
Cash Flow Management Management must project cash
inflows and outflows to be sure that adequate cash is
available as needed. This should include analyses of
expenses, short-term payables (including current
portions of long-term debt), cash accounts, payroll,
inventory turnover and receivables. In tough times,
these analyses cannot wait for month-end reports; but
should be available from weekly, or even daily balances.
10 Contributors
<sec:Contributors>The following people have contributed to the budgeting
discussion:
Andrew L. Gould, Chirik, Chris Roland, Christian
Stimming, Dale Alspach, Darin Willits, David Ayers,
Derek Atkins, Derek Neighbors, Doug Foskey, Glen
Ditchfield, Jack McKinney, Jesse Guardiani, Jon Lapham,
Justin Kelly, Kaaren Shalom & Richard Gilligan,
Marthter, Matthew Vanecek, Phil, Phillip Shelton, Phil
Longstaff, Reinke Bonte, Rick Ziegler, Robert Uhl,
Scott Minster, Stephen Cuppett, Stewart V. Wright,
Tripp Lilley.
(This list was created by looking at the 'From:' lines
for postings to the gnucash-users and gnucash-devel list.)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 274 bytes
Desc: Digital signature
Url : http://lists.gnucash.org/pipermail/gnucash-user/attachments/20030908/c106e127/attachment.pgp
More information about the gnucash-user
mailing list