Hacker News Reader

Comment by captainmuon | Hacker News Reader

I think I understand the mechanics of double entry bookkeeping, but what I find confusing about it is that it is the redundancy. People emphasize the error detection, but these errors can only exist in the first place because of the requirement to record each transaction twice. Also you get a lot of "fictious" or virtual accounts that don't correspond to concrete piles of cash or bank accounts.

It seems much easier to me to just record the transactions ($100 from bank account to shop on date). Then you can generate balanced account sheets from this automatically.

But you can go further and look at the actual cash flow. This is something you can't easily do with double entry: how much money did I have on day X? How much money will I have approximately on day Y? Will any asset fall below a certain value? And make nice graphs out of everything.

View on HN

I didn't see the purpose of it when I got told of the principle at school. The supposed control of error detection feel like a very vague benefit to me. Especially now with computers. Actually hashing of the chain of values would probably be more secure (like bitcoin yes).

However, I think the real value in double entry accounting is that it not only represent money you have but also things you own: If you buy a pen, you have less money, but you have an extra furniture pen and your accounting can reflect that. It can also reflect the loss of value of the pen over time.

It is also useful if you get in debt to buy something: you transfer money from a debt account to your current account, you buy the thing you wanted to buy and appropriatly report the value of what you own in accounting. You now have a thing, and a debt to be repaid in whatever term was agreed.

It's also very useful as a tool of control for state. All exchanges you have with other entities are recorded in a separate account. It's possible to take that account and check that the other entity accounting book match exchanges they have with you.

> People emphasize the error detection, but these errors can only exist in the first place because of the requirement to record each transaction twice.

That's like saying that check digits in credit card numbers detect errors that only exist in the first place because we entered more digits. Or that checking the md5sum after downloading a binary file detects errors that only exist in the first place because we downloaded two files instead of one.

Any increase in redundancy should increase the raw error rate. However, with a credit card check digit or md5sum file the additional data is relatively tiny compared to the data it's responsible for checking, so you're much more likely to catch an error than to introduce a new one. Double-entry bookkeeping, in the traditional sense where you actually record every detail about each transaction separately in two or more journals, is more like a RAID-1 mirror: double the data, so approximately double the raw error rate, and if a discrepancy does turn up you'll have no idea which entry was wrong and which was right. But if you lose a journal outright you can recreate it from the mirror image.

So far as I know, most actual "double-entry" accounting software just stores each transaction once in a general ledger. The appearance of doubled entries is all in the UI where it processes the ledger to present a list of transactions from the perspective of a certain account. You still get the benefit that the system won't allow the balance of one account to be increased or decreased without an equal and opposite change in other account(s)—money cannot be created or destroyed[1], only moved around.

[1] Unless you're the Federal Reserve. They play by different rules.

Not really. In double entry bookkeping you have to always add every entry "twice" (I'm not sure how prevalent it is to have split entries, $20 in one and $10+$10 in another - I've learned in school that you don't do that).

I'm just suggesting a different entry format where you enter the number once and the computer creates both bookkeeping entries. Yeah you have the chance to make a typo, but I guess preventing that kind of error is not what this is about, is it?

It's actually not like a checksum, but more like the DRY (don't repeat yourself) principle. Where one framework requires you to define a constant, say a SQL table name, in multiple places, and another lets you type it only once. Like handrolled SQL vs- an ORM. In this case, I think less typing is less error prone.

> Yeah you have the chance to make a typo, but I guess preventing that kind of error is not what this is about, is it?

That's the kind of error it catches, where you entered one of the entries (say, the cash outflow) and not the other (say, the invoice you were paying) or they were not consistent.

Note it's not always as easy as "this number goes into two places". One entry in one account may correspond to multiple entries elsewhere (say, price plus tax). At least that's what I think, nobody told me not to do that or I don't remember...

And it's literaly a checksum.

https://en.wikipedia.org/wiki/Trial_balance

"The purpose of a trial balance is to prove that the value of all the debit value balances equals the total of all the credit value balances. If the total of the debit column does not equal the total value of the credit column then this would show that there is an error in the nominal ledger accounts."

I agree, I don't understand how creating two entries in two separate locations is a good thing. You have to constantly monitor that you have matching entries everywhere. No thanks.

Instead, have a master list of transactions with money in/out in each transaction. As long as every transaction balances, you are golden.

Balances, history, cash flow, etc. can all be figured out from this one central location.

This is how ledger-cli works.

I haven't used ledger, but it seems to be double entry accounting too. According to the example:

    2015/10/12 Exxon
        Expenses:Auto:Gas         $10.00
        Liabilities:MasterCard   $-10.00

whereas I would have something like:

    2015/10/12   Exxon  $10.00  MasterCard  ->  Gas

The idea would be that the form of the transaction doesn't allow you to screw up - it is neccessarily balanced because you only give the amount once. A bit like a typed language only allows well-formed programs to run.

Modern accounting systems like most ERPs allow you to specify the account and offset account in one line. It pretty much like you describe and is the preferred method for simple entries with only two accounts.

It gets a bit trickier when, for example, sales tax is involved where a simple example for a sale of $1.000 with 25% VAT would be:

  cr. revenues                $800
  cr. VAT patable             $200
  dr. accounts receivable    $1000

Reply on news.ycombinator.com