Hacker News new | past | comments | ask | show | jobs | submit login

Thanks for asking.

In the programming world typically we would use a signed value[0] instead of separate ledgers[1] for debit and credit (ie. +$12 and -$11.50 within one ledger, resulting balance +$0.50).

Whereas, in the traditional double entry world, you have two ledgers, one called 'credit' and one called 'debit', BOTH with POSITIVE balances. You don't know where you stand until you look at both and apply appropriate signs, then make a total. This obviously can function and does make sense if you are used to it, but is an artifact of ancient book-keeping practices and a perfect basis for confusion in many cases. Especially since, on different days, you might be the person on either side of the equation (ie. then credit becomes your debit and debit becomes your credit, should you - for example - acquire a competitor).

You could of course store things in any way you like and present them differently, but there's no need to TALK and THINK about them jumping through such pointless logical hoops. (Many philosophers, writers, linguists, mathematicians and programmers have explained the value of concise and explicit language as a boon for clarity of thinking.)

You can model transactions between entities as a directed graph[2], allocating each transaction a unique identifier. In this way, the 'credit' or 'debit' nature of each transaction is no longer the property of "where you are looking from" (subjective property), but rather objectively associated with the source and destination nodes for that transaction in the directed graph.

I believe these approaches promote fiscal literacy because: (A) Everyone with basic mathematical comprehension understands the meaning of + and -. (B) Using common language instead of professional vocabulary reduces the chances for misunderstanding and thus fraud. (C) Maintaining a common ledger for credit and debit (positive and negative value) transactions means they are always sorted through time which is probably our most basic intuitive sense of record as humans. (D) We should always be suspicious of appeals to authority, and the professional vocabularies and self-auditing professional societies in which they congregate, which generally turn out to be the inertia-driven self-interest groups of dynastic rent seeking. (E) Objective and explicit record keeping is good practice. (F) The "whole picture" (all transactions) is a clearer and more logical default intellectual scope than the "half picture" (only credit, or only debit transactions).

Using these tools you can model transactions in any economy, whereas using double entry bookkeeping you will encounter increasing issues when modeling multi-party transactions, multi-hop transactions, multicurrency transactions (traditional double entry book keeping systems utilize a single currency per ledger), etc.

For further observations and thoughts along these lines see IFEX.[3]

[0] https://en.wikipedia.org/wiki/Signedness [1] https://en.wikipedia.org/wiki/Ledger [2] https://en.wikipedia.org/wiki/Directed_graph [3] https://raw.githubusercontent.com/globalcitizen/ifex-protoco...




I thought a major argument for double-entry bookkeeping was for error detection and correction/auditing. Was I mistaken? It was sold to me like that many years ago.

We have technology that will help with that (signing, hashes, parity bits, blockchain, etc) but none of that matches the simplicity of a notepad in a desk at a local takeaway store.


Yes, that's the classic argument. However, it is quite irrelevant today, where human error and time are both stupendously more expensive than precise record keeping executed by software in the first place.

The tools you mention are tangential to this: signatures are for non-repudiation and authenticity, hashes are for checksums, parity is for self-repair in bad checksum cases (rarely used in application level software today), and blockchains are for distributed trust (eg. distributed ledgers), essentially providing the combined properties of signatures and hashes to a shared database in a distributed system over time.

Note that all depend on the input of valid data in the first place, and none can be efficiently applied to a manually written notepad.




Consider applying for YC's first-ever Fall batch! Applications are open till Aug 27.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: