Live data from Hacker News

Accounting for Computer Scientists

martin.kleppmann.com

51–60 of 79 posts

Re: Accounting for Computer Scientists

#51
post #31
post #4

"User-friendly" accounting software (such as QuickBooks) tends to obscure the fundamental simplicity of double-entry accounting. If you want to actually understand your books, use something simple and powerful like John Wiegley's ledger: https://github.com/jwiegley/ledger/

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 number of "ledger" clones). I have my own somewhat compatible ledger program written in Python. It's crude otherwise I would release code.

Re: Accounting for Computer Scientists

#52

If you have a formal systems bent, as I do, you might enjoy "Algebraic Models for Accounting Systems" ( http://www.amazon.com/Algebraic-Accounting-Systems-Salvador-... ). "This book describes the construction of algebraic models which represent the operations of the double entry accounting system. It gives a novel, comprehensive, proof based treatment of the topic, using such concepts from abstract algebra as automat…

OK, that sounds pretty amazing, but is it as good as it sounds? For example, Leon Sterling wrote a 400 page book that included a crappy unrealistic example of how to write a Tamagotchi program. http://www.amazon.com/dp/0262013118 Funny, considering Luca Cardelli's paper about biologist's fixing tamagotchi's.

Re: Accounting for Computer Scientists

#53
post #50
post #39

Earlier quoted context omitted.

I agree with observations and comments. Well you can live without profits for sometime, if you run out of working cash, your stuffed. This is why loans, and factoring come in and is why even profitable business require loans because of bad cashflow. One easy way to try avoid this, is to always try to get in flow payments coming in faster, and outgoings slower. Even if the net total is the same in end, it allows more…

Most of the hard problems are to do with depreciation, and the legalities of how you classify them. For example, Police departments have dogs. Dogs are assets. If all government departments are told to use accrual (rather than cashflow), they need to depreciate assets. So the account needs to figure out how dogs depreciate. Should you assume that a dog has a useful life of 10 years, and loses 10% of its initial value…

> Most of the hard problems are to do with depreciation, and the legalities of how you classify them.

I would generalise that to say that all the hard problems in accounting are ones of classification.

Does sale X fall in 2010 or 2011?

Do we book the inventory when we order it, when it is delivered to our warehouse, when it is delivered to our shop, or all three? And if we use some combo, how do we combine them in LIFO calculations?

We've just donated $100,000 to Fashionable Cause, a charitable foundation founded by Irish rockstar Nobo and in exchange he will wear our platform shoes exclusively. Do we book this under philanthropy or marketing? If philanthropy, do we consider it part of the overhead cost for the shoes sold?

And so on and so on.

Most of the big bucks in accounting comes from coming up for clever excuses as to why something should be categorised in a certain way.

Re: Accounting for Computer Scientists

#58
Accounting gets interesting when you get derivatives and the fed involved. You own a volatile asset, so the price can go up and down, everyday. However, you don't necessarily know how much said asset is worth. So, you have no P&L. You can possibly borrow against said to cover cash flow, but if asset declines in value, your creditors can demand payment.

Furthermore, your balance sheet can look great. However, if your debtors go bankrupt, a solid balance sheet can quickly deteriorate. If your customers pay late, and you can't borrow money, the delicate balance can collapse.

Re: Accounting for Computer Scientists

#59
This analogy seems a bit off, and I don't see how it simplifies things.

I guess this is similar to the "Monad tutorial" problem, where the author forces a (typically way off) analogy onto the reader.

One concrete problem with "accounting as graphs" is that a transaction typically involves more than two legs, while Graph edges are ALWAYS associated with exactly two nodes. You can emulate this, of course, and the author hints as much in his description of complex "deals", but it raises the question whether graphs are the best analogy.

Post reply on HN