The trouble with double-entry...

[Mark H. Wood]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sun, 6 Feb 2005, Rod Engelsman wrote:
[deletia]
> 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.

I suspect that at least part of the problem is the dearth of books on
bookkeeping and accounting from a personal perspective.  I trawled through
the local big chain bookstore recently and found lots of books that teach
you how to account for salaries and inventory and a bunch of other stuff
that I don't have.  The only books with a personal orientation were
"personal finance", which is mainly a codeword for "how to choose an
online broker."

> 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 object.  I think that accounting and budgeting should be *two* tools
sitting atop a common data store.  The reporting engine sits next to them.

[snip]
> 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.

I have to agree with some of this.  Assets have two values:  what you paid
(less depreciation), which is real and verifiable and should probably be
the basis for most of your calculations, and what you could probably get
for it today, which is conjectural and useful only for deciding whether to
sell it.  Maybe that should be yet another tool, to keep the accounting
interface from becoming cluttered.  Having 69 different kinds of registers
with different sets and numbers of columns is going to be confusing and
hard to maintain.

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

Uh?  The clearing date would be useful for a check.  The date your payment
was posted to your card account is relevant only to that account.

Actually, now that I think of it, the date a check was written has very
little meaning either in the accounting system or even in the checkbook.
The only reason we care at all is probably that we know it immediately and
can jot it down in the register, while we have to wait on average 15 days
to learn the clearing date (which is the only date with actual
consequences for the account).

- -- 
Mark H. Wood, radical centrist     OpenPGP ID 876A8B75     mhwood at ameritech.net
No amount of clipart will save dull writing or an uninteresting topic.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: pgpenvelope 2.10.2 - http://pgpenvelope.sourceforge.net/

iD8DBQFCDiQoeziYCIdqi3URAhyDAKCFbBTlOlqSrEMwn8+Oe2Pq6RxhnQCgiaob
wcJANtGyYceMmkn8vLbab3I=
=dlaI
-----END PGP SIGNATURE-----