Accounting For Developers, Part I

The name "double-entry bookkeeping" may be misleading: what matters is not how many times / in how many places you do entry, but whether you're tracking both (or all) sides of a transaction. (With a computer you only need to enter the transaction once, as long as you track the "from"/"to".)

A couple of examples from personal money-tracking:

• say you have a bank account, and you track when the bank balance increases / decreases. That's single-entry. When you withdraw cash from your account at an ATM, your bank balance decreases, and when you buy something with cash your balance doesn't change — this is probably not what you want. With double-entry bookkeeping, you track separate "accounts" for (say) "bank account", "cash" and "outside world", and every transaction is an edge in this graph (or in general, hyperedge in hypergraph). (E.g. withdrawing $100 cash means a transaction that is -$100 on "bank account", and +$100 on your "cash" account, which add up to 0.)

• Similarly, with your bank account and credit-card account, when you pay your credit-card bill it's a transaction between your bank account and credit-card account, and when you buy something with your credit card it's a transaction between your credit-card account and the "outside world" account (which you can break down more granularly if you want to track your expenses).

Summary: double-entry bookkeeping means that instead of entering "this balance decreased" or "this balance increased" (without a direct way of linking where the money came from or went), you enter transactions that track all the changes as one unit, and in each transaction the sum of the "postings" is 0.

Or just read this by Martin Blais, it's still the best: https://beancount.github.io/docs/the_double_entry_counting_m...

If you are interested in error-preventing and tamper-proof fund tracking systems, have a look at the UTXO model. Bitcoin and many cryptocurrencies use it, but the actual model predates Bitcoin.

https://en.wikipedia.org/wiki/Unspent_transaction_output

I was lucky enough to work on a billing system early in my career and pick up some rudimentary knowledge of accounting. I can confirm that even being able to 'speak the language' a little bit provides immense value to you as a developer.

Double-entry is kind of a bad name, but the concept is sound.

I like think of each entry as the complete journal entry - a set of debits (abbreviated DR) and credits (abbreviated CR) that describe an event. Debits and credits are, as many accounting instructors have taught many students, names that effectively mean "Left Side" and "Right Side". Some accounting systems represent debits as positive numbers and credits as negative numbers - this is perfectly valid too.

Say somebody purchases a product for $60 and a service for $40 from me. The product that I sold cost me $40 to purchase, and both the product and service have a 5% sales tax applied. This is a very common transaction - car repairs, for example, are usually a combination of products (e.g., oil, oil filter) and services (e.g., oil change and inspection).

    Account               DR      CR
    Cash in bank         105
    Tax Payable                    5
    Sales Revenue                 60
    Services Revenue              40
    Cost of Goods Sold    40
    Inventory                     40

In this example, I collected $105 in cash from my customer which will go into my bank account. Because of this sale, I now owe the relevant tax agency $5 because I collected sales tax on their behalf. I recognized sales revenue of $60 and services revenue of $40. Since I sold some physical goods that I had in inventory, I also reduced the value of my inventory by the cost of what I sold.

This is, in my mind, one "entry" which has six detail lines to recognize all of the different things that need to be recorded for this event. The important point is that everything balances, credits always equal debits.

Some businesses might not do the Cost of Goods Sold / Inventory entries with each transaction, instead they might count their inventory once a month and calculate out how much they sold (inventory at start + inventory purchased - inventory at end = cost of goods sold) and just do one entry a month to get the books in sync with reality.

Yes, that was quite confusing. Thanks for mentioning.