
Accounting for Developers - petethomas
https://docs.google.com/document/d/1HDLRa6vKpclO1JtxbGB5NeAYWf8cf1UMGy22o8OZZq4
======
jasim
Debit is Yin and Credit is Yang. When you receive salary as cash, you record
it as a tuple:

    
    
    		Yin: Cash Account
    		Yang: Salary Account
    	        (amount: $salary)
    

When you spend from that cash, you record it as this tuple:

    
    
    		Yin: Dinner Expense
    		Yang: Cash Account
    		(amount: $bill_amount)
    

If you get your salary through cheque, it looks like this:

    
    
    		Yin: The Bank Account
    		Yang: Salary Account
    

When you borrow:

    
    
    		Yin: Cash Account
    		Yang: The Creditor Friend
    

And vice versa when you pay it back.

Now replace Yin with Debit and Yang with Credit, and that's mostly it.

~~~
filearts
I think that the major challenge in understanding debits and credits is that
different accounts have different 'signs' that may seem counter-intuitive.

For example, if you earn money (get revenue) this is something that you would
typically consider 'positive', however revenue is a credit account and so the
earning of revenue is actually a credit.

A simple trick is to recognize that balance sheet accounts have signs that
align with our intuitive understanding of positive and negative, whereas
income statement accounts are flipped. To grok why that is gets a little more
tricky and the linked article seems to give a great basis for understanding
that.

Source: I'm a Canadian CPA, CA (and CBV) and soon-to-be software engineer. I
think this helps understand both perspectives.

~~~
dragonwriter
> A simple trick is to recognize that balance sheet accounts have signs that
> align with our intuitive understanding of positive and negative, whereas
> income statement accounts are flipped. To grok why that is gets a little
> more tricky

For me, what made this less tricky, was thinking in terms of flows and their
accumulation. A debit entry is a flow of value into an account, a credit entry
is a flow of value out of an account (a debit or credit balance is simply an
accumulation of those flows.)

------
bcoates
As a former bookkeeper, I should mention that this is technically bookkeeping,
not accounting, which vaguely corresponds to the difference between
computation and programming.

That said, this is very dangerous knowledge; once bookkeeping makes sense like
this you will constantly have to resist the urge to yell at people who claim
"expenditure X really shouldn't count because it has benefit Y", which is a
disturbingly common belief among otherwise smart people.

~~~
camz
I wouldn't try to separate bookkeeping from accounting too much. As a cpa, the
lines are blurred too often because we're usually making decisions and
adjustments along the way.

But, a little information can definitely be dangerous. It can be a huge time
sink to "restate" the books to suit someone's vision and at worst it allows
people to misrepresent the information.

~~~
jasode
>I wouldn't try to separate bookkeeping from accounting too much.

I think of them as distinct and separate concepts:

 _bookkeeping_ : the recordkeeping of transactions. The "data entry". You can
have lower wage data entry clerks tearing open envelopes to type in data from
vendors' invoices and recording deposits of checks from customers. At this
layer, the data needs to be recorded correctly.

 _accounting_ : literally the management of "accounts". This is a position of
education (CPAs). Their value-added thinking happens above the layer of
bookkeeping. They use professional judgement to set up a "chart of accounts"
... what kind of buckets to keep track of various money, how many buckets,
etc. They are in charge of "closing the books" each month and preparing
financial reports.

Yes, sometimes the activities blend into each other. Some bookkeepers do
higher level "accounting" activities and some Certified Public Accountants
also do grunt work of "bookkeeping" but they're still separate cognitive
activities.

Lastly, there's _finance_. The finance layer sits above accounting and
bookkeeping. Finance management (CFO, treasurer, etc) focuses on strategy of
money. Should the company lease or buy the building, the tax implications of
foreign earnings, stock buybacks, etc. The accountants & bookkeepers can
_report_ exactly how much money is sitting in the bank but they are not the
ones who _decide_ what the best strategy is for it.

It's the small businesses where "bookkeeping" and "accounting" are synonymous
(e.g. using Intuit QuickBooks). In those mom & pop shops, the "finance"
strategy is handled by the owner(s) of the company.

~~~
sundarurfriend
From your description, it sounds like bookkeeper:accountant as DB-user:DB-
admin - the accountant/admin defines the schema, and the bookkeeper/user only
gets to work at the data level, with no metadata level decisions. Is this
analogy sound?

~~~
jasode
That can be a loose analogy if one is using the perspective of _job titles_.

I was emphasizing the different "cognitive activity" of each instead of job
titles. As for workers' positions/roles, that's more fluid.

For example, in the small company[1], the "bookkeeper" is also doing the
"accounting tasks".

In this other larger company[2], the "bookkeeper" is more of a data-entry
person and reports to the CPA.

[1] [http://jobview.monster.com/Bookkeeper-Job-Palm-Bay-FL-
US-151...](http://jobview.monster.com/Bookkeeper-Job-Palm-Bay-FL-
US-151281639.aspx?mescoid=4300700001001&jobPosition=5)

[2] [http://jobview.monster.com/Bookkeeper-Logistics-Firm-Job-
New...](http://jobview.monster.com/Bookkeeper-Logistics-Firm-Job-New-York-NY-
US-151267610.aspx?mescoid=4300700001001&jobPosition=14)

------
calpaterson
I think it's great that someone is trying to teach this topic to software
engineers and I accept that it's hard to teach but I think that this document
doesn't do a good job. Covering the "balancing" of debits and credits as the
starting point is too abstract.

GNUCash's (which I use for my personal accounts) guide is unhelpfully down
right now, but you can find it here:

[http://www.gnucash.org/docs/v2.4/C/gnucash-
guide/](http://www.gnucash.org/docs/v2.4/C/gnucash-guide/)

I also found Accounting Demystified very useful:

[http://www.amazon.co.uk/Accounts-Demystified-
Astonishingly-S...](http://www.amazon.co.uk/Accounts-Demystified-
Astonishingly-Simple-Accounting/dp/0273744704/)

~~~
nbouscal
The post basically read like a summary of the first class in my accounting
degree. I would be very surprised if the average software engineer has _less_
tolerance for abstraction than the average accountant.

Debits and credits are the foundation on which all of accounting is built. I
don't see why you would start anywhere else.

~~~
calpaterson
When you consider how many people leave "Accounting 101" classes without
really understanding anything the traditional way starts to look quite bad

~~~
tmornini_ey
Good point.

Do you know or believe it to be higher than most other classes?

------
buyx
I did accounting (actually bookkeeping) in high school, as did almost all my
school-mates, and it is a very useful skill to have. From understanding debit
and credit on a bank statement, to being able to read a balance sheet,
accounting is a powerful tool in day-to-day life. South Africa has a bit of an
accounting fetish (Chartered Accountants are the gods of the business world
here), but it certainly is useful to know the rudiments.

We hear about coding being the "new literacy". I am sceptical, but if coding
is the "new literacy" then basic accounting knowledge is equally important, in
my opinion.

~~~
tmornini_ey
I agree 100%.

Cannot imagine a more valuable high school class than basic accounting.

I guess you'd agree with us that building any software that handles money
should, by definition, use accounting to do so?

------
cbhl
One simplistic definition of 'debit' and 'credit' that my accounting teacher
taught me:

'debit' means 'left', 'credit' means 'right'

Then, you just make sure that SUM('left') == SUM('right').

~~~
frivoal
That's the easiest way to deal with it. If you can remember that (which is not
hard), and where one type of account falls on the left/right spectrum (which
isn't hard either, pick whichever you like), then you can figure out the rest.

Until you're used to these two words and they speak for themselves, assigning
any other meaning tends to lead to more confusion than anything else.

~~~
kinleyd
I dropped accounting in my 10th grade largely because I made the mistake of
trying to get into the "meaning" of debit and credit. Mnay wasted hours there.

Finally in grad school I got it - left and right - and accounting has never
been a problem again.

------
atmosx
Truth to be told, going by the title I was expecting a sort of handbook for
something like ledger[1].

[1] [http://www.ledger-cli.org](http://www.ledger-cli.org)

~~~
Fiahil
I started going through ledger recently (after a fructuous discovery in a HN
comment), and it's truly a great tool with a great documentation for someone
not used to accounting!

------
hrjet
> From a mathematical perspective, abnormal balances are essentially negative
> balances, though in accounting negative numbers should never be used or
> allowed.

This seems like a bad legacy passed down unwittingly. I am not trained in
accounting, but been keeping my books for several years now. I have written a
ledger-cli clone and have been using it for the last three years for both
personal and company accounts. Using signed numbers works perfectly fine
during book keeping. I use the Debit/Credit lingo only when I need to show
reports to the pesky accountants. (Fortunately, my main accountant doesn't
bother me with formalities).

~~~
clarkevans
Bookkeeping uses a different reasoning system than you are accustom. I think
of it as vectors in a 2-dimensional space (asset/liability, income/expense) --
where each vector has a magnitude and a direction (debit/credit). You can
think of "debit" being the head of the vector (where value is going), and the
"credit" as being the tail (where it comes from). Transactions are paired,
complementary movements in this space -- not plus/minus movement along a
single line.

Visually, it's much easier to distinguish between a debit and a credit if they
are in different columns. A tiny little minus sign won't do it. Of course, you
could use color, but, that's not always printable. Parenthesis are OK, but, it
makes sanity checks in your head difficult. Of course you could do this
transformation a report if you wanted, but really, how often does that happen?

Logically, these are actually very different activities. When you debit an
asset account, it's representing a kind-of-activity that happens (retained
value accumulating). Once you view credit/debit as just plus/minus, you're
tempted to neglect the other dimensions of the interaction. To a beginner,
debit/credit affect on asset/liability/expense/income accounts seem like an
unnecessary distiction, however, the interactions are inverted in their
affect. Is minus good or bad? It completely depends upon your perspective.

Redundancy is a feature not a defect; it's a checksum. There's always a
tendency to simplify the model and elminate the balancing interaction and
check. This is possible, of course, and it does simplify the recordkeeping.
However, it means that logical classification errors are harder to discover.
When (perhaps big) money is at stake, why take the risk? By having 2
complementary transitions in a more complex space, you cause the person making
the entry to think... and that's very useful (even if it's tedious or
exhausting).

Pratically, you have convention/tradition. You're making a choice to use
plus/minus for credit/debit is one of the distinctions, you could just have
easily use it for asset/liability or income/expense. Why favor credit/debit?
While this may not be the best way to solve these concerns, the approach is
the incumbant -- most financial people expect this kind of problem to be this
way, regardless of the extra complexity involved. Tradition here reduces
communication overhead.

Even so, the rules arn't passed down unwittingly, they form an approach known
to work. I think each generation is welcome to challenge (and they often do
challenge) tradition, however, new approaches need significant justification.

~~~
dragonwriter
> Transactions are paired, complementary movements in this space -- not
> plus/minus movement along a single line.

Sure, _transactions_ are pairs (or balanced sets) of entries. _Entries_
however, are exactly plus/minus movements along a single line in a single
account. Sign (+/-) reflects that much better than debit/credit labeling does.

> There's always a tendency to simplify the model and elminate the balancing
> interaction and check.

Using +/\- in place of credit/debit does not eliminate the balancing
interaction. In fact, it makes exactly what is done in the balancing
interaction more explicit.

> You're making a choice to use plus/minus for credit/debit is one of the
> distinctions, you could just have easily use it for asset/liability or
> income/expense. Why favor credit/debit?

Because income, expense, asset, and liability, are all kinds of accounts, and
credit and debit are not, they are descriptors of whether an entry (or
balance) is a flow (or accumulation of flow) of value into (debit) or out of
(credit) an account.

~~~
tmornini_ey
+\\- doesn't represent it better, it represents it identically...in modern
terms.

~~~
dragonwriter
For a modern audience, o think that makes it better. Communication isn't
independent of the audience.

------
seanstickle
One of my favorite books is "Algebraic Models For Accounting Systems" \--
[http://www.amazon.com/Algebraic-Models-For-Accounting-
System...](http://www.amazon.com/Algebraic-Models-For-Accounting-
Systems/dp/9814287113)

Fundamentally this book is about the application of abstract algebra to the
analysis of accounting systems.

Add in APL or J (or Haskell if you must) by way of "Algebra: An Algorithmic
Treatment" ([http://www.amazon.com/Algebra-algorithmic-treatment-
Kenneth-...](http://www.amazon.com/Algebra-algorithmic-treatment-Kenneth-
Iverson/dp/B0006WTFW6)), and you build a quite rigorous proof-based accounting
system.

~~~
boothead
Thanks for the recommendation. If it wasn't $73 I'd definitely grab a copy.
Why is Haskell "if you must" though? Are the others better at expressing code
algebraically?

~~~
seanstickle
Mostly because I'm an APL snob. Haskell is great.

------
camz
I always appreciate new ways to make accounting easier. A lot of accounting
should be automated because most of it is ministerial.

But, I do thinking that financials are something that each person should learn
a bit more about. I find it too common that people aren't spending enough time
to understand what their financials are trying to tell them. For example,
they're generate awesome revenues, but failing to convert it into cash fast
enough to meet their debts (statement of cash flows).

Always a fan of everyone gaining financial literacy =).

~~~
Pamar
Can you suggest some light reading on this?

~~~
eru
[https://martin.kleppmann.com/2011/03/07/accounting-for-
compu...](https://martin.kleppmann.com/2011/03/07/accounting-for-computer-
scientists.html) is a good introduction.

~~~
haberman
This blog post changed the way I think about accounting in a deep and powerful
way.

~~~
buyx
I found that article to be rather obtuse and very complicated (I think it was
an intellectual exercise rather than a primer), but that's my personal
opinion. Definitely not the "light reading" GP wanted. A useful primer would,
in my opinion, start with the accounting equation, explaining its components,
and move on from there.

~~~
tmornini_ey
Is "that article" our primer of the Martin Kleppmann piece?

~~~
buyx
I was referring to the Martin Kleppmanm piece on "Accounting for Conputer
Scientists". It seems like it was meant as an exercise in mapping accounting
to graph theory, but somehow morphed into a go-to tutorial for accounting.

Looking at the comments on that website, it has even developed a sort of
fanboyism. But IIRC, it led to some "interesting" insights when it was first
discussed on HN, like "sales are liabilities".

I find the alleged impenetrability of basic accounting to be rather baffling
in general.

~~~
tmornini_ey
Thanks, happy you were not referring to our document! :-)

Sales (Incomes) are clearly equity, with Expenses being contra-equity. Not
sure how anyone could come to any other conclusion, but I'll read the article
and it'll probably become clear. :-)

------
satyanash
I've always understood it using the 'source' and 'destination' analogy that
many unix tools follow.

Credit is the source while debit is the destination.

Using the source and destination keywords has the advantage of not implying
the actual operation to be performed. For eg. credit results in an 'add'
operation on an expense account while a 'subtract' operation on an asset
account.

~~~
tmornini_ey
Yes, in the article we describe this as from/to. :-)

------
arihant
Another great resource is Financial Intelligence for Entrepreneurs:

[http://www.amazon.com/Financial-Intelligence-
Entrepreneurs-R...](http://www.amazon.com/Financial-Intelligence-
Entrepreneurs-Really-Numbers/dp/1422119157)

So far is the only book I know that explains _why_ and not just _what_.

------
Dowwie
This is as good a place as any to mention that this double-entry bookkeeping
process, a centuries-old methodology, is long overdue for replacement (but
changing a global standard like this may never come to pass). In the early
1980s, an academic known as William McCarthy presented one such alternative
known as REA, which organizes accounting into a resources-events-agents model.
A little while ago, I asked Mr. McCarthy whether REA was dead and he claimed
that it in fact wasn't dead and that work was still ongoing.

The thing is, since as early as the 1960s, there has been discussion and
publications about event-driven accounting architecture. Pretty crazy, right?

Alas, considering IFRS and GAAP span the world's modern economies, it may be
safe to assume that hell will freeze over before any viable accounting
alternative to double-entry bookkeeping supplants it.

~~~
tim333
I doubt double-entry book keeping will be replaced but there are many
opportunities to build on it. GAAP earnings can give you results that are
completely out of sync with whether a business is making it's owners richer or
not which is what counts at the end of the day.

~~~
throwaway_97
Wasn't GAAP replaced long time ago?

------
mikekchar
I don't know why, but when I read the introduction to this I suddenly thought,
"Hey my production code/tests is a double entry programming system".

------
jldugger
Bookkeeping wasn't super hard to figure out when I started using GNUCash in
grad school. Really the most painful part was importing history from shitty
local bank records.

~~~
calpaterson
I don't import history from my bank - I find manual reconciliation fairly
quick and quite useful - but I share your pain with dealing with banks. QIF is
a useless format for double entry systems.

~~~
jldugger
GNUCash lets you do separate import and reconciliation steps. The problem was
the bank didn't support OFX. Or maybe even QIF, it was a long time ago and I
was naieve.

------
known
Check
[http://en.wikipedia.org/wiki/Hollywood_Accounting](http://en.wikipedia.org/wiki/Hollywood_Accounting)

------
cdcarter
A neat intro for a project that looks like it could be very neat, but
definitely not yet full featured enough to compete in the Quickbooks or even
Ledger environment.

It's an interesting move to make the docs all google docs, but for readability
it really is quite nice!

Your homepage talks about great handling of micro-transactions but I can't
find ANYTHING about it in the docs. Can you point me to something?

~~~
tmornini_ey
Thanks for your input!

We _never_ intend to be competitive with the product layers you've described.

We've deliberately built Subledger to enable other developers to build focused
custom accounting applications above us. :-)

We believe it's time to move beyond one-size-fits-all approach to accounting!
:-)

------
weddpros
I've studied accounting at school and I've always hated it since then.

To me, accounting is a data model gone wrong. Redundancy, race conditions,
unclear semantics, too generic...

I've tried countless times to make sense of it (the latest being today when I
read the post with great hope), but I always came to the same conclusion:
there must be a better way.

Yet I know the value of the model as a log to record transactions.

We're all confronted to accounting (when we read our bank ledger)... Ask the
public, and they'll tell you it's good if there's more money in the credit
column than the debit column. This "common wisdom" is _false_ in accounting.
What's a debit card? a credit card? What's an account? Isn't it a container
for money? not for accountants.

Accounting turns many concepts upside down... and I always fail to bend my
mind enough to grasp it.

I admire accountants for succeeding where I fail so miserably, but they're
also responsible for the problem. There must be a better way... I was so bad
in accounting at school...

~~~
dragonwriter
> Ask the public, and they'll tell you it's good if there's more money in the
> credit column than the debit column.

That's because the public is used to hearing the terms used by entities who
are using them in the accounting sense, but where the member of the public in
question is external to the entity whose accounting the term refers to.

So credit -- and outward flow of value -- sounds good, because when the public
hears it from another company, its usually because they are the _sink_ to
which value is flowing (and debit -- an inward flow -- sounds bad, because the
member of the public hearing an external entity use the term is usually the
_source_ from whom the value is flowing.)

Of course, neither is _intrinsically_ good or bad, they are good or bad
relative to a particular actor based on whether the account they refer to is
internal or external to the actor. Debit is just inward flow of value to an
account, credit is outward flow of value from an account.

> What's an account? Isn't it a container for money?

That's not a bad approximation; a better approximation would be "a named
accumulation of flows of value".

> Accounting turns many concepts upside down... and I always fail to bend my
> mind enough to grasp it.

Interestingly, all the concepts you list that the public perceives in a way
which you seem to think conflict with the accounting view actually reflect
_limited subsets_ of the accounting view from a narrow perspective, which are
subsumed within the more general view of accounting.

Accounting doesn't turn them upside down, it just broadens them.

~~~
weddpros
Thanks for your comment :)

It still puzzles me a great deal!

------
davidw
If anyone's interested in Luca Pacioli and the history of accounting, I
enjoyed this book:

[http://davids-book-reviews.blogspot.it/2012/12/double-
entry-...](http://davids-book-reviews.blogspot.it/2012/12/double-entry-how-
merchants-of-venice.html)

------
z3t4
Startup idea: Create a bank with accounting tools built in. Also make it easy
to receive payments via credit cards.

~~~
scoopr
Holvi?

[https://about.holvi.com/en/](https://about.holvi.com/en/)

------
tmornini_ey
Hey all!

John and at appreciate all the discussion and feedback.

We're absolutely delighted to have struck a chord with developers, the
intended audience of this piece, and with accountants, who have managed and
passed down this technology for 700 years.

We're working through the backlog of comments and will reply where we feel we
can add some value.

~~~
jasode
_> with developers, the intended audience of this piece, _

I'm not sure why you feel the document targets _developers_ specifically. I
didn't see any text that's a unique bridge to a developer's perspective.

For example, a text for "developers" might include examples of video game
"tokens" or multi-player "weapons" that can be traded. You'd outline a
rudimentary outline of what data structure to keep track of the source and
destination of where the tokens went.

Or an example would be bitcoin money being subtracted and added to various
accounts. Since many developers know bitcoin, maybe map bitcoin ledger concept
to accounting concepts. Or explain how they are radically different.

Your current document is a generic introduction and one can search & replace "
_for developers_ " to " _for biologists_ " and nothing else would have to
change.

~~~
tmornini_ey
Thanks for your feedback. We felt it was for developers are we're developers
and this is the way we've come to describe and understand it having built
Subledger.

Your point is excellent and we'll steer toward developers in the future.

------
facepalm
What are good tools for getting started with accounting? Simple needs (just my
private affairs)?

------
Roboprog
It's funny: I had to write this stuff back in 1985. After that, we did reports
and special inventory breakdowns added onto an existing 3rd party system.
Still, I guess it helps to know where projected purchases and sales are being
logged.

------
walterbell
HN thread on triple-entry accounting,
[https://news.ycombinator.com/item?id=7771712](https://news.ycombinator.com/item?id=7771712)

------
k_sze
Did the author forget to secure the _other_ document (Accounting for
Developers 103) that is linked to from the first one?

~~~
tmornini_ey
We left all three open for commenting, which we've now disabled.

------
crimsonalucard
accounting for developers? Does this mean the text is dumbed down or made more
advanced?

~~~
itsybitsycoder
It means it's teaching (or attempting to teach) the field of accounting using
terms, concepts, and styles of thinking familiar to developers, instead of
starting from square 1.

~~~
tmornini_ey
Thank you, could not have answered this better myself!

Also, it's by-developer, for-developer, so there's a developer's perspective
as well. :-)

------
velvety
dxctfyvgbuhljk

------
louithethrid
Essential knowledge, so when your average clueless buisness major tryies to
get you to come up with new metrics and wont buy into other previous useless
metrics (codelines checked in etc.) you can invent something funny, that
allows you to go back to "real" work. Success never had trouble getting
Alimoney-suits.

------
0xdeadbeefbabe
I find the title racist or sexist or both.

~~~
tmornini_ey
I assume this is a joke, but if not, let's discuss.

~~~
0xdeadbeefbabe
Though the headline is obviously doing its job, I'm just not willing to
swallow the presupposition that developer people exist in the same way that
male and female exist or that Asians exist. Developers as they are called are
just people with a range of skills, and the same goes for accountants. I even
heard a good accounting school has a program for accountants with a proclivity
for programming.

I admit the title isn't absolutely fascist, racist, or sexist, but it is some
kind of ist, and it is annoying. Maybe accountants, with self congratulatory
pride in their profession, feel the urge to divide the world up into neat
little categories?

~~~
tmornini_ey
Are you suggesting that nobody should class themselves as a developer, and/or
that as self-identified developers, who I can agree are just people with a
range of skills (and I never suggested otherwise), we should not attempt to
write a document attempting to explain accounting to other self-proclaimed
developers, who, in our decades of experience, tend to have certain
viewpoints, vocabulary, and interests in common?

Finally, while I'm delighted that you agree the title isn't _absolutely_
fascist (which you never claimed in the original post and suggest in your
response it to be _partially_ ), racist or sexist, I'm entirely baffled as to
why you felt compelled to post a comment stating it in absolute terms in the
first place.

~~~
0xdeadbeefbabe
Did you say decades of experience? Oh. Ok. Nevermind.

I'm just asking myself why not write about accounting, and let the reader
decide what group he or she belongs to. The answer is clearly something like,
we need a good title.

------
mvdwoord
Lies < Damn lies < Statistics < Bookkeeping.

~~~
throwaway_97
What kind of stupidity is this?

~~~
codemac
[https://en.wikipedia.org/wiki/Lies%2C_damned_lies%2C_and_sta...](https://en.wikipedia.org/wiki/Lies%2C_damned_lies%2C_and_statistics)

A joke?

