23 ms·
Double-entry bookkeeping as a directed graph
- mportela 3y agoHi, all! I'm not an accountant but decided to study double-entry bookkeeping and basic accounting a while ago. I learned a lot from many places, including great threads here on HN, and wanted to give back to the community. In this article, I explain the mechanics of double-entry bookkeeping and how I came to realize it's a directed graph. I know there are many accounting nerds on HN so please feel free to criticize or suggest changes where I got things wrong!
- RcouF1uZ4gsC 3y ago> and how I came to realize it's a directed graph. One of the funnest things in computer science is realizing how some problem that you may not suspect initially turns out to be some type of graph.
- anodari 3y agoNice article, congratulations. I have worked with information systems all my life and one of the biggest insights I had was that the transaction, a purchase or a sale, which is the basis of the ERP system, is converted into 2 flows, the money that enters or leaves on one side and the product or service in another, this is accounting double entry. It may be obvious and simple, but I see that few people in my area have this understanding.
- samsin 3y agoOne of those threads may have been a blog post by Martin Kleppmann [1], who also describes double-entry bookkeeping as a directed graph. [1] https://martin.kleppmann.com/2011/03/07/accounting-for-computer-scientists.html https://martin.kleppmann.com/2011/03/07/accounting-for-compu...
- wjnc 3y agoI’ve been in finance for nearly 20 years and okay, so, I’m kind of hesitant to admit… this is so great. Would love for my controllers to create such graphical flows of operating results. At some scale accounting gets pretty hard (hard as in at least one professor on the accounting policies team) and what I’ve learned from statistics is that graphics matter (Ross Ihaka, Andrew Gelman). With the appropriate abstraction any figure can get a graph of the constituting components. Moment of clarity here, thank you.
- foobarian 3y agoJust wanted to say, I have been trying to understand double-entry bookkeeping for 30 years now and this is the first explanation that finally clicked for me so thank you!
- blackhaj7 3y agoGreat article. I would love an RSS feed or place to subscribe on your site so I can be sure to read the next in the series
- sgarland 3y agoNothing of substance to add, I just wanted to say that I thoroughly enjoyed this post.
- nickpinkston 3y agoI think people underestimate the beauty and impact of accounting. Just a tiny number of formulas (accounting identities [1]) and statements (P&L, balance sheet, etc.) can represent what's going on in any org in ways that can be roughly comparable. Reminds me of the "fundamental theorem of calculus" or "central dogma of biology". Accounting is also where we get math and written language [2] as ancient Mesopotamian civilizations initially kept track of commodities using specific "accounting tokens" [3] shaped like the thing represented, and that evolved into written language, imagine: hieroglyphics. Later, Al-Jajr [4] (aka algebra, literally "balancing") was invented by Al-Khwarizmi (origin of "algorithm") to solve Islamic inheritance law, whose rules of splitting up became a series of equations that led to the need to solve them quickly and correctly. Al-Khwarizmi's quadratic formula was the origin of why "algorithm" gets its name from him. [1] https://en.wikipedia.org/wiki/Accounting_identity https://en.wikipedia.org/wiki/Accounting_identity [2] https://en.wikipedia.org/wiki/History_of_accounting https://en.wikipedia.org/wiki/History_of_accounting [3] https://en.wikipedia.org/wiki/History_of_ancient_numeral_systems#Clay_tokens https://en.wikipedia.org/wiki/History_of_ancient_numeral_sys... [4] https://en.wikipedia.org/wiki/Al-Jabr https://en.wikipedia.org/wiki/Al-Jabr [5] https://en.wikipedia.org/wiki/Al-Khwarizmi https://en.wikipedia.org/wiki/Al-Khwarizmi
- wongarsu 3y agoOn the other hand some things in how accounting is traditionally done suffer from accounting predating a lot of "modern" math. Negative numbers were first used around the 3rd century in China and took until the 16th century to be used in Europe. Modern double-entry bookkeeping was invented in the 14th century in Europe. So if you ever wonder why they traditionally use a column for debit and one for credit, with definitions that seem a bit strange: that was the best way to make it work with only positive numbers.
- alexb_ 3y agoI wonder if this is why losses are written down with () instead of -.
- 3y ago
- pcrh 3y agoMy understanding of double-entry bookkeeping is that it does not care who Alice bought the book from, nor what their accounts look like. Instead, the "double entry" that complements the money leaving Alice's cash ledger is the entry of the value of the book into Alice's "book ledger", one decreases by $20, and the other increases by the same amount.
- rco8786 3y agoYou're right about the double-entry part, but bookkeeping more generally definitely cares about who Alice bought the book from.
- grantc 3y agoIndeed. While dr==cr gets you far towards being able to calculate account balances and an entity's aggregate financial position, it's also fairly foundational that you are able calculate the company's position with different counterparties. So knowing that Alice purchased the book from Foo Booksellers, but maybe hasn't settled with FooBooks yet is super relevant. The company's accountant may care about balances and reconciling them back to things like the existence of said book, a receipt for payment or a bank transaction indicating settlement happened. At a big enough company, the accounts payables nerds may come along and be focused on making sure the full process procuring and paying has happened correctly, including record-keeping, tax compliance, and the actual movement of funds. When you start to scale how all of these processes are executed and recorded, it's dense enough that it still surprises me many years later.
- kayo_20211030 3y agoKinda yes and no on this. The journal entry capturing the transaction will be for the transaction of Alice buying the book from Bob. The debits and credits will be tied to that JE. Somebody is keeping book and the accounts are the accounts of that somebody. A fictional bookstore will have all the info, but Alice's and Bob's bank might not.
- evrimoztamur 3y agoIn real-life bookkeeping the journal entries contain a lot of metadata which link the individual entries to other objects such as invoices, fixed assets (computers, equipment, furniture, etc.), contacts. In an organisation's accounting (Alice LLC), the basis entry would state a debit (increase of expense) in the book expenses account, credit (decrease of asset) in the cash balance. The complete entry would then make a reference to the invoice/receipt of the purchase and the contact details of the bookstore (address, chamber of commerce registration ID, tax number, etc.). The exact level of detail is determined by how 'complete' your books are supposed to be. A book expense might not mean much to Alice LLC (which does not deal in book sales/purchases), but a laptop should (see more on the subject of fixed asset registries), or a large invoice from a business from a different country (which will require a lot more diligence with tax 'metadata'). On the other hand, the bookstore definitely cares more about books and will then consider the sale and replenishment of its book inventory, and once again introduce more meta-accounting data (see more on the subject of management/manufacturing accounting).
- BoppreH 3y agoI always enjoy these explainers that use computer science terms. In this case, you can be more precise about the type of graph: double-entry accounting creates a Directed[0] Bipartite Graph[1] with Labelled Edges[2]. Every edge is between a Transaction and an Account nodes, which makes it bipartite, and the amounts are edge labels. [0] https://en.m.wikipedia.org/wiki/Directed_graph https://en.m.wikipedia.org/wiki/Directed_graph [1] https://en.m.wikipedia.org/wiki/Bipartite_graph https://en.m.wikipedia.org/wiki/Bipartite_graph [2] https://en.m.wikipedia.org/wiki/Graph_labeling https://en.m.wikipedia.org/wiki/Graph_labeling
- feoren 3y agoNo, it's not bipartite. in this article, every edge is between two Accounts. One edge is one transaction; one node is one account. Don't try to make transactions nodes, ew.
- kayo_20211030 3y agoNice job on this. But, one has to be careful with redefining terms that have a generally accepted meaning. Changing Debit/Credit to Incoming/Outgoing smacks of jargon and will cause confusion. Any bookkeeper will understand what credit cash and debit expense means. Putting that in incoming and outgoing terms will not help the people who do the work, or have to explain the work. It's probably worth the effort of learning the nomenclature that's been useful for a few hundred years rather than falling back on what are metaphors.
- EvanAnderson 3y agoI'll go further: Knowing basic accounting and bookkeeping jargon is a super power when it comes to dealing with finance people. Your credibility builds tremendously when you can engage with them using the proper jargon correctly.
- UglyToad 3y agoBut the problem is the accounting jargon is counter (contra?) to the layman's gut understanding. If I get credited or I use a credit card money came from nowhere, woohoo. If I have a debit well that sounds like debt and my money decreased, boo. I get that actually there's a good reason for the names but a field that doggedly sticks to non intuitive jargon that runs counter to every usage yet encountered for outsiders could do with some different non-overloaded terms.
- mrkeen 3y ago> Changing Debit/Credit to Incoming/Outgoing smacks of jargon and will cause confusion. I disagree. Discussions like this on HN always invite someone to say "Look, it's super simple. Credits are just... and debits are just ...". Then a reply saying "You have it backwards. Look, it's simple! Credits are just..." I would be perfectly happy to ditch those terms forever.
- mrkeen 3y agoPlenty of downvotes, and yet, after writing this prediction, this thread is indeed filled with people all defining the terms 'Credit' and 'Debit' at one another. :D
- qznc 3y agoStill too complicated. It goes wrong with "Let’s add the Transaction column to our table." Don't store the account data. Instead store the transactions. Compute the accounts from that. The table "Transactions" should have the fields: Date, Amount, SourceAccount, TargetAccount, Description. That is how it becomes beautiful in my opinion. Unlearn this habit of thinking in accounts just because that is what you know from your bank statements. Think in cash flows. (Ok, this is too simple for the tax use case. Sometimes transactions have multiple sources or targets. So my schema above needs to be adapted for that. My point is that the thinking should still be different.)
- thfuran 3y agoIsn't having to replay every transaction in history to query current balance rather inefficient?
- globular-toast 3y agoIt's a trade off. Immutability is a big enough win to pay the price of a few extra CPU cycles. In practice it's very quick anyway. Computers are very good at adding numbers together (it's almost like it's what they were made for!). I keep all my accounts for over 12 years in one file and I still don't notice any delay when calculating balances etc. If it does become a problem then one solution is to take sums at some point in time and start the ledger again paying each account from a contra account containing the previous balance.
- BillyTheKing 3y agoI mean, yes for personal accounts with a couple of thousand transactions - sure. But esp. in payments or in exchanges there can be accounts with millions of transactions a day. So you get a double-whammy - those are hot-accounts which also slow down the system, recalculating the balance for those accounts each time a transaction happens isn't an option
- globular-toast 3y ago
- dkyc 3y agoI find it a strange choice to explain double-entry bookkeeping with the example of "one entry for Alice, one entry for Bob". That's really not what it's about. It's obvious that a transaction with two parties could be recorded in two places, but to me the crucial point of double-entry bookkeeping is that it requires two entries for each party of the transaction. So if Alice buys book from Bob, four entries are made. I get that this is supposed to be a simplification for educational purposes, but I find this is simplification is an oversimplification, since it omits the key point.
- em-bee 3y agoi was about to write the same thing. knowing that double-entry is meant to apply to myself only, i actually found the example confusing, because well, of course bob is going to have an entry in his accounting book, but i don't care about bobs accounts, i don't want to track that. i only care about mine. i buy a book. how do i record this transaction using double entry bookkeeping in my accounting book? and bob is not even doing any bookkeeping. he is bookselling ;-)
- toong 3y agoYou gained $20 worth of assets, so the counterpart of the $20 leaving your bank account is countered by your assets-account gaining $20 Now each year your book loses 1/5th of its value, due to wear and tear (4$ disappearing from your assets-account), this is countered by your depreciation-account (4$ tax write off, every year!) After 5 years, it is worth $0 according to your books, but you manage to sell it again for $10: your bank account gets debited for $10, while your capital-gains-account gets credited for $10
- nolongerthere 3y agoThis is the best explanation, everyone else is giving wrong explanations that appear to be at least partially sourced from some AI.
- probably_wrong 3y agoAnd how about food? I can understand a book having a resale value I keep in my books, but once I've eaten the hot-dog I bought it is gone forever.
- 2Gkashmiri 3y agoIs there any person who wants to test an old but currently in-development agpl licensed accounting software? Your help would be regarding testing the software, reporting bugs and maybe submit PRs to fix issues https://gnukhata.org/install/ https://gnukhata.org/install/
- gibsonf1 3y agoA better way to do this would be to more closely model what is really happening, that is the transaction events which change state. The states being changed would be the account balance amounts input to and output from the transaction event. With the event, you can also track the system performing the function in the event. (All with rdf) https://graphmetrix.com/trinpod-server https://graphmetrix.com/trinpod-server
- mo_42 3y agoI believe double-entry bookkeeping needs more attention. I think double-entry bookkeeping is, at least to me, as fundamental to economics (and of course business) as logic to math. Even if some actors don't use it explicitly, it still holds. If I buy ten apples for 10 bucks, I have ten more apples in stock and ten bucks less. Many economic discussions (not only on HN) get out of hands because people don't try to see the full picture or deliberately choose to see one side. I've even seen a professor of economics claim in public that the world is too much in debt. Well, double-entry bookkeeping tells you that there are always two sides to consider. For example, in case of governmental debt they ignore the other side of that debt, which might be assets. Assets like airports, schools, bridges, etc. Usually, we call such things useful. Another typical example is the central bank "prints money". Well, double-entry bookkeeping tells us that it's not possible. If they hand out currency, the counterpart needs to trade something in (typically repurchase agreements with commercial banks). (Leaving aside here the idea of helicopter money, which could even go into neg. equity or a loss.)
- pcrh 3y agoAgreed. The "magic" of double entry bookkeeping is that it is a financial version of the Principal of the Conservation of Energy. It isn't as strict in that it allows for assets to alter in value, for profits or losses to be made. But it does keep track of the way that money and "value" circulates in different forms, e.g. as cash, assets, debts, depreciation, etc. The "double entry" keeps track of the transformation of the nature of "value". This is hard to do using a simple household-style "cash-in" and "cash-out" set of accounts.
- xphos 3y agoEconomics is funny because its very anti complex math. For the local economics (household even company level) that makes total sense but for anyone doing research or systems modeling for things bigger than a company the total distain for calculus and non-equilibrium systems really prevents any discussion. I think its because if you remove stability most of supply and demand arguments fall apart. Its crazy because stable systems are extremely rare in natural complex systems its weird to apply it to large parts of economics as a given. But here I'd caution against the idea that banks (not even central) cannot increase money supply because that's not really true. If a Bank is the backer of both sides of loans or engage in fractional reserve banks (i.e all banks), they can effectively increase money supply which in my opinion is equal to printing money. Especially since in the loan case, the loan is not necessarily a guaranteed asset (think cars in a crash). This effect is called the money multiplier effect via fractional reserve banking. https://www.youtube.com/watch?v=93_Va7I7Lgg https://www.youtube.com/watch?v=93_Va7I7Lgg The multiplier is more of ceiling to the amplification rather than it actually happening on loans. None of this necessarily bad loans and investment are really important to other parts of economics but none of it is simple and non of it is stable in the traditional sense
- 29athrowaway 3y agoWell, in this case - balance = states - transactions = state transitions It is simply the representation of state transitions as a diagram, similar but not equivalent to that of a state machine.
- t_mann 3y ago> Definition 6: Credit An entry that represents money leaving an account. > Definition 7: Debit An entry that represents money entering an account. Not really, the meaning of debit and credit depends on the type of account: https://en.wikipedia.org/wiki/Debits_and_credits https://en.wikipedia.org/wiki/Debits_and_credits Maybe there's a reason why it takes more than one course to become a CPA (https://www.accounting.com/careers/cpa/how-to-become/ https://www.accounting.com/careers/cpa/how-to-become/).
- Sammi 3y agoSecond sentence of that wikipedia article is: "A debit entry in an account represents a transfer of value to that account, and a credit entry represents a transfer from the account."
- rahimnathwani 3y agoNot really, the meaning of debit and credit depends on the type of account That's how most accountants think about it. But I think there's something more fundamental: a CR entry is an increase is what the company owes (to creditors or shareholders), and a DR is an increase in what the company owns. EDIT: see this link for how this relates to the accounting equation https://news.ycombinator.com/item?id=32501707 https://news.ycombinator.com/item?id=32501707
- emptyfile 3y ago[dead]
- jfengel 3y agoIsn't that exactly backwards to what most people think of credits and debits? If you credit me something, I now have something. I don't owe anything. I can kinda squint and see "Oh, you want the universe to balance, so if I have something it is some kind of karmic debt". But it still feels like exactly the opposite of what I grew up thinking of these terms to mean.
- rahimnathwani 3y ago
- guthriej 3y agoMartin Kleppmann (author of Designing Data-Intensive Applications) has a great article in the same vein: https://martin.kleppmann.com/2011/03/07/accounting-for-computer-scientists.html https://martin.kleppmann.com/2011/03/07/accounting-for-compu...
- btbuildem 3y agoI think I'm missing something here. How does looking at transaction history as a directed graph help anything? Is it an improvement on the centuries-old "double-entry" practice? It seems to barely work with the toy example of couple transactions - imagine what the graph would look like with dozens or hundreds of edges between pairs of nodes. What use would there be for the typical algorithms that work with graphs? This feels a bit like using pliers as a hammer. Sure, you can, I guess -- but why?
- brvsft 3y ago[dead]
- deleted 3y ago[deleted]
- weego 3y agoThe article feels like a similar insight to the founding ideas of cryptocurrencies. Engineers stumbling on foundational principles baked into other fields that software happens to be replicating.
- inopinatus 3y agoIt’s hare-brained. The article is over-egging the pudding. They haven’t established a justification, and the author’s claim that this visualisation helped them arrive at a clearer understanding is rather undermined by the category errors they make in the course of trying to geeksplain D.E. from first principles. What’s more they’ve represented only one very simple transaction. God knows how they’re going to gain from a graph-based visualisation of something more abstract e.g. dissimilar tax and book depreciation, adjustments for gains/losses on foreign exchange, allocation of franked dividends, PAYG, holding of amounts in trust for other parties, partial recognition of deferred revenue and so forth.
- zamubafoo 3y agoI can see what you are saying, but I think it helps in two ways: 1. it is another way to conceptualize an idea. For most purposes this might not be relevant, but who knows where a hard accounting problem might be resolved through the application of graph theory (or the inverse!). 2. it is another way to visualize flows. Not everyone is financially literate or numerically inclined, so instead of handing them a table of columns of numbers and having them reason about the flows numerically, it lets you represent the flows spatially which maybe easier. After all, not all tools are for professionals. Additionally, while the cumulative history in one graph might be much, simply adding filters based on transaction date might provide non-obvious insight that other visualizations miss. I can see this probably being even more helpful by cross referencing other information such as location.
- globular-toast 3y agoEveryone should do their own accounts. I've been doing it for over 12 years and I'm so glad I've kept up with it. I don't bother keeping my ledger immutable, though. The point about immutability is that whatever happened is immutable (because it's in the past; it already happened!) and the ledger should just reflect that. So if I somehow made a mistake in my ledger I just correct it. I keep my ledger in git so that does record changes to the ledger itself, but I rarely, if ever, need to access these.
- brabarossa 3y agoWhat does that mean? Are you using cash? Are you copying bank transaction history to your git?
- globular-toast 3y agoYeah, I source my ledger from multiple places like bank transactions, investments accounts, cash transactions etc. I can't really think of a case where I have made a mistake, but if, for example, I sold something to a friend I would debit (+) their "reimbursement" account with the amount they owe me. If I typoed that to 10x the amount, I would just go and correct the typo, I wouldn't make two new entries to revert then correct the mistake.
- vwkd 3y agoGreat idea to treat of personal finances like a business. Also makes a great source of data for stats. Can you share more on the system you've come up with? In what format do you store the data? Do you store files per account, or per day, etc.? Do you have a CLI helper to quickly read, write, edit the files? Maybe you can even share a demo repo?
- globular-toast 3y agoI use ledger: https://ledger-cli.org/ https://ledger-cli.org/ I believe this same plain text format is used by other tools, which you can find info about here: https://plaintextaccounting.org/ https://plaintextaccounting.org/ (In particular a lot of people seem to use hledger and beancount) The ledger is written using a text editor. The purpose of the software is to add everything up, calculate the balances and make sure everything balances. I keep all of my 12 years of accounting in one file and haven't noticed any slowdown. But a real business would surely have many more accounts and may want to split files by financial year or something. I use helper scripts to convert the data from my bank CSV downloads into ledger format. It uses machine learning to associate payees to accounts (e.g. "Tesco" gets filed to the account "Expenses:Groceries"). I haven't maintained the ML part although it works for me most of the time. In case it's useful, the code is here: https://github.com/georgek/accounts/ https://github.com/georgek/accounts/
- doodlebugging 3y agoNice graphical breakdown. I think the real winner isn't Bob or Alice though they each benefited from the exchange. The real winner is the credit card company that banked 10% of the transaction on Alice's side and 5% on Bob's side. Sounds like they both chose the least sensible option to handle payment. Maybe Bob should've made it clear that he accepted cash, money orders, cashier's checks, or personal checks, or even cryptocurrency so that Alice would not need to suffer a foreign currency conversion fee especially when you consider that they live in the same small town. Just kidding. I realize that the example transaction needed some massaging on the path to the end graph to illustrate handling of more complex, real-world transactions. Great job producing this intuitive break-down. There is one thing that I found interesting near the top of the tutorial. You make the statement "But money is meant to be spent." If money exists to be spent then why do so many people accumulate such vast sums that they could never spend all that they have managed to accumulate? Dumb question, I know. Money in the hand has indeterminate or no value until the bearer needs to acquire a product or service and then the value of the money in hand is set by the seller of the product or service they require. The global economy functions because at some point in time a traditional barter system where useful physical items were exchanged was replaced by the current system involving exchange of special artisan linen papers or conveniently portable metallic disks emblazoned with cartoon images celebrating historical events or personalities. Anyway, this was a good read and I enjoyed watching the transaction ledger complexity increase to account for real-world situations where there are more than two parties involved in a single transaction. Years ago when I was in high school we had a class that introduced us to checking and saving accounts and the goal of the class was to teach us how money moves through the system so that we could manage our own assets once we had real jobs and incomes. We had the introduction to the ledger book with one side handling credits and the other handling debits. It was all confusing at first but ended up being very useful. A long time after this class I found myself working as an independent consultant paid a negotiable hourly rate. All of that earlier instruction came in very handy when I needed to split project time and classify and categorize all the transactions that helped me understand where all that cartoon cash came from and where it all went. My spouse is a CPA/Auditor so having her level of knowledge and experience close to hand was also enormously useful in splitting everything so that the charts and graphs I assembled were most intuitive. Thanks! I enjoyed reading this.
- phailhaus 3y agoI'm not sure that visualizing bookkeeping as a graph is helpful, it makes it really hard to tell what's going on and you lose the time dimension. What if you instead used a table to show movement of funds by transaction, and only used a graph to model the "aggregate result" of a set of transactions?
- andrewfowl 3y agoI think it is a great article and graph representation would be very useful to have in accounting. There are a few things I would add: 1. It may be beneficial to segregate ledgers (used to record transactions with customer accounts, i.e. with assets you do not own) vs. books (transactions recorded to present own assets and liabilities). Books are used to account for all possible types of assets and liabilities, while ledgers are usually strictly limited to reflection of cash movements. I think the article is about ledgers. 2. Regarding the state of each account at each period in time, I think there is a lot of confusion between reflecting activity / transactions in the period and adjustments related to how prior transactions were recorded. I personally thought that adjustments could be better accounted for using something like a model with slowly changing dimensions where you can see history of each change. So it is not something you want to see on the directed graph by default, but something you want to be able to trace. 3. There was one idea that I really don’t like because although it make sense on surface, it has really bad implications for accounting and analytics. The idea I am talking about is that you don’t need to have one debit and credit for transaction, rather you just need to make sure that total debits equal total credits. say, Bob has several types of accounts and multiple customer. Now Bob asks you to tell him, how much of the current balance of a specific account was generated from proceeds by customer. To answer it, you now have to solve many-to-many relationships between customers and Bob’s accounts. And sometimes it has no deterministic answer because we balanced multiple accounts in one entry. And accountant now have to use imagination and excel to prepare a manual report that uses multiple assumptions to answer this question.
- brvsft 3y agoIt was 'cute' the first time it was posted (in this form: https://martin.kleppmann.com/2011/03/07/accounting-for-computer-scientists.html https://martin.kleppmann.com/2011/03/07/accounting-for-compu...), but I find pointless musing like this to be counterproductive sometimes. While I understand the tendency to fixate on 'nerdy' topics like, "How can I take <thing> people think about as <X> and shove it into math or computer science idea <Y>?" this (a) doesn't introduce any substantive ideas (in this particular instance) and (b) would completely fuck up your bookkeeping and result in you failing an audit if you completely ditched double-entry bookkeeping in place of a directed graph. Use the appropriate structure for the data. A graph is not appropriate as you lose information about time, which is important to the ledger. No, you can't add time as a value on your edges. If you did, you'd either have several dozen graphs, or they would look absurd.
- thinkxl 3y agoThis is my mental model and how I built the backend of a budgeting web app. Two types of accounts: - assets (you want your balance to be more than 0) - liabilities (you want your balance to be 0) Two types of entries: - debits (increase balances of assets, decrease balances of liabilities) - credits (increase balances of liabilities, decreases balances of liabilities) Rules: - A transaction represents a transfer of value between accounts. - Every transaction must have at least two entries. The balance of all entries the transaction holds should be 0, i.e., balance = debits - credits. You don't think about money leaving or entering an account before you nail down those definitions. The account representations can be anything that holds a numeric value, not just money. You can affect more than two accounts by adding additional entries with the condition of keeping the balance to 0.
- kqr 3y agoGiven just the two accounts you have, your goals are impossible to achieve, because Assets = Liabilities, so you cannot have one more than zero and the other zero. I think in this problem hides two mistakes: - Zero liabilities is not a reasonable goal for most people. - There's an equity account type also. (Also income and expense accounts.)
- thinkxl 3y agoI don't understand your point. But instead of rationalizing with words, let's put it into practice. - I receive my paycheck in my bank account. - I want to budget $800 for groceries every month. - I have a credit card with a balance of $250. - I want to know how much I have left; we will have an account named Left to Budget (LTB). Let's outline them as accounts: - Bank Account. It's an Asset and has a balance of $0. - Groceries "category" Account. It's a Liability and has a balance of $0. - AMEX Account. It's a Liability and has a balance of $250. - LTB is my income account. It's a Liability (yeah, I know, but stay with me). When I receive my $1,000.00 paycheck. - Debits Bank (ASSET) for $1,000.00 - Credits LTB (LIABILITY) for $1,000.00 Balances: - Bank (ASSET) $1,000.00 - Groceries (LIABILITY) $0.00 - AMEX (LIABILITY) $250.00 - LTB (LIABILITY) $1,000.00 I budget $800 for Groceries for this month. - Debits LTB (LIABILITY) for $800. - Credits Groceries (LIABILITY) for $800. Balances: - Bank (ASSET) $1,000.00 - Groceries (LIABILITY) $800.00 - AMEX (LIABILITY) $250.00 - LTB (LIABILITY) $200.00 I go to the grocery store and buy Milk for $50 and Bread for $10. - Credits Bank (ASSET) for $60.00 - Debits Groceries (LIABILITY) for $60.00 Balances: - Bank (ASSET) $940.00 - Groceries (LIABILITY) $740.00 - AMEX (LIABILITY) $250.00 - LTB (LIABILITY) $200.00 As of now, I effectively know that: - I have $940 in my bank, but I only have $200 available to spend (LTB). - I have $740.00 left to spend on Groceries in my Bank. - If I wanted to pay my Credit Card (AMEX) in full, I couldn't. Even though I have enough money in my Bank, most of it is already allocated to Groceries. BUT I could adjust my budget, like so: Adjust my Groceries budget by moving $50 back to my LTB, so I can pay my Credit Card in full this month. - Debit Groceries (LIABILITY) for $50 - Credit LTB (LIABILITY) for $50 Balances: - Bank (ASSET) $940.00 - Groceries (LIABILITY) $690.00 - AMEX (LIABILITY) $250.00 - LTB (LIABILITY) $250.00 OK, so now I know that: - I still have $940.00 in my bank. - If I wanted to pay my Credit Card I can because I have enough in my LTB category. - I have $690.00 available to spend in Groceries, because I moved $50.00 away. Now, let's pay my Credit Card. - Credit Bank (ASSET) $250.00 - Debit AMEX (LIABILITY) $250.00 Balances: - Bank (ASSET) $690 - Groceries (LIABILITY) $690.00 - AMEX (LIABILITY) $0.00 - LTB (LIABILITY) $0.00 Now the money I have left in the Bank is for Groceries only. If I wanted to spend on something else, I'd have to either: - Create a new Category and transfer an amount from Groceries, or - wait for my next paycheck. -- We were able to manage all this information with only one bank account, but we successfully managed a small budget. Double-entry is a concept that's not necessarily applied directly to "physical" accounts. We transfer values between accounts even when the money stays where it is. > - Zero liabilities is not a reasonable goal for most people. Zero liabilities is not a goal; it's the direction on whether money balance increases or decreases; it's not tied to the money you have or owe. It's a concept or formula rather than a reality. > - There's an equity account type also. (Also income and expense accounts.) Equity and expenses are Assets. Income can be an Asset or a Liability, depending on how you want to represent it. For me, it is a liability because I want it to be 0. Even tho, my income account will have money, its representation of Money Left to Budget will be zero because the accounts that transfer value from it will include savings or investing accounts.
- elijahbenizzy 3y agoThis is a great write up, thank you! One thing I’m curious about is what properties/metrics of the graph mean for accounting. Spectral properties (eigenvalues, etc…) might have some insightful meaning for the financial system. Also I’m sure this is extremely well studied but I’m not super familiar — ML on accounting graphs could identify shapes that indicate illegal transactions, etc… Will dig for reading :)
- nyrikki 3y agoPersonally I find the model of a collection of immutable events that preserve assets= liabilities+ equity easier. Events being constrained to historical statements of fact.
- rjinman 3y agoDouble-entry bookkeeping is very easy to understand once you ditch the ridiculous "credit" and "debit" terminology. Essentially, the goal is to keep the accounting equation true at all times. The equation is: Equity = Assets - Liabilities. Eventually, earnings (Income - Expenses) will become part of equity, so splitting that out, you have: Equity + Income - Expenses = Assets - Liabilities. Rearranging to get rid of the minus signs you get: Equity + Income + Liabilities = Assets + Expenses. This equation must be true or something has gone wrong - like money appearing or disappearing out of nowhere. To keep it true at all times, it should be clear that any time you add money to an account on the left side of the equation (say, to an Income account), you must either add the same amount to an account on the other side or subtract the same amount from the same side. For example, you sell a lemonade for $5. You add $5 to Sales (Income) and add $5 to Current Account (Assets). The "credit" and "debit" terminology is ridiculous because their definitions swap around depending on which account you're talking about, which is an utterly absurd (mis)use of language and the main reason people find this confusing.
- jandrese 3y agoThe one thing I remember most from my economics courses in college is that economists have highly idiosyncratic mathematical conventions and they don't care. So many graphs with the independent variable on the Y axis...
- abtinf 3y ago> So many graphs with the independent variable on the Y axis I was perplexed by this as well and none of my profs could cogently explain it. The classic example are supply and demand curves, with price as the Y axis. I finally realized they are actually trying to communicate that price is not under the control of the buyer or seller, but that the market dictates the price given a level of production. This kind of “spherical cow” thinking made me develop a healthy contempt for conventional economics.
- abdullahkhalids 3y agoIndeed, one of the main problems with econ education is that at the most basic level they teach a model for the "spherical cow" free-market. Which is all that most people end up learning. And then those people try to apply this reasoning to real world markets - the vast majority of which do not satisfy the assumptions of the free-market model. So almost all public discussions of micro-economics is totally useless.
- lmeyerov 3y agoVery cool! Well-written, and surprisingly real: Somewhere VERY close to this modeling patterns has always been an interesting use case for us is large-scale visual analysis of crypto investigations, where the ledger gets shown quite similarly. The bit on taxes is funny too, as that's the first thing to get filtered out because it makes the graph messy :) Often, balances aren't initially known, so a post whole-graph-compute step is done to algorithmically enrich nodes after. You can also do visual tricks here, like collapse 'multiedges' between the same accounts to get a summary of their p2p history. Analytically, this becomes an easy groupby on a ledger dataframe :) To a lesser extent, we also see fiat $ investigations here too, imagine correspondent banking. I wish more bigco AML forensic accounting did this internally (erp, credit cards, ..), especially as so much is digital now, but we don't see that as much. An interesting area becomes when you do things like add identity details to the graph, and can then start realizing the "A" and "Alice" and contra XYZ are all the same person. Another, which helps once you have a lot of data, is to start to be able to decloak transaction $1 "food" is a Costco hotdog, or funny buying patterns. Both are where "graph neural networks" come in, which have really advanced over the last few years. We see this kind of things in finance, like risk analysis. We find most folks are at the viz stage vs AI stage, and it's a multi-year relationship to get them from one to another, but a fun one! --- Edit: Another practical modeling aha here is that a transaction can involve multiple entities. Formally, that is a hyperedge: it's fine for edges to connect more than 2 nodes. (And why languages like datalog are neat here, even if rare.) Visually that's confusing, so a trick is to make the transaction a node and connect it to all the involved accounts. Keeping transactions as event edges between entities can be nicer when zoomed out as fewer nodes, but having the transaction node is nice when zoomed in, and in the limit, there are asymptomatically fewer nodes+edges when doing the transaction node as you replace strongly connected components (quadtratic in edges) with a hub&spoke, which is linear.
- aquir 3y agoDouble-Entry Bookkeeping is great - I have learned it when started implementing ERP systems. This article is a bit overcomplicated and also, where is the Balancing Entry for the Opening Balances? It should be balanced against some Technical Account...
- m3kw9 3y agoDouble entry can track networth better. Instead of a single entry of recording 500$ paid for laptop, which decreases your networth by 500, in reality you still have 500$ worth of a laptop in your hand. You would also record the asset increase as a +500$ from gaining a laptop. Which reflects reality of your situation better.
- balderdash 3y agoMy personal observation is that where many people struggle the most mentally is across the three statements (balance sheet, income statement, and cash flows), 1) that that balance sheet is point in time and the other two are over some period, but 2) how a record entry effects each of the statements…e.g. if you sell an asset for a gain causing a change in the composition of the balance sheet (asset > cash, reversals of accumulated depreciation etc.) income statement (income in excess of basis) and cash flow (actual cash received)
- jacques_chester 3y agoInterestingly I sort of went in the other direction at one point -- converting what was obviously a graph (build pipelines) into a from-to / credit-debit representation. On reflection it's just an edge list. My main problem with adapting the representation was in the incommensurability of different kinds of asset moving through the pipeline. How does one credit source code and debit a blob store? I thought about learning more about multi-currency accounting as a source for ideas but never followed it up. That effort inspired my thinking about a "Universal Asset Graph" for software[0] -- keeping track of not just containment but also movement and transformation of software. It's a partial but not complete inspiration for GUAC, which aims to capture software part relations for easy querying. [0] https://theoryof.predictable.software/articles/some-requirements-for-a-universal-asset-graph/ https://theoryof.predictable.software/articles/some-requirem... [1] https://guac.sh https://guac.sh
- eunos 3y agoCool! Reminded me to this accounting explanation for CS folks (written by Designing Data Intensive Applications author) https://martin.kleppmann.com/2011/03/07/accounting-for-computer-scientists.html https://martin.kleppmann.com/2011/03/07/accounting-for-compu...
- sandGorgon 3y agoI built a double-entry ledger for multiple different kinds of credit cards at redcarpetup. the way i like to primarily think of it technically is idempotency. Thinking of balances is the wrong way to model it : 1. since you want the capability to recompute all balances using ledger entries. 2. there are not two balances. There's usually a lot more. you want to update reward points, dues, late fees, partner share, etc etc etc. a 2 balance double entry ledger is a simplification. once you set your mental model to think of it as a idempotency problem, there are multiple ways to model it. For e.g. a directed graph - traverse the entire subgraph to update balances. Or model it as a log database and re-run txns to arrive at balance computation.
- ggrothendieck 3y agoDavid P. Ellerman has a mathematical approach to accounting based on what he refers to as the Pacioli group. A provisional element of the Pacioli group looks like x//y where x and y are non-negative integers and we form equivalence classes based on x//y and u//v being equivalent if the cross sums x+v and y+u are equal. The group operation is x//y + u//v = (x+u)//(y+v) and the inverse of x//y is y//x . The identity element is 0//0. For more info see, for example, https://ellerman.org/wp-content/uploads/2012/12/DEB-Math-Mag.CV_.pdf https://ellerman.org/wp-content/uploads/2012/12/DEB-Math-Mag...
- nosmokewhereiam 3y agoThis helped me. In class now and the first ever accounting course I've taken. It's hard to wrap your head around without any background. Thank you!
- xg15 3y agoThere is one limitation of the graph visualization that's worth paying attention to: If you add a larger number of transactions to it, the graph will become tangled up and difficult to make sense of: You see which accounts trade with each other, but the order of the trades got lost, because all transactions share the same "account" nodes. Indeed, if you'd try to also track balances in the graph, you'd end up with the exact same limitations that the original, "mutable" account table had: You can only store a single "current" balance for each account and each time you add another transaction to the graph, the old balances of the accounts involved are lost. You could fix this shortcoming by redefining the meaning of the "round" nodes in the graph and essentially treating the graph as a ledger: Instead of a round node representing an account, make it represents an account at a specific point in time, i.e. between two transactions. Then new transactions can be added as new nodes and edges to e.g. the right side of the graph and the graph will become a long chain that grows from left to right and represents the exchange of money over time. (Another constraint has to be added that a transaction must never go "backwards in time", i.e. never go from a node to the right to one on the left and never have an "incoming" and "outgoing" edge pointing to the same round node) With many accounts and transactions, it might still get difficult to keep track, which transactions are close together in time and which are far apart. This could be made easier by introducing another container, let's call it a block, that groups all transactions together which share at least one "round" node in their "incoming" or "outgoing" edge. Because of the "no going back in time" property, the blocks will be non-overlapping and they will also have at least a partial ordering to them that follows the chronologial ordering of the transactions. If you want to make the graph extra pretty, pick one transaction in each block and use its timestamp to turn the partial into a total ordering. If you zoom out, your graph indeed looks like a chain of blocks, going from left to right in the direction of time, with each block containing the transactions that belong to the same slice of time. A blockchain, if you will...
- feoren 3y agoAnd then crypto-sign each transaction with an enormously expensive proof-of-work function because you don't trust anyone wearing a suit and then blindly go all-in on this new "blockchain" being the solution to every problem and then get scammed all the way up your own asshole by believing your own bullshit, and then beg those people in suits to fix it for you like a housecat begging for food from their owner they just scratched the shit out of, and be confused that they can't fix everything for you this time because you intentionally cut them out of the system. It's foolproof!
- TeeWEE 3y agohttps://martin.kleppmann.com/2011/03/07/accounting-for-computer-scientists.html https://martin.kleppmann.com/2011/03/07/accounting-for-compu...
- amelius 3y agoCan one do accounting using Git commits, and would it be practical?
- ebolyen 3y agoI see a lot of consternation about credits and debits and the nomenclature. Something that makes this simpler to think about from a modern perspective is that accounting is older than the popular use of negative numbers. By a lot. If we were to invent accounting today, we'd probably use positive and negative accounts instead of debit and credit accounts. Algebra over addition is second nature to us at this point, but it would not have been obvious to the average merchant in 1604, and even then, negative numbers were viewed quite poorly. What is important is that there are always two sides to a transaction and that they are inverses of each other. This is all a credit and debit are. Inverse operations on a number. Therefore, we can make a rule that a transaction balances when credit = debit. (aka we didn't invent money as debit + credit = 0, but remember that we didn't like negative numbers when this system was invented, so this last fact is more of a happy coincidence that happens to ALWAYS WORK, for some reason, rather than the goal). What is then reasonable is to consider literal cash on hand to be the most positive (debit) kind of account there can be, and work backwards from there. If I want to handle an expense, then I need to invert the cash account somehow (credit it) and therefore have the opposite kind of entry for where the money went (debit it). So an expense account must have a generally debit (or positive) balance. But where did the cash come from? Well that comes from income and I want the cash to be debit-ey so the place it came from must be credit-ey otherwise I risk writing a transaction that doesn't balance (equal zero). So then income accounts must generally be credit accounts rather than debit account (aka they hold a typically negative balance or are "credit normal"). What is really killer about this system, is it just so happens that every mundane transaction you could ever write will end up as balanced transactions and each of these possible transaction accounts end up having the same usual balance of credit or debit (negative or positive). I think that is just so elegant.
- EvanAnderson 3y agoI enjoy using the alliteration of "Capital" and "Credit" to remember the normal balance of the capital/equity accounts. Memorizing that and the accounting equation is all that's necessary to derive the normal balances of every other account type.
- yandrypozo 3y ago
- thedanbob 3y agoI recently wrote my own bookkeeping software based on a budgeting spreadsheet my wife found a long time ago and used for years. It wasn’t until reading this (and some of these comments and other references) that I realized it’s actually a disguised double-entry bookkeeping system. No wonder it works so well!
- vezuchyy 3y agoTen years in SAP working on FI, SD and AA. (not anymore, I'm done with that) The post triggered PTSD and I want to go home and cry. You created your double entry, cool, now let's split it (because of million reasons) and add taxes. So now we deal with a basic 25 line document where some lines are doing nothing but move funds through certain tax accounts. Oh, no, there is a typo, but we cannot just create the reversal because for some accounts, the transaction should stay reflected in turnovers, for some it should not and for most it depends on fiscal period and stuff. Don't forget that everything varies between countries. With all that let's create a financial statement for eg Walmart (who has every line item sold posted to SAP system when you buy things at store)
- ericpauley 3y ago> Walmart (who has every line item sold posted to SAP system when you buy things at store) Shudders
- vezuchyy 3y agoOn the other hand, people who work on that don't think GPT will make them jobless. Also, I recall how a major client postponed adoption of a new reporting platform because it meant for them layoffs in accounting department and accountants started to sabotage the whole thing...
- JensRantil 3y agoI work in the Carbon Accounting space where the accounting is used for carbon emissions.
- infogulch 3y agoDouble-entry bookkeeping is the original CRDT. Just by maintaining a local invariant -- debits and credits in a transaction sum to zero -- a distributed network of agents attending to their own ledger can reliably maintain a global consistent state (like, money is neither created nor destroyed), or heal it in the case of corruption.
- poslathian 3y agoCame here for this comment. I’ve always kept an eye open for anyone who has applied this insight to something. There is something also satisfying about how accessible accounting is vs any other domain you encounter invariants (like noethers theorem, group theory, or equivariant neural networks)
- lurkingmba 3y agoThe article is wrong in at least one important respect. Debits do not always increase the balance of an account. Accounts can have either a natural debit balance or a natural credit balance. Credits actually increase the revenue account, which is a pretty important one!
- hacker_88 3y agoBlock chain should solve any issues relating to accounting
- kazinator 3y agoDouble-entry bookkeeping is inferior to N-entry bookkeeping, whereby a transaction generates N entries, that sum to zero. Multiple dual-entry transactions are needed to record a single N-entry transaction which is clumsy and harder to follow. Also, by the way, the whole debit/credit thing in English-language accounting is supremely idiotic: a credit is an increse in this account, but a decrease in this other type of account? What? It's purely for job security for accountants. There are accounts which represent outside interests/stakes in the company. Then there are accounts which represent what the company has. The outside interest accounts run negative (under normal conditions). An interpretation of that is that the company owes what it has to the outside interests. The sum of all the accounts is zero. The outside interest accounts go negative when the company grows. E.g. $100 added to cash (account representing what the company has) might be balanced by a -$100 into the owner's equity account. The company owes $100 more to the owner. If the $100 came from a bank, then rather than the equity account going down by $100, the account representing that bank or loan (outside interest) would go down by $100, more negative. If the company buys some equipment for $100 for cash, then -$100 goes into cash, and $100 into assets. When that asset depreciates, turning to $80 dollars a year later, -$20 goes into assets, and $20 into owner's equity, bringing it closer to zero.
- lexszero_ 3y agoI'm surprised that there are no mentions of a great hacker-friendly plain-text accounting software called `ledger` https://ledger-cli.org/ https://ledger-cli.org/ in this thread. It has amazing documentation when it comes to understanding basic principles of double-entry bookkeeping and goes through many typical situations and usecases. There are also several forks, most popular and advanced is `hledger` https://hledger.org/ https://hledger.org/ (h is for Haskell), which provides some neat features out of the box, such as a simple web interface. All of them are very primitive compared to "professional" accounting software, but in return it offers great opportunities for hacking around while ensuring validity of your books.
- xyst 3y agoNot a fan of people changing the terminology used in a domain. It confuses people in the domain (accounting) and makes their lives just slightly more harder. Keep in mind, sometimes the software you write is pushed hard by the incompetent CIO that “wAnTs To ReDuCe ToOlS” or gets a kickback from the vendor. That person doesn’t have to deal with it on a daily basis but the poor workers have to deal with this shite software. The impression of that poor software reflects poorly on the rest of us.
- adius 3y agoI've been preaching to use a simpler accounting system for years and even built my own tool for it: https://github.com/ad-si/Transity https://github.com/ad-si/Transity But so far with little success. I think I’m the only active user of Transity.
- flaminHotSpeedo 2y agoSomething's been bugging me about this article (besides the fact that it's explanation/examples of double entry ledgers are either bad, misleading, or wrong, depending on your perspective), and I wasn't able to put my finger on it until just now: There's a way easier way to explain double entry bookkeeping for the article's target audience, it's just statics for accounting.