Accounting for Computer Scientists (2011) • Hacker News Board

Re: Accounting for Computer Scientists (2011)

#51

Post by bokenator » Sat, Jan 03, 2026, 1:09 PM UTC

TuringTest wrote: post #44

Havoc wrote: post #17

Earlier quoted context omitted.

>I never understood double entry bookkeeping It only makes sense in the context of a company. Yes you can shoehorn it into a personal context and/or treating it like some sort of database like hn's accounting posts love to do but that's not what the real accounting world looks like at all. An accountant armed with a low/no code solution isn't going to write great code. That I think is obvious to every hn reader. But…

> 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 ha…

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.

Re: Accounting for Computer Scientists (2011)

#52

Post by TuringTest » Sat, Jan 03, 2026, 2:28 PM UTC

bokenator wrote: post #51

TuringTest wrote: post #44

Earlier quoted context omitted.

> 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 ha…

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

Re: Accounting for Computer Scientists (2011)

#53

Post by malwrar » Sat, Jan 03, 2026, 2:53 PM UTC

LV123 wrote: post #21

NikolaNovak wrote: post #9

I never understood double entry bookkeeping and that's where the author immediately loses me again: Early on after 4th diagram, author includes sentence : "Because every transaction appears twice, once positive and once negative" There is something so obvious about this to accounting folks that they always make the massive jump without any explanation. The previous diagram absolutely does not have positive and negati…

> I never understood double entry bookkeeping While I completely agree with you and have had the same experience, I'll try to phrase it in a way that might "click" for you: 1. An account is an abstract bucket that aggregates things of the same type. For example, the "Sales" account contains all the income from sales and the "Furniture" account represents the value of all the furniture. The "bank account" represents y…

Thanks for this explanation, I see the “graph” now!

Re: Accounting for Computer Scientists (2011)

#54

Post by jltsiren » Sat, Jan 03, 2026, 2:57 PM UTC

dagss wrote: post #40

I read this article on HN ten years ago and it has been very important to me in a career working on a special purpose accounting (for automated reconciliation of bank accounts of a payments processor). The biggest shift from conventional accounting is the use of negative numbers instead of debit/credit. I believe that accounting would have been a lot more accessible to professionals from science/math backgrounds if n…

I think the biggest challenge is that negative numbers are fundamentally a hack in this context. You don't have negative $100 in your bank account, and you don't pay negative $100 for something. Instead, you are $100 in debt or you receive $100, which is qualitatively different. Such qualitative differences should be represented using the type system.

Re: Accounting for Computer Scientists (2011)

#55

Post by skywhopper » Sat, Jan 03, 2026, 4:00 PM UTC

TuringTest wrote: post #52

bokenator wrote: post #51

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…

[flagged]

Re: Accounting for Computer Scientists (2011)

#56

Post by memset » Sat, Jan 03, 2026, 4:29 PM UTC

tnn000 wrote: post #45

Can I replace Credit = From and Debit = To?

It depends on the “normal balance” of the account.

For Asset and Expense accounts, yes. For Liabilities, Equity, and Revenue it is the opposite.

Re: Accounting for Computer Scientists (2011)

#57

Post by memset » Sat, Jan 03, 2026, 4:29 PM UTC

I wrote an article on how to model a ledger with a DB. https://www.jaygoel.com/posts/building-a-scalable-accounting...

It addresses how to model dr/cr in a DB with positive and negative numbers, but still produce reports with positive numbers as expected

Re: Accounting for Computer Scientists (2011)

#58

Post by poslathian » Sat, Jan 03, 2026, 4:31 PM UTC

This is the freshest take I have ever seen. Kudos, so cool.

My professional career has been 20 years of physical ai research and now industry. My dad insisted I take corporate accounting in undergrad.

It’s a skill I use every single day, double entry bookkeeping is one humanities great inventions and deeply related to conservation laws utility in various other areas. Could not have built my business without having gotten so into this Topic.

Re: Accounting for Computer Scientists (2011)

#59

Post by KolenCh » Sat, Jan 03, 2026, 4:47 PM UTC

amelius wrote: post #12

Those graphs look cool, but I'd prefer a growing log of entries, so you can see what happens over time and more easily roll back or fix things. That's actually what's missing in this presentation: how do you deal with time?

A.k.a. How do you deal with a time dependent network?

Re: Accounting for Computer Scientists (2011)

#60

Post by TuringTest » Sat, Jan 03, 2026, 5:02 PM UTC

skywhopper wrote: post #55

TuringTest wrote: post #52

Earlier quoted context omitted.

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…

[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