Comment by TuringTest | Hacker News Reader

Comment by TuringTest | Hacker News Reader

Parent Full thread

> I know a decent bit of both worlds so that disconnect in perceptions always amuses me.

Double-entry bookkeeping was from its inception an error-correction code that could be calculated by hand.

Modern databases contain much more powerful error correction methods in the form of transactional commits, so from a pure technical point, double-entry bookkeeping is no longer needed at all; that's why programmers have a hard time understanding why it's there: for us, when we store a value in the DB, we can trust that it's been recorded correctly and forever as soon as the transaction ends.

The thing is, cultural accounting still relies on the concepts derived from double entry bookkeeping as described in the article; all those assets and debts and equity are still used by the finances people to make sense of the corporate world, so there's no chance that they'll fall out of use anytime, at least 'in the context of a company' as you out it.

Now would it be possible to create a new accounting system from scratch that relied on DB transactions and didn't depend on double entry? Sure it can, in fact crypto coins is exactly what happens when computer engineers design a money system unrestricted from tradition. But in practical terms it still needs to relate to the traditional categories in order to be understood and used.

> from a pure technical point, double-entry bookkeeping is no longer needed at all

Just because databases are transactional doesn't mean the entire system is. Double-entry accounting still helps catch errors.

A concrete example, since people like to think databases dealing with money are especially transactional, when they're not ...

I used to work at a small regional bank. In the course of some network maintenance, I accidentally disrupted the connectivity to an ATM while a customer was doing a transaction.

The next day, our accounting folks caught a problem with reconciliation, and the customer called to follow up as well. My interruption caused a deposit to proceed far enough to take their checks and money, but failed to credit the customer's account.

It's very hard to orchestrate transactions perfectly across multiple organizations and systems. You can't hand-wave this away by pointing at db consistency guarantees. Traditional accounting techniques will catch these errors.

I'm not sure that ATMs even have the ability to communicate certain failure classes back to the acquiring bank. eg, a cash dispenser malfunction is common enough to be mentioned by VISAs network rules explicitly, but as far as I know will almost always require manual reconciliation between the ATM operator and the network.

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 transfers. For example, is we are logging a sales, cash increases by $100, and revenue increases by $100. What's the "from" here? Revenue isn't an account where account is taken from, it is the "source" of the cash increase. So something like the following doesn't capture the true semantics of the transaction.

```json { "from": "Revenue", "to": "Cash", "amount": 100 } ```

Instead, in accounting, the above transaction is captured as the following.

```json { "transaction": "Sale", "entries": [ { "account": "Cash", "debit": 100, "credit": null }, { "account": "Revenue", "debit": null, "credit": 100 } ] } ```

It gets worse with other entries like:

- Depreciation: Nothing moves. You're recognizing that a truck is worth less than before and that this consumed value is an expense. - Accruals: Recording revenue you earned but haven't been paid for yet. No cash moved anywhere.

The limitation of ledgers with "from" and "to" is that it assumes conservation of value (something moves from A to B). But accounting tracks value creation, destruction, and transformation, not just movement. Double-entry handles these without forcing a transfer metaphor onto non-transfer events.

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 than double entry, though they don't need to be exposed into the business domain). Any tracking that you'd want to do with double-entry accounting could be done by creating single-entry accounts with similar meaning, and registering each transaction once, if you know that you can trust the transaction to be recorded correctly.

I think this depends on what you consider to be the fundamental trait of double-entry accounting: the error-checking or the explanatory power.

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.

[flagged]

I'm not presuming I know anything about accounting. I know a great deal about data recording and management though, and my analysis is done from that perspective.

I explicitly recognized that the practice of accounting as a discipline keeps using traditional concepts that are culturally adequate for its purpose. What my posts are pointing out is that the original reason for double-entry records, which was having redundant data checks, is no longer a technical need in order to guarantee consistency because computers are already doing it automatically. From the pure data management perspective I'm analysing, that's undeniable.

The most obvious consequence of this analysis is that traditional bookkeeping is no longer the only viable way of traking accountability; new tools open the possibility of exploring alternative methods.

Compare it to music notation; people keep proposing new ways to write music scores, some of them computer assisted; and though none of them is going to replace the traditional way any time soon, there are places where alternative methods may prove useful; such as guitar tablature, or piano-roll sheets for digital samplers. The same could be true for accounting (and in fact some people in this thread have pointed out at different ways to build accounting software such as the Resources, Events, Agents model.)

https://en.wikipedia.org/wiki/Resources,_Events,_Agents

Reply on news.ycombinator.com