The trouble with double-entry...

[Rod Engelsman]

Benjamin Carlyle wrote:

>I'll start with the stick:
>  
>
Ouch, ouch!!  :)

>It's not the truth, it's a lack of understanding. You aren't smarter
>than 700 years of collective experience.
>
I never said I was.

> You just haven't grokked that
>experience, yet. 
>
Heinlein! Am I the stranger in a strange land?

>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.

>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.

>
>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.

>>Another real-life situation: Suppose you strike ill and incur a large 
>>medical bill. So large, in fact that you have to pay it over time. 
>>Logically, that's a liability. So to create the liability you have to 
>>incur a corresponding expense. Payments against the liability are 
>>transfers that don't change your net worth. But medical expenses are 
>>deductible. But you can only claim that part of the bill that you have 
>>actually paid. So you're in a situation where it's damn difficult to 
>>simultaneously track your net worth accurately (which is really the 
>>whole point of traditional double-entry) and account for your deductible 
>>expenses.
>>    
>>
>
>You have an expense that is incurred all at once as a liability. It's
>just like any loan. You pay down your liability as you get the money.
>That's fine. It's a normal part of accounting, too. What you're
>concerned about is the tax implications.
>  
>
Theoretically, anyway. In reality there's no point for me to itemize 
because I don't have enough deductions.

>The trouble here is that you're jumping between two accounting systems.
>Businesses are usually required to run on an accruals system. This
>forces them to declare every expense as soon as they incur it, rather
>than waiting until they've paid it to declare. It makes for less noise
>in the business's view of its net worth and makes it easier for
>financial institutions, government, and investors to make sense of the
>real financial position. Individuals can get the same benefits in
>analysing their own accounts by using and accruals system. When we teach
>double-entry accounting, we are often teaching the accrual method.
>
>Unfortunately, Individuals are often taxed based on another accounting
>system. The cash basis model of accounting does not consider an expense
>to have occurred until you've actually paid the bill. It makes it easier
>to hide transactions (by just not paying for things on time or by
>negotiating long payment periods) and to hide your financial position.
>It also makes it harder to interpret your financial position because you
>don't always know what's owing. When you deal with the intersection of a
>private accrual-based accounting system and a tax-related cash-based
>accounting system you do have to step through a few extra hoops. That
>may include moving money from one expense account to a special
>"tax-related" version of the same account, or may involve an offsetting
>account that describes the tax implications of each transaction you
>make.
>
>  
>
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.

>>The whole problem stems from the inability to distinguish between 
>>"internal" and "external" liabilities. By that I mean internal 
>>liabilities are things like loans and credit cards. While external would 
>>be an outstanding bill -- an account payable, I guess. In the example 
>>above, if you were to pay the medical bill with a credit card or take 
>>out a bank loan, then you could easily and accurately account for the 
>>expense for taxes.
>>    
>>
>
>In the situation you described above, I would probably account for the
>expense by transferring it initially to a medical bill liability
>account. Over time, I would transfer money to that account from a
>"payable, the hospital" account. Finally, I would pay the bill by
>transferring money from my cash account to the payable account.
>
>i.e...
>I had a motorbike accident
>Expenses:Medical	1000DR
>Liabilities:Medical	 	1000CR
>
>I've recieved this month's invoice, $100
>Liabilities:Medical	100DR
>Payable:Hospital		100CR
>
>I've paid this month's invoice
>Payable:Hospital	100DR
>Cash				100CR
>
>At this point we have the current balances:
>Expenses:Medical	1000DR
>Liabilities:Medical	900CR
>Payable:Hospital	0CR
>
>If you query for the amount transferred into Payable:Hospital, you'll
>see a value of $100.
>
>I actually work (almost) exclusively through payable accounts for bills.
>I can see in a single account all of the payments I have made to each
>creditor and when those payments were invoiced. This actually achieves
>your suggested goal of separating "internal" and "external" accounts.
>The payable accounts are external, and the rest are internal.
>
>  
>
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.


>>Now here's where I screw with 700 years of accounting tradition. I think 
>>it's just wrong to equate an account -- real physical account like a 
>>bank account -- with a conceptual entity like an expense category. When 
>>I pay the rent each month I'm not writing a check to "Rent", but rather 
>>to my landlord -- another real palpable entity. In real accounting, who 
>>you pay the money to doesn't matter; it's little more than a memo. It's 
>>confusing a who or where or what with a why.
>>    
>>
>
>Accounting theory is like XML. If it ain't working, you aren't using
>enough of it.
>
>  
>
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

But my point really isn't to question the way accounting is done in 
business. And I'm sure that gnucash is a fine example of a program 
designed to work the way a business accountant would want it to work.

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.

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.

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.

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.

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.

Rod