The trouble with double-entry...
rodengelsman at ruraltel.net
Sun Feb 6 01:48:08 EST 2005
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
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
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
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
>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
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 had a motorbike accident
>I've recieved this month's invoice, $100
>I've paid this month's invoice
>At this point we have the current balances:
>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
>>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
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
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.
More information about the gnucash-user