Why I don’t want to use auxiliary dates for bank reconciliation … or anything else
Peter McArthur
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:
- Go through your accounts and your bank statement, matching them item by item, and checking off matched items.
- 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:
- It’s hard to detect and correct errors.
- 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.
- 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.]
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].
o1bigtenor
--
John Wiegley
PM> The manual shows us how unclear the semantics are. Most people seem to use
PM> auxiliary dates as a date when a cheque is *cleared*. But the manual also
PM> shows them being used when a cheque is *paid*:
It should be noted here that one of the "features" of Ledger is that it leaves
as much of the semantics of your accounting as possible up to you. This is a
reason why beancount was created: To choose the best notion of what things
mean in a financial setting, and then to impose those semantics to help you
avoid errors.
C++Ledger, however, is just a glorified calculator. It doesn't tell you what
your inputs or your outputs should mean.
--
John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2
o1bigtenor
>>>>> "PM" == Peter McArthur <peter.m...@gmail.com> writes:
PM> The manual shows us how unclear the semantics are. Most people seem to use
PM> auxiliary dates as a date when a cheque is *cleared*. But the manual also
PM> shows them being used when a cheque is *paid*:
It should be noted here that one of the "features" of Ledger is that it leaves
as much of the semantics of your accounting as possible up to you. This is a
reason why beancount was created: To choose the best notion of what things
mean in a financial setting, and then to impose those semantics to help you
avoid errors.
C++Ledger, however, is just a glorified calculator. It doesn't tell you what
your inputs or your outputs should mean.
Peter McArthur
On Wednesday, 31 May 2017 18:58:10 UTC+1, John Wiegley wrote:
>>>>> "PM" == Peter McArthur <peter.m...@gmail.com> writes:
PM> The manual shows us how unclear the semantics are. Most people seem to use
PM> auxiliary dates as a date when a cheque is *cleared*. But the manual also
PM> shows them being used when a cheque is *paid*:
It should be noted here that one of the "features" of Ledger is that it leaves
as much of the semantics of your accounting as possible up to you.
Compare that to tags. While there are two special tags called * and !, there's nothing they can do that other tags can't, as far as I'm aware. For instance, this:
$ ledger -f journal balance %/cleared/
This is a reason why beancount was created: To choose the best notion of what things mean in a financial setting, and then to impose those semantics to help you avoid errors.
John Wiegley
o> So - -- from your perspective you don't see a value in having something
o> defined that would help with the date paid, date cleared, date issued (more
o> for invoicing) as a specific 'data type' available for use?
Not as part of the internals of Ledger, no. As something in the form of
external scripting, such as by using the Python support, sure.
o> I understand that you see C++Ledger as a 'simple' tool - - - I think it is
o> a tool that appears simple but has the framework to do even more. (To use
o> the analogy of a calculator it looks like perhaps just a 4 function machine
o> and then when you dig a little deeper you see the scientific functions and
o> then deeper yet you find the statistical functions and the vector/polar
o> calculations and and and. This is how I see ledger - - - its a tool with
o> little showing on the surface but there is a vast world below!)
You might want to give beancount a look, since it has much more of an
accounting focus.
John Wiegley
PM> but I don't really see what you're getting at. Power and flexibility are
PM> good. The ability to add constraints is also good. They work best when
PM> used together.
I want you to add the constraint, not me. If there's a constraint you want to
encode but can't, I'd want to find a way to generalize what you're trying to
accomplish.
Brian Exelbierd
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:
- Go through your accounts and your bank statement, matching them item by item, and checking off matched items.
- 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:
- It’s hard to detect and correct errors.
- 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.
- 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.
Peter McArthur
1. This seems to make it no easier to detect and correct errors than a tick mark on your bank statement. To add the final lines you still have to go through the statement line by line.
2. There still seems to be no record tieing your entry to the line item on your bank statement. Had you added a comment containing the exact details from your statement then you could match. This could also be accomplished by just numbering the entries on your bank statement and then adding a cleared line number comment.3. Agreed as solved if a suitable parser is written.
Date Transaction Type Description Money out Money in Balance
All four posts are now linked by being part of the same transaction, without any need for transaction codes.
By the way, I’m uncomfortable with the way you used an :XYZ subaccount. Is it not possible to do the same thing with tags?
Brian Exelbierd
Peter McArthur
I feel like we've added a lot of work (assuming no automation)
without solving the problem.