Accounting for computer scientists (2011)

> This is not for everyone, probably yourself included, but it does work for me.

Sounds a bit like accrual based accounting, which indeed is not for me ^_^

This is the article I always share with new joiners at Tebi: www.tebi.co

We’re building an accounting software system. And on top of that a POS system, inventory management, expense tracking etc.

But at the core it’s a double entry financial journaling system.

I love how Kleppmann bridges the fields of computer science and accounting.

I’ve even build graph visualizations of our journals and ledgers using Kleppmanns technique.

The balance sheet's components each capture distinct aspects of a company's finances. While you've mentioned 'income accounts', these actually fall under the Equity section.

A balance sheet has three primary segments, corresponding to the accounting equation:

  - Assets
  - Liabilities
  - Equity

Specifically, you seem to be focusing on:

--Assets: Cash and cash equivalents--

This indicates a company's liquid position. To understand cash flow changes over a given period, compare the differences in 'cash and cash equivalents'.

-- Equity: Retained earnings–-

This reflects accumulated income. To gauge profit changes over a time frame, observe the variations in Retained Earnings. (This is accurate provided no dividends were distributed during that period.)

Hi rendaw, I made an account just to reply to you because I think your questions are excellent ones.

I am a CPA by background. While much of my professional work today involves programming and working with data, I continue to work primarily in accounting and finance contexts because it is the type of work that I find most interesting.

I don't have a ton of time right now but let me at least answer your first question "what are you trying to solve by doing accounting?". At its core double-entry accounting is a control system (e.g. safeguarding the resources / assets of a corporation by tracking their use). The most important control is that debits must always equal credits. You might understand that in the context of a balance sheet, however it's important to recognize that double-entry accounting systems record business events by way of journal entries. A valid journal entry must include two or more accounts where the sum of debited amounts always equals the sum of credited amounts (if you want to understand why that is a rule I can talk about that in another post). It is a simple & rigid rule, however it still affords enormous flexibility in terms of being able to precisely express business events.

All financial statements are derivative of a series of time ordered journal entries. This series of entries is known as the general journal (not the general ledger which is more often talked about). The general journal is basically just a log of business events. Business events recorded in the form of journal entries are discretely understandable, although you often need the context of other entries to be sure about what's actually occuring.

It's also very important to recognize that this log of journal entries is append-only and immutable. If a mistake is made you never go back a delete an old journal entry, you just make a new one to correct it (sometimes called an adjusting entry). This preserves the ability to review journal entries and intuitively understand what a business is doing over time.

For example, when a company makes a sale you might see a journal entry where accounts receivable is debited and the sales account is credited. A week later you might see a journal entry where cash is debited and accounts receivable is credited, reflecting that the amount for the sale made a week earlier was collected.

This concept of an immutable time-ordered log of events is / was a powerful and useful idea for some obvious and not so obvious reasons that I could talk about for days.

I believe this blog post is also valuable to read and it specifically mentions accounting data structures (I believe it is fairly well known) https://engineering.linkedin.com/distributed-systems/log-wha...

Can talk more later if anyone is interested.

> 'Debit' only means 'the left hand side', and 'credit' only means 'the right hand side'.

Well, it is a bit more than that. It is the two sides which must balance, so you put them on those sides in order to make them balance. For example, you would put assets and expenses on the debit side, liabilities and revenue and capital are on the credit side, so they will be added up because e.g. you would earn money (a asset) in the debit side and the equal number of revenue on the credit side, so you can see that they are equal.

Of course you could consider them addition and subtraction (in either order; the diagrams in the article use the convention that debit is positive and credit is negative, while you seem to be using the opposite convension) and then consider that they add up to zero, which is mathematically equivalent to the description above.

The diagrams in the article is another way; the arrows are pointing toward the debit side in these diagrams (so the Sales and Capital are shown as negative because they are in the credit side). ("Now, by convention, accountants flip the sign on all of the blue and pink nodes’ balances" is also because they are in the credit side.)

Or the "matrix accounting" that I had made up, where the balance is represented by the equation (which doesn't have any reference of "debits" and "credits", etc):

   = 0

( is considered to vary over time and represents the financial state vector. (It is a kind of projective space.))