The trouble with double-entry...

[Benjamin Carlyle]

Sorry about the long turn-around on my emails to this list. I don't read
this inbox during the week :)

On Sun, 2005-02-06 at 00:48 -0600, Rod Engelsman wrote:
> Benjamin Carlyle wrote:
> >Any first-year university-level textbook should clarify
> >things for you if you are willing to read. My personal epiphany came
> >from reading my brother-in-law's text on the subject. This email will
> >likely not affect your position but maybe will spark some interest in
> >greater research. I am not an account, just an interested hobbyist.
> Actually I've been doing a little research on the Internet. I'm always 
> willing to learn.

:)
Actually that was a genuine recommendation from me. Find out what the
first year university students are reading and get a copy. Accounting
textbooks are a lot more readable than you might think. They have to be,
because the subject matter bores the hell out of most people. If you
already draw some satisfaction from the subject matter then reading the
books will be a breeze.

> >Fluctuations in asset value are normally not reflected in your books. I
> >repeat: Not reflected. There is a fundamental concept in accounting of
> >"book value", which is purely historical and doesn't represent the
> >current value of your assets. Double-entry accounting is not designed to
> >tell you how much you are worth. It's designed to tell you how much what
> >you own cost you. This distinction becomes important when accounting for
> >inventory.
> This is interesting. Because following my mini-rant (and I confess that 
> was what it amounted to, and I apologize to the list for that) I've 
> received at least two e-mails exclaiming my ignorance and, in effect, 
> telling me to go read a book. But you tell me not to do it -- that 
> you're not supposed to try to reflect current valuation -- while Mr. Uhl 
> patiently explained to me how you go about doing it. So it appears that 
> there isn't exactly a broad concensus on this list. FWIW, my surfing 
> research reveals that you are entirely correct -- at least with respect 
> to business accounting. And keeping your investments at book-value has 
> the advantage of making your tax situation a lot clearer as well as 
> reinforcing the fact that you don't have a profit until you have the 
> cash. Personally, I find the whole business of creating faux 
> transactions to and from ersatz gains/loss accounts a pointless exercise.

Heh... my response was a bit of a rant, also. I was in the mood for a
little whoop-arse. Sorry if it hit you too hard.

I would actually take anything you hear on a public accounting forum of
non-professionals with a grain of salt. I believe that most haven't gone
and done their basic research and are speaking primarily from hearsay of
what they've picked up previously from the same kinds of channels. On
the other hand, the view I'm pushing is a stuffy one. It's based on how
accountants work with business. I find it satisfying to work within that
framework as far as I can, and see where I can push it in a home
environment. Others start with what's useful in a home environment and
tend to push things only so far as they see genuine advantage.

As for faux-transactions and faux-accounts... well I suppose I have a
few points to make.
Point 1: Your money is just in a faux-account from the bank's
perspective.
They maintain these fake accounts in the same way accountants would have
you maintain yours. They set up a liability to you. The value of your
account shows up as credit in any statements they give you, even though
from your perspective the account is a net debit ;)
The bank saying an account exists isn't what makes an account real.
Point 2: You should only use useful accounts
Accounting practice and usefulness says what's real and what is fake. If
it's not useful you shouldn't have it.
Point 3: Accruals-based accounting isn't the only way.
If you're taxed on a cash basis, and you think of your accounts on a
cash basis you should account for it that way as well. Double entry
accounting will serve you cash-basis freaks just as well as it serves we
accrual-basis types. Do what's useful to you. Do what gives you the
reports you want to see.

> >The main value of double entry account keeping compared to other forms
> >is that on paper it allows you to compare balances that should add to
> >zero. When they don't, you know you've made a mistake. Computers don't
> >make mistakes as often, so maybe double entry isn't actually required.
> >On the other hand, business and accountants still work this way and
> >there is little real reason to change things and no better alternative
> >presenting itself.
> I think here we need to distinguish between the *philosophy* of DE -- 
> that money has to come from somewhere well-defined and go somewhere 
> well-defined -- and the mechanics of DE -- which are entirely about 
> guarding against math errors. For instance, one reason for the business 
> of debits and credits is a relic from manual arithmetic where it was 
> realized that subtraction was more error-prone than addition. 
> Personally, I find it a lot easier to think in terms of adding to this 
> account and subtracting from that account than trying to keep straight 
> where the debits and credits go. YMMV.

Well, there are real alternatives to double entry accounting. Here I'm
not talking about the different accounting basis, I'm talking about the
concepts of balanced accounts that double entry defines. One alternative
is to simply record everything you do in a raw form, and let the
computer deal with everything else:

Me: Computer? Hello, Computer?
Computer: Hello.
Me: I spent five dollars on coke and chocolate today
Computer: I'll record that fact.
Me: How much have I spent on coke and chocolate this year?
Computer: I'll look at all the times you spent money and I'll let you
know...

Me: Computer, I paid a bill. It's my rates, and covers the next three
months of my occupation
Computer: I'll record that fact
Me: What's the average amount of money per month I'm spending on rates?
Computer: I can tell you that based on your rates bill pay events, and I
didn't even bother to create a prepaid expenses account to draw from in
order to perform my calculation. Are you proud of me?
Me: Yes, computer. You did good.

(I think that revealed just a little too much of my inner psyche...)

> This is all, true. But the fact is that *both* pictures are important 
> and relevant. Either one by itself is incomplete.  And it's more than 
> just the tax situation; the difference between accrual and cash 
> accounting is solvency vs. liquidity. Solvency is an important measure, 
> but it's not one that you would hope to have to test. Solvency is the 
> long run but it's the short run of liquidity that pays the mortgage and 
> buys groceries. Liquidity tells me how I'm doing this month and solvency 
> tells me how I'm doing this year.

Yes, and this is something that the whole double-entry accounting model
doesn't address itself internally: Multiple views of your accounts.

Even in a wholly-accrual-based double entry accounting system you may
have multiple views that is important to keep separate. A company may
want to report its profit in the most even way possible to its company
executives, and to its shareholders. To the tax department, however, it
wants to claim income as late in the peace as possible and expenses as
early as possible. Requiring an accruals-based accounting system both
for tax and internal reporting closes a number of loopholes available to
achieve this, but if depreciation is a big part of the expenses it is
easy to say "I'm depreciating my assets at $10000 per quarter"
internally, but say to the tax department "I'm depreciating $20000 in
the first quarter, $10000 in the second, then $5000 in the last two
quarters of this year". That's fine legally, but the accounting system
isn't going to help you make that separation. In the end you almost have
to keep two separate sets of accounts to maintain that data. The problem
can get even more serious if you have to report earnings one way
internally, another way to the stock exchange, and another way to the
tax office.

As for your solvency issue specifically, Australian businesses listed on
the stock exchange have been required to state their cash position since
the late eighties or early nineties (after a few big high-profit
businesses suddenly and unexpectedly found they couldn't pay their
bills). That's easy to track because in practice you do know which of
your accounts represent cash money. The balance sheet of any big company
should show an asset breakdown that lists their cash on hand, cash they
expect to have in hand within one year, and longer-term assets.
Likewise, their liabilities are broken down into current and non-current
liabilities. Various useful metrics exist that allow you to calculate
and compare solvency between different businesses.

> Can you do the above in one transaction with splits? The way accounts 
> payable would work in a non-business situation is unclear from the help 
> files.

You can do as much as you like in a single split, so long as you
consider the event to have occurred on the same day. If not, you need
more than one transaction. I briefly discussed mentioned the problem of
transaction dates and cleared dates in an email to gnucash-user today.

> FWIW, I'm not the only one questioning some accepted accounting 
> practices. See:
> http://64.233.167.104/search?q=cache:uuFl0qd1H5YJ:www.cbs.dk/staff/hkacc/BOOK-ART.doc+double-entry+bookkeeping&hl=en

Ugh. Making me read...
Ok.

On redundancy:
The internal models gnucash and other accounting systems use are not
redundant. The redundancy it mentions is between the general journal and
each account's transaction entry list. In a paper-based system this
redundancy exists. In gnucash and other accounting systems only one of
these forms will exist in the back-end. The other is generated at
runtime as necessary to provide the user with a conceptually-comfortable
view.

On exactness:
Yep. Accounting is not an exact science. It is possible to treat
expenses as assets. It's possible to disagree from very well-reasoned
positions about what is an expense and what is an asset.

On getting bogged down in the words:
Yep. Accounting can be so full of jargon and accounts with less and less
practical implication and reason that it ceases to serve its functions.
I like this quote: "It is wrong to believe that the task of accounting
is to discover how a firm's financial position is. Rather, accounting is
concerned with what we can say about the financial position."

On accuracy vs timelyness:
This is pretty well-understood in accounting circles. You don't know
what's real until it has happened. In the mean-time you need to work
with estimates and weave the corrections for those estimates back into
the model. This is probably most clear when an invoice is issued. There
is always the chance that invoice won't be paid, and that chance has to
be factored in at the time the invoice is issued. This amounts to an
expense to balance part of the invoice's income.

This article is interesting, and ends up questioning the model of the
creation of a liability to someone which is later paid in cash. It goes
on to describe a three step process that accounting currently fails to
properly address. It follows the logical steps:
1) We expect to make $x1 sales this year
2) We have now have agreements to sell $x2 worth of units
3) We have issued invoices for $x3 worth of units
4) We actually received payments for $x4 worth of units

A cash-basis accounting model only records (4). An accruals-basis
accounting model records both (3) and (4), and forces the accountant to
jump a hoop or two in reporting the difference between what has been
realised and what has come as cash into hand. Traditionally, a budget
has been used to track (1). Perhaps you could claim that (2) is covered
by scheduled transactions and things like loan accounts. The article
makes the claim that (2) is not covered formally by our current
accounting systems and sees that as a significant problem. It also
pushes the notion that budgets should be part of the reporting process,
just as invoices and payments are.

The author would like to see four reports, updated in real-time if
possible. The cash position of the entity, the "realised" position
(which would cover all actual invoices), the "agreed" position
(including uninvoiced contractual agreements), and the "expected"
position (including all budgeted items for the period). I'm not sure if
the creation of all such reports would kill double-entry accounting.
Just as cash-basis data can be extracted from an accruals-basis system,
I suspect that all four types could be extracted from a double-entry
system that tracked data from all of these points on the accuracy vs
timelyness scale. On the other hand, I could see how another scheme may
make the whole thing more wieldy.

> My focus here is on personal finances and the utility of a program like 
> gnucash to help you effectively manage those finances. The formalism of 
> DE as presented in the interface is, on the one hand, unnecessarily 
> confusing overkill, while on the other hand, requiring you to jump 
> through the hoops to represent your financial reality in a useful way.

You're probably right, to be honest.

> What I'm looking for here is a tool which actually *helps* you deal with 
> the dual perspectives of solvency and liquidity -- net worth and cash 
> flow -- in a relatively straight-forward manner. This tool should not 
> only accurately track accounts, but include the budget planning tools of 
> a spreadsheet.

I think this is something you can do reasonably with gnucash by
identifying accounts as "cash" or otherwise, and creating reports that
use this distinction. Budget planning is beyond what gnucash can really
do (although future-dated transactions can be useful tools in this
regard). Could there be one conceptual system that made this all work
cohesively together? Maybe. In our lifetimes? Maybe.

> Let me give you another example of how the DE accrual paradigm makes 
> life (slightly) more inconvenient. Not all transactions with tax 
> consequences involve incomes or expenses; events like investing in an 
> IRA are clearly transfers between asset accounts, yet these events have 
> tax benefits. Currently gnucash is unable to export those those 
> transactions in a TXF file because you can only tag income and expense 
> accounts for tax lines. It's really the same problem as the medical bill 
> I was tallking about earlier; a liability is just a negative asset after 
> all. So if you could just tag those transactions with a tax "category" 
> you would have no need to juggle between real and fake expense accounts.

As I don't live in the US I am not able to use TXF files. Instead, I use
reports to do this sort of thing (actually, truth be told I'm still
using Quicken under wine...). If you were handling your accounts in real
detail you could actually track the tax implications of each transaction
as you make it rather than waiting for the end and wading through
swathes of data. You would have a "Prepaid Tax" account and "Tax
Liability" account. Transfers of this nature would reduce your tax
liability (presumably by reducing your taxable income or increasing your
deductible expenses). I've been experimenting with such a model myself
out of an awful kind of sadism. Unfortunately, neither gnucash or
Quicken provide a means I'm satisfied with to do this impact analysis
and reporting.

> There's a relatively simple fix for the asset appreciation problem as 
> well. The Finance Quote module can display today's price for market 
> securities. Purely for display purposes, why couldn't the account ledger 
> for a stock display columns for the current price and market value? No 
> need to screw around with "unrealized" gains and losses -- after all 
> they're "UNREALized" -- just tell me what they're worth today. You might 
> even be able to do the same thing for vehicles if you could figure out a 
> way to automatically hook into Kelly Blue Book.

Now you're asking for data much more timely and much less accurate than
even the budget data your article's author craves :)

When devising a data model for my own prototype accounting package I
always pictured a separate table that would keep track of current and
historical prices for analysis of share values. Ultimately, the data is
distinct from your accounting system but can be queried and displayed in
conjunction with accounting data. It was always a "phase two" idea for
me.

It would certainly be my preferred way to work if I were a gnucash user
to have share prices updated in my accounts only when I said so. In the
mean-time they should appear as distinct data.

> Finally, another thing I would like to see is the ability to have the 
> components of a split transactions have different dates associated with 
> them. The date you wrote the check, the date it posted to the credit 
> card account, and finally the date it cleared your bank. It would make 
> reconciling statements easier.

Oh, that's right. You were the original source of this comment. Well,
I've addressed that separately :)

-- 
Benjamin Carlyle <benjamincarlyle at optusnet.com.au>