Budgeting - Let's decide what we want!
Stewart V. Wright
svwright+lists at amtp.liv.ac.uk
Thu Aug 28 17:22:21 CDT 2003
Hi All,
Me again!
Here is my contribution to the (hopeful) budgeting debate...
(It is a txt version of a LaTeX document that I wrote. Sorry about
the sometimes dodgy line breaks...)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Budgeting in GnuCash
Abstract
A discussion of a potential way of implementing
budgeting in GnuCash is presented. This document is
intended as an aid to stimulate discussion and clarify
the GnuCash userbase's wants.
1 Introduction
There are at least two types of budgeting that GnuCash
users would undoubtedly like to see: Personal and Business.
I cannot offer a clear insight for business budgeting
requirements, as each business is different and I've
been out of the game for a few years now.
However I know what I would like to see in a personal
budget and this is what I will be presenting. This is
in fact the sort of thing I did with my business, so it
might be usable for others too.
2 Budgeting in Practice
Budgeting is not as simple as transferring cash from a
bank account into a number of other accounts and then
making transactions from them. It is as simple as
having "virtual" accounts and then pretending that the
transactions occurred in one of these, whilst knowing
in actuality that the transactions are made in a few
real accounts. People might call the "virtual" accounts
something different, envelopes, cookie jars, or the
like but it doesn't change the concept. This is how I
budget, and I expect how most people do it. However let
me make it clear by giving an example.
2.1 An Example
John is a single guy, who has a net income of $24,000.
He sits down and fills in all his financial inflows and
outflows in GnuCash for three months to get an idea of
what he is spending his money on.
John decided to group the various of his expenses into
broader categories to make budgeting easier. His broad
categories are called Required, Living, Fun and
Savings. The Required category includes things like
Rent Payments, House and Medical Insurance. Living are
his everyday expenses on groceries, laundry costs and
the like. Fun is not surprisingly are the categories
that are required to keep him sane, but aren't strictly
necessary costs, like taking his girlfriend out for
dinner, going to the pub and that occasional copy of
Sports Illustrated.
After looking at his Cash Flow report for the last
three months, John decides that the correct
distribution of his income should be:
Required 50%
-------------------
Living 20%
-------------------
Fun 20%
-------------------
Savings 10%
This leaves a little extra about his predicted expenses
in the first three categories, but that is just
prudent... When John's next paycheck comes along he
transfers, on paper, the appropriate percentages into
these virtual categories/accounts.
Further transactions are entered in GnuCash in their
appropriate accounts. John also records the
transactions as income/expenses in the virtual
accounts. Thus he knows exactly how much he has to
spend on expensive gifts for his girlfriend at any one
time by looking at the balance of the Fun (virtual) account.
2.2 The Problem
The problem with this sort of budgeting is that
currently it is not possible to implement this virtual
division of income in a simple manner that also allows
the easy reconciling of bank statements that (in my
opinion) is a great aspect of GnuCash.
I do however have a suggested method of implementing
such a system which I believe will add to the strengths
of GnuCash without changing the behaviour for anyone
who doesn't wish to work in this manner. This is an
important requirement of any budgeting extension to
GnuCash. Those who don't want to budget in GC shouldn't
have to do anything differently to the way they do now.
3 Budgeting in GnuCash
This section suggests a slight extension to the account
structure of GnuCash to allow the budgeting approach of 2.1
without modifying the current behaviour for most users.
3.1 Virtual Accounts
Budgeting is often achieved by the use of an imaginary
division of income and expenses into user defined
categories. Keeping with the terminology of GnuCash
these imaginary categories will be known as Virtual
Accounts (VAs).
In summary VAs are a imaginary asset/liability/expense
source that are used to divide income and expenses as
defined by the user. The major difference from regular
Accounts is that a leaf VA will mirror all expenses to
the first (real) Account that sits above it. VAs will
not contribute to the calculation of assets,
liabilities or expenses of the Accounts under which
they are leaves.
In addition to entries in a VA leaf of an Account each
entry will be listed in a parent VA for each category.
Once again an example might be of assistance.
3.1.1 VA example
Using the example described in 2.1 a simplified account
tree might look something like
+----------------------------------------------------------------------------
| Assets
| \hookrightarrow | Current Assets
| \hookrightarrow | Bank Account
| \hookrightarrow | (V) Living
| \hookrightarrow | (V) Fun
| \hookrightarrow | Cash in Wallet
| \hookrightarrow | (V) Living
| \hookrightarrow | (V) Fun
| \hookrightarrow | (V) Living
| \hookrightarrow | (V) Fun
|
| Expenses
| \hookrightarrow | Entertainment
| \hookrightarrow | Music/Movies
| \hookrightarrow | (V) Fun
| \hookrightarrow | Rent
| \hookrightarrow | House
| \hookrightarrow | (V) Living
+--------------------------------------------------------------+-------------
where the virtual accounts are denoted by the '(V)'."
For example John buys a round of drinks at the pub
costing $10 and puts it in his Fun VA. If the round was
bought with cash from John's wallet the transactions
would look like the following. Firstly there would be
the entry in his Expenses:Entertainment:Pub account:
+-----------+-------------------+-----------------+----------+---------+---------+
| Date | Description | Transfer | Expense | Rebate | Balance |
+-----------+-------------------+-----------------+----------+---------+---------+
+-----------+-------------------+-----------------+----------+---------+---------+
| 18/08/03 | Round at the pub | A:CA:W:(V) Fun | 10.00 | | |
+-----------+-------------------+-----------------+----------+---------+---------+
where I have simplified the account structure as A:CA:W
representing Assets:Current Assets:Cash in Wallet. This
would obviously have a corresponding entry in the
Assets:Current Assets:Cash in Wallet:(V) Fun account
+-----------+-------------------+-----------+----------+-------------+---------+
| Date | Description | Transfer | Deposit | Withdrawal | Balance |
+-----------+-------------------+-----------+----------+-------------+---------+
+-----------+-------------------+-----------+----------+-------------+---------+
| 18/08/03 | Round at the pub | E:E:Pub | | 10.00 | |
+-----------+-------------------+-----------+----------+-------------+---------+
This is all entirely consistent with the current
structure of GnuCash. The difference is in the fact
that there are two other locations where this
transaction would appear. Firstly it would be listed in
Assets:Current Assets:Cash in Wallet, the branch
account of which Assets:Current Assets:Cash in
Wallet:(V) Fun is a leaf.
+-----------+-------------------+-----------+----------+-------------+---------+
| Date | Description | Transfer | Deposit | Withdrawal | Balance |
+-----------+-------------------+-----------+----------+-------------+---------+
+-----------+-------------------+-----------+----------+-------------+---------+
| 18/08/03 | Round at the pub | E:E:Pub | | 10.00 | |
+-----------+-------------------+-----------+----------+-------------+---------+
The central difference with this transaction is that it
would be a copy of the transaction in A:CA:W:(V) Fun
and all the transactions in the VA leaves would be
mirrored like this. The second location that the "Round
at the pub" transaction would appear is the trunk (V)
Fun account. All transactions in the VAs lying under
any of the Assets or Liabilities accounts linked with
Fun would appear in this account. Thus at a glance the
total value of the VA Fun would be clear, much as it is
with Assets, Liabilities, Income and Expenses currently.
Transfers of money into VAs would work in exactly the
same way, but as the transfer from the Assets account
is to a VA there would be no effective change in the
balance of the accounts. For example if John transfered
$500 into his Fun VA from his savings account the
transaction would look something like:
+-----------+--------------+---------------+----------+-------------+---------+
| Date | Description | Transfer | Deposit | Withdrawal | Balance |
+-----------+--------------+---------------+----------+-------------+---------+
+-----------+--------------+---------------+----------+-------------+---------+
| 12/08/03 | Salary | I:Salary | 1000.00 | | 1243.45 |
+-----------+--------------+---------------+----------+-------------+---------+
| 18/08/03 | Budgeting | | | | |
+-----------+--------------+---------------+----------+-------------+---------+
| | (V) Required | 500.00 | | |
+---------------+----------+-------------+---------+
| | (V) Living | 200.00 | | |
+---------------+----------+-------------+---------+
| | (V) Fun | 200.00 | | |
+---------------+----------+-------------+---------+
| | (V) Savings | 100.00 | | 1243.45 |
+--------------------------+---------------+----------+-------------+---------+
| 21/08/03 | Groceries | E:Groceries | | 24.00 | 1219.45 |
+-----------+--------------+---------------+----------+-------------+---------+
Thus no change in the balance of the savings account
would occur when a transaction was made to or from a VA.
3.2 Limitations
This approach is neither complete or without holes in
the logic. Two that spring to mind I will address
briefly here
3.2.1 Account totals in leaf VAs
The most obvious flaw that would come to light when
using an approach like the one described above in
GnuCash is a result of the Double Entry accounting. It
is probably best described (again) by an example. I go
to the bank and withdraw $100 to put in my wallet.
Currently this sort of transaction is simple in
GnuCash. However with VAs would I need to specify how
much of the $100 in my wallet is to be used for Fun
expenses, and how much for Living costs? If I didn't
transfer money into these VAs I would constantly be in
the red in the leaf accounts of my A:C:Wallet account.
I don't have a perfect solution to this. My current
thinking is that the VA leaves would always be in the
red as the transfer of cash into the VAs would be into
the trunk accounts --- all transactions, both expenses
and liabilities would appear there so it is the branch
accounts that would show your financial position, not
the leaf accounts. Undoubtedly this solution would make
some people feel uncomfortable, so perhaps a judicious
transfer at the end of the pay period to balance the
VAs is an alternative.
3.2.2 Automation, Druids and Future Expenses
An email from Phil Longstaff (see the gnucash-devel
mail archive) made me question whether this approach
answers all the budgeting requirements. Phil pointed
out that there are at least two parts to budgeting:
1. Tools to produce a budget - forecasting, GUI to set
up budget
2. Tools to monitor a budget - budget vs actual reports
I think the current proposal answers some of the
problems of the second point, but as to the first???
Both Phil and I have a need for a month-by-month
budget. As he points out there are other people who
have mentioned a need/desire for longer budgets
possibly for an 18 month project. Perhaps one of these
people can offer some insights for how to implement
such a budget.
4 Resources
The resources that might come in useful for this
discussion are
GnuCash The GNU way to manage your money! [http://www.gnucash.org/]
gnucash-users The GnuCash users mailing list: [https://lists.gnucash.org/mailman/listinfo/gnucash-user]
gnucash-devel The GnuCash users mailing list: [https://lists.gnucash.org/mailman/listinfo/gnucash-devel]
The Motley Fool Living Life Below Your Means: [http://www.fool.com/specials/2000/sp000412lbym.htm]
What Does It Take To Invest Like a Fool? [http://www.fool.com/school/13steps/13steps.htm]
--
European Citizens: Please do a little work to convince the European
Parliament to reject software patents. This page explains the issue
and provides suggestions for action; take the time to participate.
http://swpat.ffii.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 274 bytes
Desc: Digital signature
Url : /pipermail/attachments/20030828/81cfdfa3/attachment.bin
More information about the gnucash-user
mailing list