Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Accounting for Computer Scientists

martin.kleppmann.com

Post reply on HN
Print view View original

61–70 of 79 posts

Re: Accounting for Computer Scientists

#61

Post by beza1e1 »

For a programmer I'd rather explain it in database terms. It's a single table T, which basically contains the edges of Kleppmann's graphs.

  amount  source  target  (metadata like date ...)
For each account X you get the left and right side with simple SQL queries:

  select * from T where source=X
  select * from T where target=X
All the other mumbo-jumbo about double-entry bookkeeping is implicitly baked in. For example, "The double-entry bookkeeping system ensures that the financial transaction has equal and opposite effects in two different accounts." Of course, each entry subtracts amount from the source and adds it to target.

While this representation is easy to implement (see ledger, i suppose), it does not lead to pretty graph pictures.

Re: Accounting for Computer Scientists

#62

Post by drindox »

Vivtek wrote: post #32
mordero wrote: post #25

Earlier quoted context omitted.

It's not actually a liability; it's an account with a credit balance. Sales flows into retained earnings which is an equity account, which has a credit balance per the accounting equation of Assets (Debit balances) = Liabilities + Equity (Credit balances).

I think the rules may differ in Europe (the way things are classified) - but the insight I had was that something that seems clearly to be an asset to my naive view (sales) can actually be a sort of accounting fiction to make the balances come up right, and thus be shown as a liability. Without checking my notes on a specific translation I did about 15 months ago, I don't even remember if it was sales or not. (I have…

I think the rules may differ in Europe (the way things are classified)

Nope. Sales is NOT a liability, and there is no accounting fiction. Sales are also not an asset. They are an income. The money earned from the sale is the asset. I think you may be confusing ledger credits with liabilities.

All credits are not increases in liabilities, but all increases in liabilities are credits.

Good background on Wikipedia: [ http://en.wikipedia.org/wiki/Debits_and_credits ] [ http://en.wikipedia.org/wiki/Double-entry_accounting_system ] [ http://en.wikipedia.org/wiki/Accounting_equation ]

Re: Accounting for Computer Scientists

#63

Post by follower »

nas wrote: post #51
gnosis wrote: post #31

Earlier quoted context omitted.

How does ledger compare to gnucash?

Quite different, basically no gui. I like ledger better. I have my personal and two different business accounts using ledger. I use git to VC the data files. I've done quite a bit of scripting to make the system more convenient (automate billing, tracking inventory, converting between cash-based and accrual reporting). Ledger is really quite simple. The core of it could be implemented pretty easily (witness the numbe…

> It's crude otherwise I would release code.

Everything starts out crude--release it anyway! Seriously.

Re: Accounting for Computer Scientists

#64

Post by Alexon »

Vivtek wrote: post #5

OH MY GOD! I finally understand why Sales is a liability on all the balance sheets I translate! !!!

OH MY GOD! I finally understand why Sales is a liability

And expenses are an asset? Your comment got 9 upvotes, which would indicate either that I am either missing your sarcasm, or notwithstanding the article, many hackers still don't get accounting.

Re: Accounting for Computer Scientists

#65

Post by vdm »

jcromartie wrote: post #6

Having recently taken an accounting class, this is amazing. The course I took was chock full of "because that's the way it is" explanations of terms and practices, which without fail left me feeling confused and unsatisfied. I think most people here are like me and really need deep explanations of the lower level concepts in order to be able to apply higher level concepts. Accounting coursework is absolutely horrible…

"Because that's the way it is" describes my entire mathematics education. It didn't work for me, and I can't help but think there has to be a better way.

Re: Accounting for Computer Scientists

#68

Post by praptak »

cwp wrote: post #30
zdw wrote: post #8

Earlier quoted context omitted.

I wish I could vote this up twice. Ledger is awesome and strips away all the crap that gets in the way of actually seeing the data. There are also haskell and python implementations out there if that's more up your hacking alley.

My favourite feature is this: like the article, ledger completely ignores any the concept of debits and credits. Negative numbers FTW!

I find this strange. Last time I had some interaction with a ledger negative credit and positive debit were different beasts. Granted, their contribution towards the balance was the same, nevertheless they were different things.

In particular a correction of an erroneous debit entry was stored as a negative debit, not positive credit. Representing both with the same number seems a bit suspicious to me.

Re: Accounting for Computer Scientists

#70

Post by eru »

jerf wrote: post #9
lenary wrote: post #2

This i found very enlightening to read. I wonder how many accounting apps actually store their data as he describes in this article, to aid their calculations

There are some further complications that make it impossible to use that exact representation without change; for instance a single transaction may involve more than two nodes; you could buy furniture and computers in one transaction and something in the system needs to represent this was one purchase, even if it is further broken apart after that. But with suitable modifications it seems like this ought to work. Whe…

Accounting programs already employ such directed, weighted hypergraphs. They are just not storing pretty pictures, but the incidence matrix.

The programmers probably don't think of their tables as an incidence matrix though, and end up coding lots of special cases, instead of re-using general graph algorithms.

Post reply on HN