First I should describe my philosophy.
We’re all computer nerds here, I think, so we all know the value of simple,
flexible abstractions with strong mathematical underpinnings. Relational
databases, the lambda calculus, finite automata, context free grammars and
so on. I believe double-entry book keeping deserves a place in that last.
I shan’t go into this in any depth, but I don’t think many people – even
professional accountants – appreciate the mathematical brilliance that
underlies the double-entry system. But it was this brilliant idea that
turned all our ad hoc book keeping systems into a coherent, flexible whole,
with lots of side benefits I won’t go into here.
So, just as we have SQL for talking about relational databases, or regular
expressions for talking about finite automata, I see Ledger as a language
for talking about double-entry book keeping, and in my view that is a very
good thing.
This topic arose in the context of bank reconciliation, so, let’s talk
about bank reconciliation. The traditional, pen-and-paper way of doing it
is:
1. Go through your accounts and your bank statement, matching them item
by item, and checking off matched items.
2. At the end of this process, there will probably be a few unmatched
items in your accounts, because they haven’t cleared yet. Make a note of
these in a Reconciliation Report, and check that they are all reconciled
next month.
The advantage of this method is that it is quick and efficient. That
mattered a lot in the era of pen-and-paper accounting, but now it doesn’t,
so I think we should consider its disadvantages too:
1. It’s hard to detect and correct errors.
2. There is no record of which item in your accounts matched which item
in your bank statement, so if you ever need to check again your work is
partially wasted.
3. The Reconciliation Report is a new kind of artefact that exists
outside your core accounting system.
All of the above can be solved if we split the bank account into two sub
accounts: one for uncleared transactions and one for cleared transactions.
It’s the double-entry way of doing it. They didn’t do this in the era of
pen-and-paper accounting because it wasn’t worth the extra effort, but now
it just seems the obvious and natural thing to do.
“So why don’t professional accountants do it?” I hear you ask. That’s a
good question. I went and asked that very question on an accountant’s forum
(which I was already a member of), and I got five answers. They were:
1, 2 & 3. But that’s more complicated the way we do it now. *[I disagree!]*
3. That would make life harder if the computers stopped working and we had
to go back to pen-and-paper. *[Fair point.]*
5. Our accounting software already does things that way, and it works great!
I believe that accountants could start using the new system now, if they
wanted, but most are reluctant to move on from a system they’ve invested so
much in learning. Pretty much how my wife felt when I persuaded her to
switch to a Mac. ;-)
So, now, on to Ledger’s way of doing things. I said earlier I disliked the
* tag. That’s not really true. I have no problem with metadata tags without
special semantics. But I REALLY dislike auxiliary dates. They are *not* a
core concept of double-entry; they have unclear semantics; and they violate
some important design heuristics without good reason, namely:
- *Zero, one, infinity:* An entity should be forbidden, one should be
allowed, or any number should be allowed. *[Definitely not two!]*
- *Minimalism:* A designer knows he has achieved perfection when there
is nothing left to take away. *[I do not think auxiliary dates are ever
necessary.]*
The manual shows us how unclear the semantics are. Most people seem to use
auxiliary dates as a date when a cheque is *cleared*. But the manual also
shows them being used when a cheque is *paid*:
2008/01/01=2008/01/15 Client invoice
Assets:Accounts Receivable $100.00
Income: Client name
or when it is *not* paid:
2008/10/16 * (2090) Bountiful Blessings Farm
Expenses:Food:Groceries $ 37.50 ; [=2008/10/01]
Expenses:Food:Groceries $ 37.50 ; [=2008/11/01]
Expenses:Food:Groceries $ 37.50 ; [=2008/12/01]
Expenses:Food:Groceries $ 37.50 ; [=2009/01/01]
Expenses:Food:Groceries $ 37.50 ; [=2009/02/01]
Expenses:Food:Groceries $ 37.50 ; [=2009/03/01]
Assets:Checking
If you included all three of these in your accounts, you’d end up in a
terrible mess. And in any case, a trained accountant would look at the two
examples above and say, “No, you’re doing it wrong! You should …” and then
describe a method that doesn’t use auxiliary dates at all. (I’ll leave the
details as an exercise for the reader.)
To be clear, I’ve nothing against adding extra dates to accounts *per se*.
But I dislike the privileged status given to auxiliary dates. I would much
rather see Ledger improve its support for typed tag values (e.g. cleared::
[05/30]) so that auxiliary dates could be downgraded to a special syntax.
E.g. [=05/30] might become a synonym for AuxiliaryDate:: [05/30].
--
---
You received this message because you are subscribed to the Google Groups
"Ledger" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
