
Accounting for Computer Scientists - martinkl
http://martin.kleppmann.com/2011/03/07/accounting-for-computer-scientists.html
======
jacques_chester
Two observations.

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.

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.

Secondly,

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

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&L
statement, which deals with _revenues_ and _expenses_ , both of which may
include _future_ events as opposed to actual cash changing hands in the period
covered by the report.

If there's one thing you _absolutely must learn from accounting_ , it is that
positive cashflow and profits are not the same thing. But if you run a
business without _both_ of them, that business is doomed.

~~~
al05
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 flexibility with cash flow.

Accounting is obvious to me, but we probably haven't encountered the hard
problems yet.

~~~
wisty
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 every
year? Or that it exponentially decays, as it gets older and less able to sniff
bad guys? Or should it only be 5 years? What do you do if a dog ends up
working long past its expiry date?

It can be tricky to come up with sensible numbers. Especially when accountants
don't have domain knowledge, and people who do don't like speaking to them.

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

------
tc
"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/>

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

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

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

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

And it works the other way too.

When you've read this article and understood it you wil know how to explain
graph theory to an accountant - _"see it's actually not that hard, it's just
like bookkeeping"_

------
seanstickle
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-...](http://www.amazon.com/Algebraic-Accounting-Systems-Salvador-
Rambaud/dp/9814287113)).

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

Think of it as a primer for building yourself an exceedingly awesome and
utterly-unnecessary Haskell-based QuickBooks.

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

------
jcromartie
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 at this.

~~~
Duff
Accounting courses are horrific, but in fairness they try to get you up to
speed on the basics before diving into the detail.

A typical CSI 101 course is often like this -- you learn about operators, etc
without understanding how things actually work until later.

~~~
johnzabroski
I had really great accounting professors, who explained WHY things were done.

As with anything else, assume a normal distribution of teaching talent, and
hope you end up being taught by somebody on the right side of the curve.

------
shawnee_
_If you’re a real accountant reading this, please forgive my simplifications;
if you spot any mistakes, please let me know._

There is one pretty important section of the P&L / Balance Sheet that's
missing . . . taxes.

On that note, I am hosting a tax workshop on 3/15 @ Hacker Dojo in Mtn. View
(very close to YC's office)

<http://www.transparentaccounting.org/self-employment>

~~~
dreyfiz
Please make a recording available more widely afterwards, for those of us who
can't attend. I'd pay the same amount you're suggesting as an in-person
donation for this, if it comes to that.

------
billswift
David Friedman wrote a very short post 5 years ago on accounting:

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

[http://daviddfriedman.blogspot.com/2006/02/understanding-
acc...](http://daviddfriedman.blogspot.com/2006/02/understanding-accounting-
short-version.html)

------
crux_
I am not an accountant. That said ...

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.

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

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.

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

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

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

------
farnja
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!

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

~~~
mordero
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).

~~~
Vivtek
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 computers so I don't have to remember
things, obviously, ha.)

~~~
drindox
_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> ]

~~~
Vivtek
Ah - finally I found the balance sheets I was thinking of (some Deutsche Bank
stuff from 2009). Turns out I was misremembering; it was equity capital that
falls under liabilities, which is counterintuitive to me. Capital is, after
all, something I have - but I suppose since it's an investment, it represents
something I owe.

And I see capital is shown in the balance sheet in the original post as well -
but what struck me as counterintuitive in the original post is representing
sales as, effectively, a cash flow towards the customers. If not a fiction,
surely you have to grant it's an abstraction.

~~~
drindox
Equity is on the _same side_ of the balance sheet as liabilities because of
the accounting equation: Assets = Capital + Liabilities.

See this tutorial as well:
<http://www.principlesofaccounting.com/chapter%201.htm>

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

~~~
jerf
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. Whether or not it is actually done this way, I
don't know... and to be honest, I doubt it, filed under "I don't need all that
theory crap, I've got problems to solve!". Programmers are often quite happy
to write much more complicated and redundant programs if it means not having
to learn about graph theory. Not that they think of it that way. And I find it
unlikely anybody started a real accounting project with "First, let's learn
all about accounting and strip it down to the minimal conceptual core", rather
than "Our accountants say this is how it works, so let's start putting
together the matching class hierarchy", which will not produce a clean graph
structure where one did not previously exist.

(And yes, theory can't be perfectly followed either, all systems will
generally need some amount of dirty things, but the correct balance IMHO is
definitely not 100% "pragmatic".)

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

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

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

------
vdm
Tony Bowden described an accounting system built on Semantic Mediawiki in
2006.

<http://nothing.tmtm.com/tag/finance/>

------
archgoon
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?

~~~
jpadkins
loops represent the economy. Other than new currency from the Federal Reserve
or Treasury, or physical dollar media being destroyed, its a closed loop
system.

~~~
sethg
The “new currency” exception is very significant, because under our
fractional-reserve banking system, banks have the power to create money.

If you deposit $100 in a bank, the bank can immediately loan out $90 of it to
borrowers (who may put that money in their own banks, etc. etc.), thus
creating money from nowhere. I.e., if those borrowers can’t pay back their
loan and the bank writes it off, your $100 is still safe.

~~~
ubasu
I thought fractional reserve meant that the bank can now loan out _$900_ ,
which is the creating money part. (perhaps you had a typo?)

~~~
cwp
No, they only loan out $90. But that is creating money. Where did that $90
come from? It didn't come out of your account; you still have $100. Imagine
how pissed you'd be if you went to make a withdrawal and the bank said, "no,
you can only have $10 right now, we lent the rest to somebody and they haven't
paid it back yet."

~~~
bigiain
The $900 figure comes from the assumption that the $90 they lend out
eventually lands in somebody else's account, and they then also lend out 90%
of that $90, and then recurse that all the way down till there's nothing left
to lend out again:

perl -e'$s = 100; while($s > 0.1){$t = $t + $s * 0.9;$s = $s * 0.9;} print $t'

899.140495544283

(edited: I have no idea why HN dropped out the asterixes in that code...)

~~~
prodigal_erik
Asterisks without whitespace (or a leading indent) mean italics:
<http://news.ycombinator.com/formatdoc>

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

~~~
praptak
The wikipedia page on graphs contains much more material than it is needed to
understand the article.

------
drindox
A good effort but all the sign flipping gets confusing

------
rsl
substituting programmer jargon for accounting jargon is the answer?

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

------
mikecarlton
Nicely done thanks. Much clearer than quickbooks or quicken.

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

------
Tycho
There should be an app for this. A dashboard even.

( I mean one that actually displays and lets you edit your books as a graph)

------
gcb
Was a fun read. But you don't have to get complicated.

Accounting is just taking notes. No matter how you write then

------
bakintunde
Check out accountingcoach.com

