Accounting for Computer Scientists

Two observations.<p>First, coming from computer science, introductory accounting - the bookkeeping mechanics - is quite easy. I took a 101 class and was surrounded by future Lords of The Universe who complained about how "hard" it was to add and subtract numbers according to a small system of rules.<p>Accounting is a system of metrics. The system under measurement is your business. Its purpose is to give an accurate readout of business performance. The nice thing is that accountants produce lots of metrics and these can be used to probe the behaviour of different parts of the system.<p>Secondly,<p>&#62; One thing to watch out for: profit doesn’t say anything about your bank account ... That’s why it’s possible for a company to be profitable but still run out of money!<p>This is why accountants produce a third document, the cashflow statement. It shows how cash is coming in and going out. This is different from the P&#38;L statement, which deals with <i>revenues</i> and <i>expenses</i>, both of which may include <i>future</i> events as opposed to actual cash changing hands in the period covered by the report.<p>If there's one thing you <i>absolutely must learn from accounting</i>, it is that positive cashflow and profits are not the same thing. But if you run a business without <i>both</i> of them, that business is doomed.

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

It's always enlightening when someone manages to explain a somewhat complicated subject in terms of an abstraction that the audience understands. This is a great example of that.<p>And it works the other way too.<p>When you've read this article and understood it you wil know how to explain graph theory to an accountant - <i>"see it's actually not that hard, it's just like bookkeeping"</i>

If you have a formal systems bent, as I do, you might enjoy "Algebraic Models for Accounting Systems" (<a href="http://www.amazon.com/Algebraic-Accounting-Systems-Salvador-Rambaud/dp/9814287113" rel="nofollow">http://www.amazon.com/Algebraic-Accounting-Systems-Salvador-...</a>).<p>"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 automata, digraphs, monoids and quotient structures."<p>Think of it as a primer for building yourself an exceedingly awesome and utterly-unnecessary Haskell-based QuickBooks.

Having recently taken an accounting class, this is amazing.<p>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 at this.

<i>If you’re a real accountant reading this, please forgive my simplifications; if you spot any mistakes, please let me know.</i><p>There is one pretty important section of the P&#38;L / Balance Sheet that's missing . . . taxes.<p>On that note, I am hosting a tax workshop on 3/15 @ Hacker Dojo in Mtn. View (very close to YC's office)<p><a href="http://www.transparentaccounting.org/self-employment" rel="nofollow">http://www.transparentaccounting.org/self-employment</a>

David Friedman wrote a very short post 5 years ago on accounting:<p><i>"I have been teaching a new course that includes two weeks explaining accounting to law students. To do so, I first had to understand it myself. I think I now do, and in the hope that the information might be useful to others ... ."</i><p><a href="http://daviddfriedman.blogspot.com/2006/02/understanding-accounting-short-version.html" rel="nofollow">http://daviddfriedman.blogspot.com/2006/02/understanding-acc...</a>

I am not an accountant. That said ...<p>There are a few key pieces of functionality missing from this description, and what (I think) is a really important insight that wasn't really emphasised.<p>Key pieces missing: the hierarchical chart of accounts, and grouped transactions. (You want to be able to find each 'transaction' with Dell, even though one given transaction might include $4000 in depreciable assets, $1000 in extended warranties and other services, shipping, tax... each of which could be a different 'edge' on the graph itself.)<p>And the insight is that it's the edges that count; nodes don't matter -- if you're storing "account" objects with a "balance" property, it ought only to be for caching.

As someone who both 1) checks the comments to see if I should click a link I think might be dodgy, and 2) thinks a lot of links look dodgy, including this one at first, let me give a hearty recommendation to this article. Well worth reading from start to finish.

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.<p><pre><code> amount source target (metadata like date ...) </code></pre> For each account X you get the left and right side with simple SQL queries:<p><pre><code> select * from T where source=X select * from T where target=X </code></pre> 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.<p>While this representation is easy to implement (see ledger, i suppose), it does not lead to pretty graph pictures.

This analogy seems a bit off, and I don't see how it simplifies things.<p>I guess this is similar to the "Monad tutorial" problem, where the author forces a (typically way off) analogy onto the reader.<p>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.

Loved this post. Starts to convince people that Accounting really can be beautiful, in many of the same ways that software can be beautiful. It does tend to get overrun with terminology, edge cases, and other necessary issues given the consequences of ambiguity, but at the lowest level, accounting is just telling a story. Wonderful post!

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

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

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&#38;L. You can possibly borrow against said to cover cash flow, but if asset declines in value, your creditors can demand payment.<p>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.

I think it'd be worth mentioning this is accrual basis accounting. In cash basis you wouldn't write down things which haven't already happened, like the anticipated payment from customer 2.

Tony Bowden described an accounting system built on Semantic Mediawiki in 2006.<p><a href="http://nothing.tmtm.com/tag/finance/" rel="nofollow">http://nothing.tmtm.com/tag/finance/</a>

Interesting. One of the side effects of having the zero sum rule for all transactions means that graphs can be superimposed on each other and also get a valid balance-sheet graph. Cool! Are loops possible? What do they mean?

Anyone willing to recommend a good book that introduces graph theory?

Hard to believe this article didn't contain the word "invariant."

A good effort but all the sign flipping gets confusing

substituting programmer jargon for accounting jargon is the answer?

Nicely done thanks. Much clearer than quickbooks or quicken.

Someone should write one of these for aspiring MPs. I'm pretty certain most modern Western Governments seem to have forgot the basics.

There should be an app for this. A dashboard even.<p>( I mean one that actually displays and lets you edit your books as a graph)

Was a fun read. But you don't have to get complicated.<p>Accounting is just taking notes. No matter how you write then

Check out accountingcoach.com