Accounting for Computer Scientists

— Martin Kleppmann‘s blog

Every educated person really ought to have a basic understanding of accounting.
Just like maths, science, programming, music, literature, history, etc., it’s one of
those things which helps you make sense of the world. Although dealing with
money is not much fun, it’s an unavoidable part of life, so you might as well
take a few minutes to understand it.

Sadly, in my opinion, most accountants do a terrible job of explaining their

work in an accessible way; it’s a field full of jargon, acronyms and weird
historical legacies. Even “Bookkeeping for Dummies” makes my head spin.
Surely this stuff can’t be that difficult?

(We computing people are probably guilty of the same offence of bad
explanations and jargon. The problem is, once you have become intimately
familiar with a field, it’s very hard to imagine how you thought about things
before you understood it.)

Eventually I figured it out: basic accounting is just graph theory. The traditional
ways of representing financial information hide that structure astonishingly
well, but once I had figured out that it was just a graph, it suddenly all made
sense.

I’m a computer scientist, and I think of stuff in graphs all the time. If only
someone had explained it like that in the first place! It would have saved me so
much confusion. So I want to try to fix that. If you like graphs, then by the time
you reach the end of this article, you should know everything you need in order
to understand the financial statements for a small company/startup (and even
calculate them yourself, in a spreadsheet or programming language of your
choice).

It’s really not that hard. Let’s go!

Accounts = Nodes, Transactions = Edges

Say you go to the bagel shop and buy a Super Club bagel for $5 on the
company credit card. You also visit some random Silicon Valley startup and
buy one of their surplus Aeron chairs, second hand, for $500 (by writing a
cheque from the company account). Those are two transactions. Each
transaction is an edge in our graph, and the edge is labelled with the amount.

An edge always goes from one node to another. What are those nodes? Well,
you can define them as you like (although there are some conventions). For
now, let’s say:
Let’s add some more details. You pay the $5 credit card bill from the company
account. And where did the money in the company account come from in the
first place? Ah, I see, you put in $5,000 of your savings to start the company.
Ok, now the graph looks like this:

Hopefully pretty self-explanatory so far. Money flows in the direction of the

arrows.

Hungry once again, you go to the taqueria and buy a Super Burrito for $8 on
the credit card. Now we could create another node for the taqueria, but this is
starting to get messy – we don’t really care how much money we spent on
bagels vs. how much on burritos. Let’s just lump them together as “food”. Also,
“Random startup” is a bit unhelpful – I’ve already forgotten what those $500
were for. Let’s call it “furniture” instead.

See, that’s perfectly fine. We can have nodes which represent actual bank
accounts or cards, others which represent people or companies, and others again
which represent abstract categories like “food” or “furniture”. Just throw it all
into the same graph.

Note also that you can have several edges between the same pair of nodes. You
can keep track of the individual edges, or you can simply add them up. (Using
the credit card, you spent a total of $13 on food.)

Accounts have balances

Every node in this graph is an account in accountant-speak (whether or not it is

held by a bank), and every account has a balance. The balance is a single
number for each account, and it is determined completely by the transactions in
and out of the account:

1. At the beginning of time, the value at each node is zero.

2. At each node, for each incoming edge, add the edge’s label to the node’s
value; for each outgoing edge, subtract the edge’s label from the value.
After you’ve processed all the edges, the value at each node is that account’s
balance. Our graph now looks like this:

Note that the account balances have two nice properties:

1. Because every transaction appears twice – once positive and once

negative – the sum of all account balances is always zero.
2. If you partition the set of nodes into any two disjoint sets, and add up all
of the balances in each set, then the sum for the one set is always the
negative sum of the other set (because, after all, they have to add up to
zero).

These properties are useful for sanity-checking your numbers; if they are
violated, “ur doin it wrong”. (This is what accountants mean when they talk
about “balancing the books”.)

Doing business

Strengthened by a bagel and a burrito, you go out and talk to some potential
customers. And hey, they love your product! It has a price tag of $5,000, and
you sell it to two big enterprise customers. One pays you right away (good
stuff!); the other gives you $2,500 up front, but insists that before they pay the
rest, you need to implement that additional feature you foolishly promised.

So you received $5,000 + $2,500 in cash from your customers, wired straight
the company bank account. Let’s add that to the graph:

But that’s not quite right. The price was $5,000 for each customer, and now it
looks like you charged two different prices. How do we represent our
arrangement with customer 2?
The solution is to deconstruct the deal into two separate transactions: the sale (in
which the buyer agrees to buy, but no actual money changes hands) and the
payment (when the cash actually hits your bank account). We can draw it like
this:

See what I’ve done here? I’ve just made up a new node, generically called it
“sales”, and added the actual $5,000 sales as a transaction from this “sales”
account to the customer accounts. Adding this extra node hasn’t changed your
bank balance.

This makes sense when you think about the intuitive meaning of the balances.
The balance of each customer’s account is the amount they owe you: customer 1
has fully paid up (their incoming and outgoing transactions add up to the same),
so their balance is zero; customer 2 has contractually agreed to give you $5,000,
but has so far only given you half of that, so their balance is $2,500.

And the balance on the sales account is the value of stuff you’ve sold. Or rather,
the negative value. That looks a bit weird… but I’ll come back to that later.
(BTW, if you wanted to separately track sales for different customers or
different products, no problem — just add whatever nodes make sense for you.
Just make sure that every transaction appears only once as an edge, otherwise
you’re making stuff up!)

Finishing off the example

To round it off, let me add some more events to the story (= some more edges
to the graph).

Not only have you made some sales, but now you also receive a $20,000
investment from Y Combinator — congratulations! You and your co-founder
can now afford to pay yourselves a salary. You take $8,000 out of the company
account.

Then you get set up with a company accountant, and they talk lots of jargon at
you. For some strange reason they are obsessed with correctly accounting for
your office chair; they want it to depreciate over four years, i.e. its value is
gradually reduced to zero over the course of that time. Fair enough, you say
(even though you couldn’t care less what your chair will be worth in four years’
time — surely by that time you’ll be the next Google or Facebook, and you’ll
have other things to worry about than chairs).

The resulting graph now looks like this:

Note how I have represented the transactions:

I have lumped together your founder investment with that of Y

Combinator, under the heading of “capital”. Put simply, this is money you
got into the company by selling your company’s shares, rather than by
selling a product or service to a customer. As usual, you can split
founders and YC into separate accounts if you feel like it.

I’ve represented payroll (salaries) as just money straight out of the bank
account. In reality it’s a bit more complicated due to taxes, healthcare,
benefits, etc. but the principles stay the same. It’s just more nodes and
edges in the graph.

I made depreciation for one year (one quarter of $500 = $125) go away
from the “furniture” account. Intuitively, this means that the balance of the
“furniture” account is the value that your furniture still has now. Each
year, you add another $125 edge from “furniture” to “depreciation”, until
after four years, the balance of “furniture” drops to zero (assuming you
haven’t bought any more chairs in the meantime, in your quest for world
domination).

The profit and loss statement

At this point, if you’re getting weary, I don’t blame you. But the good news:
we’ve finished building our graph! Now I will show you how this graph
representation maps to two standard financial statements most commonly used
in managing a company: the profit and loss statement (“P&L”), and the balance
sheet. This is useful, because as a startup founder you’ll sooner or later have to
discuss these documents with your investors/advisors, and so you might as well
learn what the hell they mean.

In order to produce these statements, I need to get out the crayons. Here is the
same graph as before, with the nodes coloured in:
Explaining the colours (putting the accounting terminology in brackets, since
you’re likely to encounter these words):

Green for stuff that you have (“assets”), e.g. money in the bank, or
things which you bought and you could sell again, such as furniture.
Also green for people/companies who owe you money (“debtors”, such
as Customer 2), and people/companies to whom you owe money
(“liabilities”/”creditors”, such as your upcoming credit card bill for that
burrito).
Blue for sales of your product/service (“revenue”) and money you
spent that you’re not going to get back (“expenses”/”overheads”). The
office chair is green, because you could sell it again if you wanted to, but
the bagel is blue, because once you’ve bought (and eaten) the bagel, that’s
it – no going back.
Pink for money from investors (or yourself) that you got by selling
shares (“capital”). (If you get a bank loan, that’s green, not pink, because
you owe the bank to pay it back.)

Every one of your nodes should fall into exactly one of these categories. If not,
something has gone wrong, or you have discovered some bit of the accounting
world that I don’t yet know about.

With these colours set, the profit and loss statement is simply a list of all the
blue nodes, and the profit or loss of the company is the sum of all of the blue
nodes’ balances. The way we’ve calculated things, a negative value is a profit,
and a positive value is a loss. That’s confusing, so you typically flip the sign
when reporting the number (so that a profit is positive).

Written in the standard way, our P&L looks like this:

Sales $10,000
Revenue
Total revenue $10,000
Payroll $8,000
Depreciation $125
Expenses
Food $13
Total expenses $8,138
Total Profit/Loss $1,862 (= total revenue - total expenses)
The meaning is fairly intuitive. You sold $10,000 worth of stuff, and spent only
$8,138 in the process, so you made $1,862 profit.

The profit and loss statement is calculated over a period of time (usually a
month, a quarter or a year), and it’s often interesting to compare two different
periods. To calculate it for a period, filter your transactions to only include those
which occurred within that period, and add up the account balances for just
those transactions.

One thing to watch out for: profit doesn’t say anything about your bank
account. The bank account is a green node, but we’re only looking at blue nodes
here. In this example, you ended up with $23,995 in the bank, even though
investors put in $25,000: you made a profit, yet still have less money in the
bank than you did before, because Customer 2 hasn’t yet fully paid. That’s why
it’s possible for a company to be profitable but still run out of money!

The Balance Sheet

The balance sheet is a bit less intuitive than the P&L, but it’s quite a powerful
document. It summarises what the company currently has and doesn’t have, and
why.

Remember what I said earlier about partitioning the nodes into two disjoint sets,
and their summed balances adding to zero? That’s exactly what happens on the
balance sheet. We take all of the nodes in the graph; on the one side we consider
all of the green nodes, and on the other side all the blue and pink nodes. The
sum of all of the blue and pink nodes’ balances is minus the sum of all of the
green nodes’ balances.

Now, by convention, accountants flip the sign on all of the blue and pink nodes’
balances, which means that the two sums end up being equal. And that’s why
it’s called a balance sheet.

In our example, it looks like this:

Bank account $23,995

Debtors $2,500
Assets
Furniture $375
Total assets $26,870
Credit card $8
Liabilities
Total liabilities $8
Total assets less total liabilities $26,862
Profit/Loss $1,862
Equity Capital $25,000
Total equity $26,862
The top block (assets and liabilities) corresponds to the green nodes in the
graph, whilst the bottom block contains the pink node (capital) and the sum of
all of the blue nodes. We already showed all of the detail for the blue nodes on
the Profit and Loss statement above; on the balance sheet we can sum them all
up to a single number.

Some more sign-flipping has occurred here: I’ve written liabilities, equity and
P&L with their signs flipped (which usually, but not always, has the effect of
making the numbers positive). That doesn’t change anything fundamental about
the graph structure, it just puts things into the conventional schema.

So how can you interpret the balance sheet? There are various things you can
read from it. You can see how much money is in the bank, and how much of
that money has already been promised to other people (liabilities). You can see
how much of the money in the bank came from investors, vs. how much came
from sales. And it shows how much money is due to come in soon, from sales
that have closed but haven’t yet been fully paid.

The total of the balance sheet is a lower bound on the value of your company.
It’s a very pessimistic figure — it assumes that your team, your technology,
your brand etc. are all worth precisely nothing; if your company raises money
from investors, your valuation will be much higher than the balance sheet
figure, since that valuation includes the value of team, technology, brand etc in
the form of a wild guess. In established companies you can find “intangible
assets” on the balance sheet, but since they are very hard to value, I suspect it’s
not worth bothering with unless you know what you are doing.

That’s the end of our whirlwind tour through the world of accounting. If you’re
a real accountant reading this, please forgive my simplifications; if you spot any
mistakes, please let me know. For everyone else, I hope this has been useful. To
find out when I write something new, please follow me on Twitter or put your
email address in this box:

I won't give your address to anyone else, won't send you any spam, and you
can unsubscribe at any time.
Excerpted from Accounting for Computer Scientists — Martin Kleppmann‘s blog
http://martin.kleppmann.com/2011/03/07/accounting-for-computer-scientists.html#

READABILITY — An Arc90 Laboratory Experiment http://lab.arc90.com

/experiments/readability