Earlier quoted context omitted.
The crypto model of single entries with "from" and "to" field works well for transactions. For example you move $100 from checking to savings account, something like the following will capture it perfectly. ```json { "from": "Checking", "to": "Savings", "amount": 100 } ``` This is basically what a crypto ledger does. But the main reason why we need double entry accounting is that not all accounting entries are transf…
But you don't need double entry to register increases or decreases of value; you could as well just use single-entry accounting and add or remove money from a single account, using transactions that are not transfers. In the past this was problematic because you missed error-checking by redundance, but nowadays you can trust a computer to do all the checking with database transactions (which are more complex checks t…
It is true that by enforcing that value movement have both a source and a target, we make it possible to add a useful checksum to the system. But I believe this is a side benefit to the more fundamental trait of requiring all value flow to record both sides, in order to capture the cause for each effect.
I agree with your general perspective though: technology has afforded us new and different tools, and thus we should be open to new data models for accounting. I don't agree with other commenters that we should tread lightly in trying to decipher another field, nor do I agree with the view that the field of Accounting would have found a better way by now if there were one. Accountants are rarely, if ever, experts in CS or software engineering; likewise software developers rarely have depth in accounting.
Source: just my opinions. I've been running an accounting software startup for 5 years.