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 ledger-cli+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.