How should I enter values on a budget in gnucash ?

[Edward Doolittle]

On 1 March 2017 at 06:10, David T. via gnucash-user <
gnucash-user at gnucash.org> wrote:

> On Mar 1, 2017, at 3:30 PM, Geert Janssens <geert.gnucash at kobaltwit.be>
> wrote:
>


> > My question is simply this:
> > I want to budget a repayment of a credit card (from my bank account).
>


> > How should I enter this in a budget:
> > Bank: 100.00-
> > Credit card: 100.00-
>


> > Or
> > Bank: 100.00-
> > Credit card: 100.00(+)
>


> > I would expect the latter as I think transactions need to balance.
> However the
> > other person expects the former.
>


> > I've read the gnucash documentation which is unfortunately not showing
> any
> > example or detail in this regard.
>


> I’ll begin by saying I may misunderstand the original problem, but when I
> look at the Budget Balance report, I frankly think that it is screwed up in
> more significant ways than how it represents liabilities.
>


> As to the original problem, I think there is a disconnect between how the
> budget features operate, and how the rest of the application operates,
> which the bug hints at.


I think the root of the problem is that there is a disconnect between the
concept of budgeting and the concept of double entry accounting.

In double entry accounting we think in terms of transactions, or transfers
between two accounts, e.g., Income:Taxable:Salary and
Assets:Current:Chequing. If there are n different accounts, there are
approximately n^2 (actually n(n-1)) different "two leg" kinds of transfers,
and actually many more possibilities when we think about split
transactions. We can project sets of such transactions into the future;
let's call a set of such projections an n^2 budget system.

In budgeting, at least the budgeting with which I'm familiar, we think in
terms of "money coming in" and "money going out". If there are n accounts,
we only have 2n different kinds of budget actions (say, out of
Income:Taxable:Salary, or into Assets:Current:Chequing). Let's call this a
2n budget system.

It should be clear that the two conceptions are fundamentally different.
Adding budgeting features to gnc has shoehorned the latter framework into
the former, which is the source of some confusion.

In the past, I have tried to budget in the latter fashion, thinking mainly
about the activity in my chequing account, which is where most of the
day-to-day action happens for me. However, last year I started an
experiment in which I try to project all n^2 types of transfers using a
fairly comprehensive set of scheduled transfers which I create 366 days in
advance. I like it much better than 2n budgeting (e.g., I can get a fairly
accurate balance sheet projection by running a balance sheet at some day in
the future, and I get early warning of cash flow issues). However, it is
not for everyone: it is complicated to set up, and sometimes my estimated
future transactions creep through the present and into the past if I don't
stay on top of things (though marking such transactions as "(Estimate)"
helps me to find them and fix them; it would be nice to have a report which
stores a search for past transactions containing "(Estimate)" in the
description). I wrote a longish message about my experiences with this
system some time ago.

This year I wanted to combine more traditional 2n budgeting with my n^2
system of projections because sometimes I have a need to share my budget
with others (spouse, financial planners), who are expecting to see a
traditional 2n budget. I tried the gnc budgeting features, with the hope of
combining them with my n^2 budget system. I ran into a few problems:

1) The budget report slowed down my entire Windows 10 computer. Something
is wrong with the graphical part of the budget display on Windows. I
haven't noticed the same problem on Mac or Linux. Others have reported
similar experiences in the mailing list. I hope to find the time to
investigate the problem more thoroughly.

2) There seems to be a bug in the budget report which causes it to barf on
one of my credit cards. I haven't found the time to nail down the problem
in any more detail, but again I hope to. I might also try Phil Longstaff's
budget report, which may work around problem 1) as well.

3) It is not immediately clear how to reconcile the n^2 and 2n conceptions
of budgeting.

I have been trying to sort out problem 3), which is related to the
following:

So, it is not clear whether one should enter a negative value (reduce the
> liability by entering a negative number in the budget) or a positive one.
>


> So, it seems to me that it is perhaps very understandable that a user
> would receive confusing results. It is not clear to me what the resolution
> is, except to say that the current situation is highly confusing.
>


> Be all that as it may, the report itself is fundamentally troubling for
> me. For starters, which accounts is it including, and for what purpose?
> When I run this report, I get a listing of every account in my
> file—regardless of whether accounts are hidden, empty, zero balance, or
> part of the budget. It would seem to me that the Budget Balance Sheet would
> only include accounts that the user has designated in the underlying
> budget. This is not helped by the fact that the options to exclude zero
> balance/zero value accounts doesn’t seem to work.
>


> Next, it is very difficult to determine that this report apparently is
> tallying up the numbers from the budget entries. At least, based on the
> liability account that I was using to examine this bug’s behavior, that’s
> what it seems to do. I don’t know for sure, however, because none of the
> other numbers seem to match from the budget the the report. Confusing the
> matter is the fact that values turn up for accounts without budget
> numbers—in my case, the report includes commodity holdings info, even
> though they are not part of the budget. So, it is anyone’s guess what the
> report actually includes.


Let me propose the following "story" to make sense of the connection
between the n^2 and 2n viewpoints. We imagine a single new virtual account,
and we take any (two leg) transaction and put the virtual account in the
middle of the transaction. (Multi-split transactions can be conceptually
broken down into a series of two-split transactions.) The net effect on
this virtual account is 0 for any transaction, so technically we don't have
to keep track of the balance in this virtual account. However, we can
consider the net effect on any subset of the n real accounts (as we would
if we were making a transaction report).

In this view, income has a positive effect on the virtual account and
expense has a negative effect on the virtual account; furthermore deposit
to an asset has a negative effect, withdrawal from an asset has a positive
effect, paying down a loan has a negative effect, and taking a loan has a
positive effect. (The language of debits and credits also makes sense here,
if we view the virtual account as an asset account.) I propose that the
signs in the budget and budget report follow those conventions.

Typically personal budgets are said to include only income and expense.
(But a great source of confusion is thinking of loan payments as expense in
the traditional budget point of view, when they're really mostly a
transfer.) If we do that, we will (hopefully) accumulate a positive amount
in the virtual account, "retained earnings", which will in actuality end up
either in an asset account or paying down a liability or both. Those with a
need or desire to keep more detailed track of assets and liabilities should
be able to, but ignoring them should also result in a usable budget.

(Personally, I find it helpful to include in my budget asset and liability
accounts which are involved in one-way transfers; e.g., my savings,
investments, and loan accounts are one-way on the scale of a year: there is
a nontrivial net change in the value of the account over a year; on the
other hand, my chequing account and revolving credit accounts are not one
way, so I don't include them in the budget.)

The budget estimator tool can be coupled with the n^2 projection system to
turn it into a 2n budget; with that, I can make a conventional budget from
my n^2 projection system with very little effort. Very nice.

Another set of issues needs to be considered: what to do with hierarchies
of accounts. E.g., if we ignore one account in our budget, what does that
say about what we should do with its parent or children? Conversely if we
estimate one account in our budget, what should we do with its parent or
children? My understanding is that currently there's a single crude option
in the budget to either "roll up" amounts or not, but I struggled with it.
I think that feature needs to be clarified.

That, I hope, is a start to sorting out the budget mess. I actually think
that the existing system is close to working well, but it does need some
tweaks.

-- 
Edward Doolittle
Associate Professor of Mathematics
First Nations University of Canada
1 First Nations Way, Regina SK S4S 7K2

« Toutes les fois que je donne une place vacante, je fais cent mécontents
et un ingrat. »
-- Louis XIV, dans Voltaire, Le Siècle de Louis XIV, Chap. XXVI