3 ms·

> 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

by kgwgk 6y ago

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

deleted 6y ago
[deleted]
captainmuon 6y ago
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.
- kgwgk 6y ago
  > 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 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."
nybble41 6y ago
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.

by kgwgk 6y ago

deleted 6y ago

[deleted]

captainmuon 6y ago

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.

kgwgk 6y ago
> 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 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."

nybble41 6y ago

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.