Accounting for computer scientists (2011)(martin.kleppmann.com)
martin.kleppmann.com
Accounting for computer scientists (2011)
https://martin.kleppmann.com/2011/03/07/accounting-for-computer-scientists.html
50 comments
In my high school in South Africa, we were made to take accounting for a time. The entirety of what I remember of the experience can be summed up thusly:
A. Equity = Assets - Liabilities
B. Test time! Here's something we've never talked about before: try to guess which side it goes on!
A. Equity = Assets - Liabilities
B. Test time! Here's something we've never talked about before: try to guess which side it goes on!
If you want a gentler introduction to B, you could spend 5 mins on this, which I created ~5 years ago:
https://www.oppia.org/explore/pepGU0qbyoUm
https://www.oppia.org/explore/pepGU0qbyoUm
I enjoyed that, thank you.
Isn’t the balance sheet changes between two points in time the cash flow statement?
The P&L is based on transactions on Income accounts. The balance sheet is a point in time view of BalanceSheet accounts.
For example: CASH is balance sheet. However REVENUE is an income account type.
The income statement is the changes between to points in time of all balances of Income accounts.
The P&L is based on transactions on Income accounts. The balance sheet is a point in time view of BalanceSheet accounts.
For example: CASH is balance sheet. However REVENUE is an income account type.
The income statement is the changes between to points in time of all balances of Income accounts.
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: 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.)
A balance sheet has three primary segments, corresponding to the accounting equation:
- Assets
- Liabilities
- Equity
--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.)
I learned the basics of accounting from the GnuCash guide. [1]
One of the best things I ever did.
If the featured article helps you understand accounting, good! If it's something else, that's fine too.
I agree with an HN comment [2] from long ago: learning the basics of accounting is a superpower. And not just when talking to finance people.
I do my budget in double-entry. (Can you guess my program of choice?) It allows me to budget across long periods of time and to more easily focus where my wife and I are spending money.
Learn accounting. It may suck, but you'll be glad you did.
[1]: https://www.gnucash.org/viewdoc.phtml?rev=5&lang=C&doc=guide
[2]: https://news.ycombinator.com/item?id=32497570
One of the best things I ever did.
If the featured article helps you understand accounting, good! If it's something else, that's fine too.
I agree with an HN comment [2] from long ago: learning the basics of accounting is a superpower. And not just when talking to finance people.
I do my budget in double-entry. (Can you guess my program of choice?) It allows me to budget across long periods of time and to more easily focus where my wife and I are spending money.
Learn accounting. It may suck, but you'll be glad you did.
[1]: https://www.gnucash.org/viewdoc.phtml?rev=5&lang=C&doc=guide
[2]: https://news.ycombinator.com/item?id=32497570
Seconding this, the GnuCash manual is fantastic. The principles of double entry accounting are very simple but if you're not used to thinking in those terms it can sometimes be a little confusing how to fit real life scenarios into that framework. The GNC manual has a lot of helpful explanations and examples.
> I do my budget in double-entry.
I have a short term budget in GNUCash in the form future dated scheduled transactions, but for more strategic stuff I have an annual budget spreadsheet, which among other things, models income taxes. Increase 401k contributions, and the sheet says I owe less tax. The GNUCash budget tooling is... less useful.
I have a short term budget in GNUCash in the form future dated scheduled transactions, but for more strategic stuff I have an annual budget spreadsheet, which among other things, models income taxes. Increase 401k contributions, and the sheet says I owe less tax. The GNUCash budget tooling is... less useful.
I agree that the GnuCash budget tooling is not useful.
I created separate "Budget" accounts (for every budget category) that are Liability accounts, and I also created a "Budgeted Money" Expense accounts.
Updating the budget for the month is done by debiting Budgeted Money and crediting the account for the particular budget I want.
Then when doing a transaction, on top of the debits and credits that would be there, I debit the budget account and credit the Budgeted Money account.
This lets me use the reports (with a little tweaking to get just budget stuff), as well as to split one transaction up into multiple budget expenditures if necessary, like for certain Amazon orders.
This is not for everyone, probably yourself included, but it does work for me.
I created separate "Budget" accounts (for every budget category) that are Liability accounts, and I also created a "Budgeted Money" Expense accounts.
Updating the budget for the month is done by debiting Budgeted Money and crediting the account for the particular budget I want.
Then when doing a transaction, on top of the debits and credits that would be there, I debit the budget account and credit the Budgeted Money account.
This lets me use the reports (with a little tweaking to get just budget stuff), as well as to split one transaction up into multiple budget expenditures if necessary, like for certain Amazon orders.
This is not for everyone, probably yourself included, but it does work for me.
> 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 ^_^
Sounds a bit like accrual based accounting, which indeed is not for me ^_^
I appreciate the call-out.
I agree w/ you re: the benefits for personal finance, too.
For everybody else: If your work at all touches accounting of finance learn basic bookkeeping. It'll pay tremendous dividends.
I agree w/ you re: the benefits for personal finance, too.
For everybody else: If your work at all touches accounting of finance learn basic bookkeeping. It'll pay tremendous dividends.
Accountants use jargon in the same way that programmers do - to succinctly express commonly known and understood concepts. They do not use 'hard words'; if the words are 'hard' it's because the reader lacks the domain knowledge that accountants have been trained in.
The fact is that double-entry bookkeeping does not use negative numbers. Where confusion might arise is in the meaning of 'debit' and 'credit'.
'Debit' only means 'the left hand side', and 'credit' only means 'the right hand side'.
A debit is not a subtraction operation, nor is a credit addition. I suspect this mis-conception mostly arises because that's how it looks when a Bank 'credits' your account with your deposit - in fact it's increasing its liabilities (it owes you the money) which is recorded as an entry in the right-hand side of the liability column.
edit: typo
The fact is that double-entry bookkeeping does not use negative numbers. Where confusion might arise is in the meaning of 'debit' and 'credit'.
'Debit' only means 'the left hand side', and 'credit' only means 'the right hand side'.
A debit is not a subtraction operation, nor is a credit addition. I suspect this mis-conception mostly arises because that's how it looks when a Bank 'credits' your account with your deposit - in fact it's increasing its liabilities (it owes you the money) which is recorded as an entry in the right-hand side of the liability column.
edit: typo
'Debit' only means 'the left hand side', and 'credit' only means 'the right hand side'.
I think about it like this:
CR / Credit / Creditors -> what the business owes
DR / Debit / Debtors -> what the business owns
> '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):
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):
<BAL|FSV> = 0
I'm eternally interested in learning more about accounting, but I think this is missing crucial information to actually explain what "accounting" is while laying on this patronizing anti-intellectual "accountants use hard words" writing style.
1. What are you trying to solve by "doing accounting"? After reading this article, it seems like it's some sort of arbitrary aesthetic, like people who think the point of organizing is to have no more papers on your desk.
2. How do the actions in this guide solve those questions? Why make a graph? Why make extra buckets? Why color them? Relatedly, I couldn't find an answer to "why is double entry bookkeeping revolutionary" despite spending a fair amount of time searching. I think it's either related to manual accounting (i.e. not relevant to computers) or is directly related to this question.
I appreciate the mapping of accounting terms to graph features, but the title is way too grand for the contents. I just noticed another commenter who seems to know a lot more than me says roughly the same (although much more negatively).
In addition, here are some things I'd like to know (in addition to the above, although I have guesses to the answers to some):
1. How to deal with accounting over time? When received payments and made payments are at different dates, amortization, etc. If you're trying to identify missed payments, time disconnects create permanent gaps which may or may not be an issue.
2. How to deal with multiple currencies. Related to variance over time: exchange rates, balance calculation, etc.
I feel like "make a graph" is the easy 5m answer and the first thing you arrive at if you look up double entry bookkeeping.
Lastly, I agree that accounting is a fundamental skill, but before you can do accounting you need _data_. All transactions, categorized, all accounts, all balances. This is the hard part. If you're an accountant and this is your job, okay. If I need to manage N accounts in my time after work, well that's a significant chunk of my non-work time.
Mint doesn't work well outside major western spheres. For a while I maintained my own scrapers, but I've fallen back to "just spend as little as possible and you'll avoid going negative" which is not where I want to be but until there's open banking here I don't see many options.
1. What are you trying to solve by "doing accounting"? After reading this article, it seems like it's some sort of arbitrary aesthetic, like people who think the point of organizing is to have no more papers on your desk.
2. How do the actions in this guide solve those questions? Why make a graph? Why make extra buckets? Why color them? Relatedly, I couldn't find an answer to "why is double entry bookkeeping revolutionary" despite spending a fair amount of time searching. I think it's either related to manual accounting (i.e. not relevant to computers) or is directly related to this question.
I appreciate the mapping of accounting terms to graph features, but the title is way too grand for the contents. I just noticed another commenter who seems to know a lot more than me says roughly the same (although much more negatively).
In addition, here are some things I'd like to know (in addition to the above, although I have guesses to the answers to some):
1. How to deal with accounting over time? When received payments and made payments are at different dates, amortization, etc. If you're trying to identify missed payments, time disconnects create permanent gaps which may or may not be an issue.
2. How to deal with multiple currencies. Related to variance over time: exchange rates, balance calculation, etc.
I feel like "make a graph" is the easy 5m answer and the first thing you arrive at if you look up double entry bookkeeping.
Lastly, I agree that accounting is a fundamental skill, but before you can do accounting you need _data_. All transactions, categorized, all accounts, all balances. This is the hard part. If you're an accountant and this is your job, okay. If I need to manage N accounts in my time after work, well that's a significant chunk of my non-work time.
Mint doesn't work well outside major western spheres. For a while I maintained my own scrapers, but I've fallen back to "just spend as little as possible and you'll avoid going negative" which is not where I want to be but until there's open banking here I don't see many options.
I'll try to answer some of your questions, but I'm not an accountant.
1. You're trying to understand the money coming in and going out of a business. The organization of this information can make certain events more apparent, like whether you're actually making or losing money (this is not necessarily obvious!) how much 'runway' a company has, roughly how valuable it is (a bit nebulous because a lot more goes into it, but "doing accounting" is the starting point), whether inventory is being stolen more than might be normal, etc.
2. No idea about this guide or the coloring. TBH a spreadsheet conveys the data better than a graph. Double entry bookkeeping was a revolutionary idea though. I think it's fairly easy to forget the full effect of a transaction. I buy a $500 chair for my business, this isn't just $500 less in cash, it's $500 more in some 'furniture' asset. This accounting for every minute detail of what your business owns or owes across even dozens of transactions becomes difficult to track.
1. Look up cash vs. accrual accounting. I think I learned most of this on Khan Academy the first time, but there must be dozens of YouTube videos on it. Basically w/ accounting over time you start adding deferred accounts of different sorts like payables and receivables.
2. No idea. I think when you start getting into these topics there is either just some software solution that follows some standard or allows you to make a choice about how to use the exchange rate, or there is some specific standard set by FASB saying how to do it. But I don't know.
As a simple example of something else, with inventory, businesses can value it a few different ways including FIFO and LIFO (where they value inventory based on the price they paid least or most recently) among others. These choices are often just a preference for the business, or perhaps common for a business' industry. I suspect there might be similar methods of valuation for accounts denominated in different currency, where you could take the amount by exchange rate either on the first or last of the month or by its average rate over the month.
1. You're trying to understand the money coming in and going out of a business. The organization of this information can make certain events more apparent, like whether you're actually making or losing money (this is not necessarily obvious!) how much 'runway' a company has, roughly how valuable it is (a bit nebulous because a lot more goes into it, but "doing accounting" is the starting point), whether inventory is being stolen more than might be normal, etc.
2. No idea about this guide or the coloring. TBH a spreadsheet conveys the data better than a graph. Double entry bookkeeping was a revolutionary idea though. I think it's fairly easy to forget the full effect of a transaction. I buy a $500 chair for my business, this isn't just $500 less in cash, it's $500 more in some 'furniture' asset. This accounting for every minute detail of what your business owns or owes across even dozens of transactions becomes difficult to track.
1. Look up cash vs. accrual accounting. I think I learned most of this on Khan Academy the first time, but there must be dozens of YouTube videos on it. Basically w/ accounting over time you start adding deferred accounts of different sorts like payables and receivables.
2. No idea. I think when you start getting into these topics there is either just some software solution that follows some standard or allows you to make a choice about how to use the exchange rate, or there is some specific standard set by FASB saying how to do it. But I don't know.
As a simple example of something else, with inventory, businesses can value it a few different ways including FIFO and LIFO (where they value inventory based on the price they paid least or most recently) among others. These choices are often just a preference for the business, or perhaps common for a business' industry. I suspect there might be similar methods of valuation for accounts denominated in different currency, where you could take the amount by exchange rate either on the first or last of the month or by its average rate over the month.
I appreciate the help, but I think the goal of understanding the money coming in and going out is too abstract - what does it mean to understand, and at what level is understanding achieved?
The point I want to make is that all the things described in the article should be described in terms of their relation to the problems being solved. Because the article failed to establish this connection you can say "a spreadsheet conveys the data better than a graph", or vice versa, and there's no way to decide whether that's true or not.
For instance, being able to answer the following questions:
- Do I have enough money to continue operating?
- Are there any unexpected losses?
- If there are unexpected losses, where are they?
- Are there unexpected gains? And where are they?
- If I want to spend more, how much can I safely spend?
- How are accounts likely to change in the future, and can the above questions be answered then?
Maybe there are others. Questions an exec, or a spouse, or the tax office might ask. The goal needs to have that level of specificity. When an accountant "balances the books" it's not an arbitrary exercise, it's trying to answer one of those questions above.
For the record, I absolutely want an accounting for computer scientists guide. I'm not exactly interested in wrestling with and mapping the concepts myself, at least with the free time I have right now.
The point I want to make is that all the things described in the article should be described in terms of their relation to the problems being solved. Because the article failed to establish this connection you can say "a spreadsheet conveys the data better than a graph", or vice versa, and there's no way to decide whether that's true or not.
For instance, being able to answer the following questions:
- Do I have enough money to continue operating?
- Are there any unexpected losses?
- If there are unexpected losses, where are they?
- Are there unexpected gains? And where are they?
- If I want to spend more, how much can I safely spend?
- How are accounts likely to change in the future, and can the above questions be answered then?
Maybe there are others. Questions an exec, or a spouse, or the tax office might ask. The goal needs to have that level of specificity. When an accountant "balances the books" it's not an arbitrary exercise, it's trying to answer one of those questions above.
For the record, I absolutely want an accounting for computer scientists guide. I'm not exactly interested in wrestling with and mapping the concepts myself, at least with the free time I have right now.
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.
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.
Outside of the concepts, one of the biggest life organization lessons I learned was from the user guide of beancount (a plaintext accounting software), particularly for managing finances:
- Create folders for Assets, Liabilities, Expenses, and if applicable Equity
- Organize files starting by ISO date YYYY-MM-DD.mortgageStatement.pdf
https://docs.google.com/document/d/1wAMVrKIA2qtRGmoVDSUBJGmY... talks about this.
You can use a file renaming tool (like `qmv`, built into GNU's fileutils) to help with getting started. This has helped myself get organized and help in organizational settings too.
- Create folders for Assets, Liabilities, Expenses, and if applicable Equity
- Organize files starting by ISO date YYYY-MM-DD.mortgageStatement.pdf
https://docs.google.com/document/d/1wAMVrKIA2qtRGmoVDSUBJGmY... talks about this.
You can use a file renaming tool (like `qmv`, built into GNU's fileutils) to help with getting started. This has helped myself get organized and help in organizational settings too.
Kleppmann knocks it out of the park here.
Most accounting is actually insane. What should be an immutable ledger is actually the farthest thing from.
A few years ago I had a gig writing some custom reporting for a business that was struggling to get reproducible reports (i.e. I ran this report yesterday and now I can never produce the same report again) and it turned out their accounting practices were the root of the problem.
Closing books and reconciliation have to be the two practices which are most commonly done in the absolute dumbest way possible in electronic bookkeeping. Don't mutate your historical records!
Most accounting is actually insane. What should be an immutable ledger is actually the farthest thing from.
A few years ago I had a gig writing some custom reporting for a business that was struggling to get reproducible reports (i.e. I ran this report yesterday and now I can never produce the same report again) and it turned out their accounting practices were the root of the problem.
Closing books and reconciliation have to be the two practices which are most commonly done in the absolute dumbest way possible in electronic bookkeeping. Don't mutate your historical records!
Soooo many people do this. Temporal tables can help to see dumb stuff happening.
Shameless plug: some time ago I wrote a booklet [0] about principles of accounting with examples in Ledger [1], aimed at personal/home finance (as opposed to corporate finance).
[0] https://leanpub.com/personal-accounting-in-ledger
[1] https://ledger-cli.org/
[0] https://leanpub.com/personal-accounting-in-ledger
[1] https://ledger-cli.org/
I feel this doesn't explain double entry bookkeeping well enough.
The connectedness of double entry bookkeeping and the way that it links the balance sheet to the PNL is what makes accounting powerful and accurate.
The fact that you can look at an accounting balance sheet and if it matches what exists in reality, you can somewhat trust the profit and loss statement is a very powerful concept.
Anyone who's going to write accounting programs really needs to focus on this concept.
The connectedness of double entry bookkeeping and the way that it links the balance sheet to the PNL is what makes accounting powerful and accurate.
The fact that you can look at an accounting balance sheet and if it matches what exists in reality, you can somewhat trust the profit and loss statement is a very powerful concept.
Anyone who's going to write accounting programs really needs to focus on this concept.
Discussed at the time:
Accounting for Computer Scientists - https://news.ycombinator.com/item?id=2298471 - March 2011 (75 comments)
Accounting for Computer Scientists - https://news.ycombinator.com/item?id=2298471 - March 2011 (75 comments)
Traditional accounting models are too anemic to account for most resource flows, REA is proper accounting for computer scientists:
https://en.wikipedia.org/wiki/Resources%2C_Events%2C_Agents
Quote: The REA model gets rid of many accounting objects that are not necessary in the computer age. Most visible of these are debits and credits—double-entry bookkeeping disappears in an REA system. Many general ledger accounts also disappear, at least as persistent objects; e.g., accounts receivable or accounts payable. The computer can generate these accounts in real time using source document records. REA treats the accounting system as a virtual representation of the actual business. In other words, it creates computer objects that directly represent real-world-business objects. In computer science terms, REA is an ontology.
https://en.wikipedia.org/wiki/Resources%2C_Events%2C_Agents
Quote: The REA model gets rid of many accounting objects that are not necessary in the computer age. Most visible of these are debits and credits—double-entry bookkeeping disappears in an REA system. Many general ledger accounts also disappear, at least as persistent objects; e.g., accounts receivable or accounts payable. The computer can generate these accounts in real time using source document records. REA treats the accounting system as a virtual representation of the actual business. In other words, it creates computer objects that directly represent real-world-business objects. In computer science terms, REA is an ontology.
>At the heart of each REA model there is usually a pair of events, linked by an exchange relationship, typically referred to as the "duality" relation. One of these events usually represents a resource being given away or lost, while the other represents a resource being received or gained.
So, debit and credits.
The Wikipedia article does little to really explain how it works. How, for example, does a bank contemplating making a loan to the business evaluate its profitability and cash flow, or the liquidity of its assets? (After all, most bankruptcies are not because the business has negative net worth, but because it hasn't enough liquid assets to cover operational expenses).
So, debit and credits.
The Wikipedia article does little to really explain how it works. How, for example, does a bank contemplating making a loan to the business evaluate its profitability and cash flow, or the liquidity of its assets? (After all, most bankruptcies are not because the business has negative net worth, but because it hasn't enough liquid assets to cover operational expenses).
> So, debit and credits.
Debits and credits can be seen as a type of resource flow in REA, but not all resource flows are debits and credits. A debit-credit architecture does not require linking resource flows with their duals, and those that do are likely a limited type of REA system. This loses important information.
Assessing value need not be any different in most cases. The point behind REA is not to change established methods of evaluating such questions for domain experts, but to show how traditional accounting abstractions are not core information abstractions and so shouldn't be modelled directly in computers, but should be derived views of a more general architecture.
Debits and credits can be seen as a type of resource flow in REA, but not all resource flows are debits and credits. A debit-credit architecture does not require linking resource flows with their duals, and those that do are likely a limited type of REA system. This loses important information.
Assessing value need not be any different in most cases. The point behind REA is not to change established methods of evaluating such questions for domain experts, but to show how traditional accounting abstractions are not core information abstractions and so shouldn't be modelled directly in computers, but should be derived views of a more general architecture.
I learnt all of this by using ledger[0] and, of course, reading its manual. I've been maintaining my own accounts for more than a decade now. It's fun being able to plot my overall wealth and expenses over time.
[0] https://ledger-cli.org/
[0] https://ledger-cli.org/
Same: see also https://plaintextaccounting.org/
...the gist is "ledger.exe" (crufty-old-C-program) is the "perl" of plain-text-accounting. The implementation _is_ the specification.
"HLedger" (haskell) is the mostly-compatible ("now you have 15 standards!") which cleans up a bit of the crufty accidents and is considered more "pure" and "correct".
Mess with it for funsies, and consider using `hledger-ui` for browsing. It's really really powerful!
Specifically this part is super cool: https://ledger-cli.org/doc/ledger3.html#Commodities-and-Curr...
...and: https://ledger-cli.org/doc/ledger3.html#Currency-and-Commodi...
Implied exchange rates, arbitrary commodities/inventory. It gets into really heady territory pretty quick.
...the gist is "ledger.exe" (crufty-old-C-program) is the "perl" of plain-text-accounting. The implementation _is_ the specification.
"HLedger" (haskell) is the mostly-compatible ("now you have 15 standards!") which cleans up a bit of the crufty accidents and is considered more "pure" and "correct".
Mess with it for funsies, and consider using `hledger-ui` for browsing. It's really really powerful!
Specifically this part is super cool: https://ledger-cli.org/doc/ledger3.html#Commodities-and-Curr...
...and: https://ledger-cli.org/doc/ledger3.html#Currency-and-Commodi...
Implied exchange rates, arbitrary commodities/inventory. It gets into really heady territory pretty quick.
As someone who studied accountancy, let me clue you into a secret: there is only one "rule" of double entry: Something Owned = Something Owed.
Call it Asset = Liabilities, divide those liabilities into owner vs external, divide those assets into current vs long term, those are just externalities that we tacked on so that every one is on the same page.
If you want to put an asset with a working lifetime of 10 years, all into one year, double entry will not stop you. Debit Asset, Credit Cash, boom it's done, your books will balance.
It's who decide, hang on, this asset will be useful for 10 years, it would be more true and fair if we divide this value over the 10 years.
And that's the unspoken law of accountancy, Captain true and fair from IFRS HQ to the rescue, to make sure every one's books make "sense" and are "accurate" and "comparable" and what not.
But if the taxperson decides, hand on, other people's machines last for 12 years, so you too must divide the machine's cost over 12 years or get a penalty from us... guess what, we now have the first actual law: Whatever the local law says, is how we will do it, and if we have to keep multiple books so that accounts comply with all the various jurisdictions, so be it.
Most companies I know have two set of account reporting, one that complies with IFRS and one that complies with local GAAP, with some sort of reconciliation paper to keep track of the changes between each.
But at the end, it boils down to the same thing, everything owned = everything owed.
Call it Asset = Liabilities, divide those liabilities into owner vs external, divide those assets into current vs long term, those are just externalities that we tacked on so that every one is on the same page.
If you want to put an asset with a working lifetime of 10 years, all into one year, double entry will not stop you. Debit Asset, Credit Cash, boom it's done, your books will balance.
It's who decide, hang on, this asset will be useful for 10 years, it would be more true and fair if we divide this value over the 10 years.
And that's the unspoken law of accountancy, Captain true and fair from IFRS HQ to the rescue, to make sure every one's books make "sense" and are "accurate" and "comparable" and what not.
But if the taxperson decides, hand on, other people's machines last for 12 years, so you too must divide the machine's cost over 12 years or get a penalty from us... guess what, we now have the first actual law: Whatever the local law says, is how we will do it, and if we have to keep multiple books so that accounts comply with all the various jurisdictions, so be it.
Most companies I know have two set of account reporting, one that complies with IFRS and one that complies with local GAAP, with some sort of reconciliation paper to keep track of the changes between each.
But at the end, it boils down to the same thing, everything owned = everything owed.
> Even “Bookkeeping for Dummies” makes my head spin. Surely this stuff can’t be that difficult?
Is this an artifact of accounting itself? Or of the country in which you live?
In my country, accounting is… well still not easy but at least I would say it is accessible to most.
Meanwhile my impression of the US tax system for example (not my country!), is that it is a very complicated system with grave consequences for making any sort of mistake. All thanks to the efforts of US companies hiring lobbyists to work against general public interest.
Is this an artifact of accounting itself? Or of the country in which you live?
In my country, accounting is… well still not easy but at least I would say it is accessible to most.
Meanwhile my impression of the US tax system for example (not my country!), is that it is a very complicated system with grave consequences for making any sort of mistake. All thanks to the efforts of US companies hiring lobbyists to work against general public interest.
I find pure accounting confusing in its principles, regardless of country and details. The doubling of transactions and balances, and the non intuitive signs, mess me up every time. This article goes some small way for me to not be completely angry every time I try to learn accounting (next step:French language :).
Start with the accounting equation. That's critical foundation.
> grave consequences for making any sort of mistake
Not really. The grave consequences tend to be doled out to people who're obviously trying to cheat the system. For most people, it's just "you owe X. Please pay X." If you take a long time to pay X then there might be penalties added.
I remember that years after my wife shut down a business, we got a very nasty letter from the IRS about all the things they could do: sue, garnish wages, confiscating the house, jail terms, etc. But it all boiled down to "you owe $75 from 3 years ago. Pay it ASAP."
One interesting thing my "tax guy" pointed out is that the IRS is pretty lenient on businesses in their first year because they expect you to make a lot of mistakes in accounting or filing taxes.
Not really. The grave consequences tend to be doled out to people who're obviously trying to cheat the system. For most people, it's just "you owe X. Please pay X." If you take a long time to pay X then there might be penalties added.
I remember that years after my wife shut down a business, we got a very nasty letter from the IRS about all the things they could do: sue, garnish wages, confiscating the house, jail terms, etc. But it all boiled down to "you owe $75 from 3 years ago. Pay it ASAP."
One interesting thing my "tax guy" pointed out is that the IRS is pretty lenient on businesses in their first year because they expect you to make a lot of mistakes in accounting or filing taxes.
Not accounting related, but this guy's book "Designing Data-Intensive Applications" is a very, very well written book for people interested in that sort of thing!
I was briefly in a night MBA program at San Jose State (until I decided there was no point to that).
However, the Accounting and Finance courses were totally worth it. We're playing the game of Business (even in a non-profit), and knowing how they keep score is immensely valuable.
However, the Accounting and Finance courses were totally worth it. We're playing the game of Business (even in a non-profit), and knowing how they keep score is immensely valuable.
The lack of an oxford comma in the title was enabling me to hope that the article would be about tech companies' managers measuring their standard accounting in terms of a commoditised 'computer scientists' unit - like if we have 'x' number of computer scientists, we are worth 'y' much. We can credit & debit the number of 'computer scientists' in our org to account for IT buildouts, like a new LLM or ETL system. Training an LLM costs 'z' computer scientists (maybe in person-year format - i.e. 'CS-years').
Really interested in when computer scientists are loaned, what form of interest is paid out on them =)
---
</MBAmusing>
Really interested in when computer scientists are loaned, what form of interest is paid out on them =)
---
</MBAmusing>
I've always thought that accounting is arithmetic made difficult, but this helps a lot.
It's worth remembering that accounting was developed before negative numbers.
>I've always thought that accounting is arithmetic made difficult
It basically is. The fact that operations like "debit" and "credit" behave differently based on the sign-convention of the account is legacy baggage that should have been done away with a literal millennium ago. The whole situation is as absurd as if physicists decided that the concept of a "negative" voltage was a bad thing so KVL was formulated as sum{delta_sources} = sum{delta_loads} instead of just sum{delta_voltage} = 0, and then people had to memorize under which conditions circuit elements were treated as sources instead of loads, and when anyone questions why it's all so confusing they just get told that's the way things have always been done.
It basically is. The fact that operations like "debit" and "credit" behave differently based on the sign-convention of the account is legacy baggage that should have been done away with a literal millennium ago. The whole situation is as absurd as if physicists decided that the concept of a "negative" voltage was a bad thing so KVL was formulated as sum{delta_sources} = sum{delta_loads} instead of just sum{delta_voltage} = 0, and then people had to memorize under which conditions circuit elements were treated as sources instead of loads, and when anyone questions why it's all so confusing they just get told that's the way things have always been done.
I'm the rare old timer accountant with some programming background
I definitely agree with you though my approach to analyzing activity/preparing detailed reports/etc. is to, at a first step, convert all credits to negative numbers and retain all debits as positive
Further, most charts of accounts are designed in some sane way that you can easily tell what type of account it is (asset/liability/capital/P&L)
The challenge isn't usually managing/interpreting these things but making sure you are interpreting contracts and guidance properly/consistently so you don't upset ownership or your auditors with unanticipated changes/revisions...
I definitely agree with you though my approach to analyzing activity/preparing detailed reports/etc. is to, at a first step, convert all credits to negative numbers and retain all debits as positive
Further, most charts of accounts are designed in some sane way that you can easily tell what type of account it is (asset/liability/capital/P&L)
The challenge isn't usually managing/interpreting these things but making sure you are interpreting contracts and guidance properly/consistently so you don't upset ownership or your auditors with unanticipated changes/revisions...
I had previously thought of the similar idea, making diagrams similar to the ones in that article.
The article does not mention "debit" and "credit", although that is what they are doing; the arrows point toward the debit side, and they are using the convention of debits being positive and credits being negative. (Since the sales amount is a credit amount and the amount of money you have is a debit amount, so the sales amount appears negative due to this.)
The article does not mention "debit" and "credit", although that is what they are doing; the arrows point toward the debit side, and they are using the convention of debits being positive and credits being negative. (Since the sales amount is a credit amount and the amount of money you have is a debit amount, so the sales amount appears negative due to this.)
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.
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.
I took so much away from this discussion already. But what I'm really missing I guess is a video that explains double entry bookkeeping in a concise and though-out way. Can anyone recommend one?
Being an accountant I always find hn discussions on the topic fascinated.
Presumably similar to accountants opining on software architecture.
Presumably similar to accountants opining on software architecture.
Double-entry accounting at its simplest is the accounting equation:
Every transaction that is booked in a ledger must balance by issuing a debit and a credit.
Take Cash as an example. Cash is normally considered an asset account. Suppose you receive $10 in Cash temporarily from financing but you have an obligation to pay it back in the future. That obligation can be represented by a liability account called Accounts Payable. When receiving the cash, the following entry should be booked:
Next, lets look at what happens when we pay back $5 of our obligation. First, we book the following entry:
Let's close out our accounts before answering that question.
Assets:
Hold on. Where did R/E come from? That stands for Retained Earnings and represents the net profit as the end of the period measure by the Income Statement (I/S). Similarly, the movement of Cash would be measured during the period in the Statement of Cash Flows (C/F) with the ending cash position flowing into the Cash balance on the B/S.
Accounting is more complex in reality of course, but I hope this provides a demonstration of how double-entry accounting works and how accountants think when performing bookkeeping functions. It's really sort of a fun practice in a geeky way. It's all about the flow of balancing things. Everything is accounted for, and these practices demonstrate how business resources are used.
Any questions?
Adapted from this blog post: https://www.winstoncooke.com/blog/2023-10-20-a-basic-introdu...
Assets = Liabilities + Equity
Every transaction that is booked in a ledger must balance by issuing a debit and a credit.
Take Cash as an example. Cash is normally considered an asset account. Suppose you receive $10 in Cash temporarily from financing but you have an obligation to pay it back in the future. That obligation can be represented by a liability account called Accounts Payable. When receiving the cash, the following entry should be booked:
Cash $10
Accounts Payable $10
Assets = Liabilities + Equity
10 = 10 + 0
Cash
---------
10 |
A/P
---------
| 10
Next, lets look at what happens when we pay back $5 of our obligation. First, we book the following entry:
Accounts Payable $5
Cash $5
Cash A/P
--------- ---------
10 | | 10
| 5 5 |
Assets = Liabilities + Equity
5 = 5 + 0
Inventory $10
Equity $10
Inventory Equity
--------- ---------
10 | | 10
Equity
---------
| 10
Assets = Liabilities + Equity
15 = 5 + 10
Cash $20
Inventory $10
Revenue $10
Cash Inventory
--------- ---------
10 | 10 |
| 5 | 10
20 |
Inventory
---------
10 |
| 10
Revenue
---------
| 10
Let's close out our accounts before answering that question.
Assets:
Cash Inventory
--------- ---------
10 | 10 |
| 5 | 10
20 | ---------
--------- $0
30 | 5 ---------
--------- ---------
$25
---------
---------
Liabilities:
A/P
---------
| 10
5 |
---------
$5
---------
---------
Revenue Equity
--------- ---------
| 10 | 10
--------- ---------
$10 $10
--------- ---------
--------- ---------
Assets = Liabilities + Equity
25 = 5 + 20
---------------
Balance Sheet
---------------
Assets:
Cash 25
Inventory 0
---------------
Total $25
---------------
Liabilities:
A/P 5
---------------
Total $5
---------------
Net assets: $20
---------------
Equity:
Equity 10
R/E 10
---------------
Total $20
Hold on. Where did R/E come from? That stands for Retained Earnings and represents the net profit as the end of the period measure by the Income Statement (I/S). Similarly, the movement of Cash would be measured during the period in the Statement of Cash Flows (C/F) with the ending cash position flowing into the Cash balance on the B/S.
Accounting is more complex in reality of course, but I hope this provides a demonstration of how double-entry accounting works and how accountants think when performing bookkeeping functions. It's really sort of a fun practice in a geeky way. It's all about the flow of balancing things. Everything is accounted for, and these practices demonstrate how business resources are used.
Any questions?
Adapted from this blog post: https://www.winstoncooke.com/blog/2023-10-20-a-basic-introdu...
and there is no mention of putting IP on the balance sheet
Pointless.
In the heat the battle, with deadlines pending, and projects on the go, no one gives af about accounting until the very end when they realise they've f'd up the budget and want you to save the day "somehow".
Source: extensive experience.
In the heat the battle, with deadlines pending, and projects on the go, no one gives af about accounting until the very end when they realise they've f'd up the budget and want you to save the day "somehow".
Source: extensive experience.
The mathematical principles of accounting are explained in an innovative way here [1],[2]. Also look for the book "Algebraic Models for Accounting Systems".
Skipping mathematical formulations and going directly for a "computer science" view is not always the right path.
Unfortunately, while these references are illuminating (NB: there is an entire niche of mathematical accounting literature) after you dig into them and get the gist of it you'll realize that what is missing is a standardized textbook treatment of the special vector spaces that define accounting. This is no accident. Accounting is one of these Kafkaesque closed professions that thrive on obscurity.
[1] https://papers.ssrn.com/sol3/papers.cfm?abstract_id=1340619
[2] https://www.ellerman.org/the-math-of-double-entry-bookkeepin...
Skipping mathematical formulations and going directly for a "computer science" view is not always the right path.
Unfortunately, while these references are illuminating (NB: there is an entire niche of mathematical accounting literature) after you dig into them and get the gist of it you'll realize that what is missing is a standardized textbook treatment of the special vector spaces that define accounting. This is no accident. Accounting is one of these Kafkaesque closed professions that thrive on obscurity.
[1] https://papers.ssrn.com/sol3/papers.cfm?abstract_id=1340619
[2] https://www.ellerman.org/the-math-of-double-entry-bookkeepin...
It doesn't have to be this way!
Start with this identity:
This is self-evident: the owners of the company have a claim on the company's assets, but only after any liabilities (like debts to other companies) have been subtracted.
That identity can be rearranged:
This tells us that for everything the company owns, it also owes something. It has debts to some other entity (liabilities) and anything left over is owed to shareholders (equity).
Accounting transactions are made when something happens in the business. Each transaction changes the balance sheet. The balance sheet is made up of the three items in the identity, but there's more granularity. For example Assets might have a 'cash/bank' account and also an 'inventory' account
Any accounting transaction touches one or more than one of these three accounts.
Got some new equity funding? It increases Assets (cash in the bank) but also increases Equity (paid up share capital) by the same amount. So the identity is preserved.
Sold a product and collected some cash? Assets go up: yes, inventory decreased $10, but cash went up $15. So now Equity (retained earnings) goes up by $5 and the identity still holds.
The P&L (aka Income Statement) shows how the balance sheet changed between two points in time. Profit is the change in Equity between those two points (after removing any increase decreased from share issuance or buybacks).
If you've read this far and want some intuition about debits and credits, I wrote a brief post here: https://www.encona.com/posts/debits-and-credits