Budgeting in Gnucash

[Ben Stanley]

OK, my mind is ticking over on this now, so I'd better get these
thoughts recorded somehow...

I've explored the GNUCash architecture and data structures. It seems
that the transactions, splits, and account data structures have slots
for storing key-value pairs. We could use these to store the budgeting
information in.

The first kind of information we need to store is about our projected
income/expenditure, in whatever units of time it occurs, as previously
discussed. I would propose that this information would be attached to
the account that it would occur in. For example, my wife and I receive
separate wages, so we have separate Income categories to record them.
The forward income may be projected by storing a BUDGETINFO key tag
which records the pay amount and frequency 'fortnightly' in the account
where it will be paid. Similarly for expense accounts, with variations
for things like food that occur more frequently in separate
transactions, but are allocated on a weekly or fortnightly basis.

Next we have to deal with tracking where the money is between the
time/account we earn it and the time/account it is spent from. This is
harder. The principle of budgeting says that we make contributions each
time we are paid into various savings accounts to cover each kind of
expense. The contribution is usually calcuated during a planning phase,
and should be made as soon as possible after the income is received to
avoid mis-spending it...

My wife and I have set up a special bank account which receives the
income, and which is supposed to hold the funds to cover each expense
account. When I initially moved to GNUCash, I envisaged setting up
sub-accounts of this bank account (logical accounts) for each expense
category. Contributions into each logical account were to be made by the
automated regular transaction device, but this device has not
eventuated.

Another problem was that of reconciling the bank account against a
statement. The `view sub-accounts' option must be used, because it will
show the expenditure occurring from the logical accounts, and the income
going into the parent (bank) account. However, it also shows all the
contributions into each logical account, which has no net effect upon
the bank account.... This problem could be solved by inventing another
`view' which does not show transactions between the parent account and
the sub-accounts. Note that the total at the bottom of this view must
reflect the total in the acutal bank account for reconcilliation
purposes. The reconciliation dialog must also operate with this
arrangement for this to prove useful.

With my increased understanding of GNUCash over time, I can now see that
I could make the logical account contributions easier to manage by
having a single huge split transaction which gets duplicated manually
every pay period. The duplicate facility was not available when I last
tried to solve this problem.

Un-allocated funds would then reside within the bank account, while all
allocated funds reside within the logical sub-accounts. Note, however,
that you must be very careful when withdrawing money from the account...
it is very easy to take out too much!

So, we have this account which is supposed to hold the allocated funds.
However, there are two other accounts which are involved in a typical
transaction: the VISA account and cash. To obtain an effective picture
of the bugdeting situation, these accounts must be combined with the
bank account. Funds used to buy groceries are typically moved physically
from the bank account (from the groceries logical expense account in
accounting terms) into the cash account, to be spent at the grocers.
This may happen several days in advance. Logically, the cash still
belongs to the groceries logical expense account, so this is where the
traditional approach breaks down. The funds must still be tracked
between the bank and the shop. Or, in the case of a VISA transaction,
the debt must be chalked up against a certain account. Note that having
a credit card makes it so much easier to outstrip your budget...

Another problem with this approach is savings. We try to maintain 3
accounts as part of our budgeting - the bank account, cash and VISA.
However, there are also term deposit savings accounts and managed
investment trusts, which we make regular contributions to. From the
point of view of our budget, they are an expense, at which point the
funds leave the accounts covered by the budget. However, logically,
these things are still part of our budget; of course there is a house
savings goal which is not stated in our current budgeting system.
However, we only cover 3 accounts to simplify tracking the money.

So, to my mind there is this big hole: tracking where the money is at
any time. As James stated in his budgeting thoughts, the funds to cover
a particular expense may be located in several places. Do we need to
actually allocate the money in each account? We probably do. If some
transactions are performed as cash, and this is recorded in the
budgeting system, then it becomes possible to answer the question: How
much money do I need to get out of the bank to cover this fortnight's
expenses? When this question is asked, the movement of funds for each
expense category can be automated. However, if there is no automation,
this approach could easily become very burdensome.

I fear that there may have to be several different approaches to the
budgeting system, depending upon the needs and expectations of the user.
Some may wish to allocate notional amounts, and just track them. Others
may wish to use the budgeting system to aggresively control and limit
their spending (eg those trying to save for a house, or to pay it
off...). I suspect that there will be a wide range of incompatible usage
patterns out there.

So, I think that the budgeting system will have to somehow keep track of
current allocations towards each expense, for each account. To do this
by manually creating sub-accounts for each expense category in each
physical account is a maintenance nightmare - this is the nightmare that
the budgeting system must automate and make easy. Using this method, the
unallocated funds becomes the total in that account minus the sum of all
allocated expenses (from that account). A similar calculation can be
carried out over all accounts, to allow you to figure out whether you
are in trouble...

So, the funds currently allocated to various expenses in each account
could be stored by further use of key-value pairs. Is it possible to
store more than one key-value object with the same key? I suppose it
doesn't matter - the value format can be designed to hold multiple
logical values.

When a transaction is made from one account to another, the allocated
funds tag which the transaction is for is moved as well.

This scheme may mean that I have to simplify my budgeting structure, but
that's OK, as I probably have too many expense types anyway.

This is way too long and rambling; it will have to be considerably
distilled before it turns into something useful. I just hope that it can
help with the refinement of James' problem statement, and help turn it
into a design.

Ben.


--
Ben Stanley               |    barf  [ba:rf]  2.  "He suggested using FORTRAN,
PhD Student               |       and everybody barfed." - From the Shogakukan
SITACS                    |       DICTIONARY OF NEW ENGLISH (Second Edition)
University of Wollongong  |
Australia                 |    http://www.uow.edu.au/~bds02