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.
My 100-level accounting instructor said it pretty succinctly: Debit means an entry in the left column. Credit means an entry in the right column. What a transaction means for the business depends on the accounts.
The terms debit and credit have meaning independent of their columnar position on a traditional ledger. I could create a ledger with the columns reverse or (shocking!) use a computer program with a data structure that doesn't encode the concept of left or right.
I think about it like this:
CR / Credit / Creditors -> what the business owes
DR / Debit / Debtors -> what the business owns
A common objection to this is 'what about income and expense accounts'? But those are just equity: https://news.ycombinator.com/item?id=39991837
I wrote more about this here: https://news.ycombinator.com/item?id=32498992
But that just shifts the arbitrariness of the whole thing from the words "debit" and "credit" to the words "left" and "right".
Dr accountX £100
Cr accountY £90
Cr accountZ £10
I love it, let's do it!
Thank you this is very helpful.
The whole credit/debit terminology usage here is incredibly confusing to someone who hasn't studied accounting and many of the comments and replies to people who are confused are, while technically correct, simultaneously, unhelpful - to those not familiar with the terminology.
I read a comment earlier: "Why would my bank account be debited when the balance went up? Is a debit not negative? Is the cash balance presented as a negative?" And thought: "Yes! Great question! This doesn't make sense..because debits are always negative right? A direct debit takes money out, you spend money using a debit card, a debit is a debt right? So debits are always negative and debiting is always minus-ing money..." - but the replies, while technically correct weren't satisfying at all because they assumed knowledge.
It's both amusing and frustrating to watch people effectively speaking past each other like they're talking a different language. Especially when you have the same perspective as the person who is confused and trying to seek understanding. It seems like people nitpick on small points of what was said seemingly in order to be right.
Assets + Expenses = Liabilities + Equity + Income
What if we re-arranged the equation to:
Assets - Liabilities = Income - Expenses
You can then ditch credits and debits and ask - what is the impact of this financial transaction on my net worth? The equation will tell you which accounts should go up and go down using positive and negative numbers.
I go more into how this works here: https://news.ycombinator.com/item?id=39994335
What would you suggest as an improvement? The article suggests "incoming" and "outgoing" which seems to have the same issue, as does everything I see in your comment (the person spending 5$ on lemonade sure as hell isn't putting 5$ in their accounts sales entry).
I'm not fully understanding the confusion both here and in the article.
Use the intuitive meaning of the words: a credit means you have money coming in, a debit means you have money going out. An increase in assets, income, or equity is a credit, and an increase in expenses or liabilities is a debit, and vice versa.
Or, alternatively, just use "credit" for any increase, and "debit" for any decrease. But this:
"Definition 6: Credit - An entry that represents money leaving an account."
is just totally backwards.
Examples:
If you deposit money into a checking account (asset) that is a debit (account increases) because the money "goes to" in that account (destination).
If you borrow money from a credit card (liability) that is a credit (account increases) because the money "comes from" that account (not destination).
The hard part is remembering debit accounts increase with debits, and credit accounts increase with credits.
"Credit" means "source", "debit" means "sink".
Suppose you invoice a customer 10,000 euros. You now have a promise for 10,000 euros, but you account in dollars so it's a promise for 11,000 dollars at current exchange rates. So you credit the source, your "Income: Customer A" account ("income" and "expense" accounts represent the external world) $11000, and debit "Assets: Accounts Receivable" (an account for trade-credit promises like this) $11000.
Later, the customer pays your invoice, which gets you $10,500 because exchange rates have moved around. How do you account for this?
Your promise, which you accounted as $11000, is the source, so you credit Accounts Receivable $11000. You debit cash $10500, because you got $10500 in cash. Finally, credits and debits have to balance, so you debit "Expenses: Loss on Foreign Exchange" $500. (recall that "expenses", like "income", represents the external world, and you lost the other $500 to forex traders or whatever.)
Since you don't liquidate the business on any typical day of its operation, why would you attempt to figure out how that $500 fits into a hypothetical instantaneous liquidation when you could just... account for it by balancing credits with debits? (You do sort of instantaneous-liquidate when preparing financial statements, an infrequent task which is very mechanical compared to ledger entry.)
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.
I find it easy to just think of debit as adding to the left and credit as adding to the right. Their definitions are always the same that way.
To simply write that, "Bob's account has a credit of $12 and a debit of $7" is timeless. That sentence can go anywhere, and always be explicitly correct. It is context-free grammar: the same category that all programming languages belong to. Because a programming language is context-free, it can be perfectly understood (and translated) by a parser and compiler. Because statements using the nouns "credit" and "debit" are context-free, they can be perfectly understood as the data they represent.
> 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.
On the contrary! Their definitions are always the same. They apply specifically to the account you are talking about, because they are that account: an account is a list of credits and debits.
The reason that people get confused is that we are used to using verbs like "paid" and "earned". When we use verbs, the data is the transaction, not the account. When we use the nouns "credit" and "debit", the data is the account, and not the transaction. Most people are introduced to these words with "credit card" and "debit card". That was the mistake, because cards are used for transactions, which is precisely the wrong context to use these words. It would have been much more clear to talk about "crediting cards" and "debiting cards".
(I'm 80% sure that the above reads that Bob actually owns $5 he can spend. But I'm equally sure that I get Debits and Credits backward, so I probably read it wrong.)
In any case, you've only described a single account at rest. You need to go one step further and describe an entire transaction in those terms, so that someone can swoop in and say "you got it backwards".
Assets + Expenses = Equity + Income + Liabilities
Sum of all debits = sum of all credits
These two equations have their sides associated.
Assets and equities increase with a debit and decrease with a credit, and vice versa.
I'm with you so far.
> the goal is to keep the accounting equation true at all times
Perfectly reasonable.
> For example, you sell a lemonade for $5. You add $5 to Sales (Income) and add $5 to Current Account (Assets).
And now you've completely lost me. Money appeared. Lemonade disappeared. I want to see the corresponding +$5 and -$5.
Making it fit the equation (Equity + Income + Liabilities = Assets + Expenses) is not an intellectually satisfying reason for 'Assets' to go up by $5 when I just lost $5 of assets.
What if it worked this way in physics?
I could write
Force * mass = acceleration
1N * 500g lemonade = 0.5 m/s/s
1N * 1000g lemonade = 1.0 m/s/s
If I understand your comment correctly, where you're getting confused is, you're reading Current Account (Assets) to mean your inventory of lemonade. What they actually mean in this case is money moved from Income to your Assets (e.g. your cash register). That's why assets went up in this example.
Of course for your lemonade business you might keep track of your lemonade as well (which I think is what you're talking about when you refer to assets). The lemonade sale would then lead to a decrease in your lemonade asset and and an increase in your expenses (cost of goods sold), so the right hand side of the equation balances.
So when selling lemonade there are actually 2 things happening:
1. Your income and your assets (your amount of cash) both increased. Income and Assets are on different sides of the =, so the equation still balances
2. Your lemonade assets decrease and you incurred the cost of that lemonade as an increase of your expenses. Those are both on the same side of the =, so the equation still balances.
As a neophyte: "credit" and "debit" make me think I'd need both entries to do books at all.
The way you've written it makes me think: "Oh, this is just single-entry accounting for people who aren't careful like me!"
So perhaps historically there was value in misusing terminology sufficiently to cause people to people turn off the optimizing compiler in their brain so that they just learn and do it correctly from the beginning?
Edit: clarification
State Accounts track your net worth
Assets: what you own
Liabilities: what you owe
Income: what you've earned
Expense: what you've spent
Assets - Liabilities = Income - Expense
Taking out a loan is +$10 Asset balanced by +$10 Loan. In the equation: $10 Asset - $10 Liability = $0.
In general, say you have a +Asset action, to balance the equation you can do it 4 ways:
+Asset -Asset aka swapped for equal value
+Asset +Liability aka took out a loan
+Asset +Income aka sold something
+Asset -Expense aka got a refund
This is the system we've implemented in our ledger API (https://fragment.dev)
[1] https://beancount.github.io/docs/the_double_entry_counting_m...
So if you take out a loan to buy lemonade: +$5 to expenses, -$5 to liabilities. If you sell lemonade: -$5 to income, +$5 to assets. You just have to remember that equity, income and liabilities will be negative so flip them if you want to answer questions like "how much do I owe?"
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.
If you're building payment rails, that event might itself be one of a pair of events, sourced from a meta-event tracking the transaction intent. (As a meta-point, I find it much more useful to think of the "graph" in accounting as having edges not made of money, but of data in a derived-event hierarchy.)
And a first step towards being able to have that mental model is ensuring that you have a good mental model of multiple physical-human actors accumulating events in a structured and atomic way.
But the OP doesn't actually make it clear that this is what the analogy is in service of! And I fear that the OP article will cause more confusion than it solves.
No, the number of accounts (actors) does not have to be even. The sum of debits and credits has to be equal (or zero if you like).
Unfortunately, QuickBooks won't help you understand accounting. It's not a true double-entry accounting system, at least it wasn't the last time I touched it. That said, it still does its job and does it well enough, and real accountants are fine with dealing with it.
Simply Accounting is a better example of a true double-entry system.
and bob is not even doing any bookkeeping. he is bookselling ;-)
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
- where has it come from/has it forever gone? - where is it now?
So, you start a simple ledger of having $100 in cash with a transaction like this:
Dr "cash" Cr "original funds" $100
Dr "food expenses" Cr "cash" $25
Dr "loan to Bob" Cr "cash" $20
Dr "cash" Cr "loan to Bob" $20
Dr "cash" Cr "interest income" $2
Some of the accounts, like "original funds", aren't very useful by themselves, but they are the only way to make sure "money I literally have in my account/pocket", "money I owe people" and "money that people owe me" can all be counted together: if you tally up both kinds of the accounts, the total sum should be the same, just with the opposite "sign".
How would you salvage the article to actually explain the "double" part in detail? Could you do it purely from Bob's (or Alice's) perspective?
If Alice purchases a house worth $100,000 in cash, then 2 (double) accounts will get effected. Her cash account will decrease (Credit) by $100,100 and simultaneously her House equity account (or any other appropriate name such as immovable asset etc) will increase by $100,000 (Debit).
This can be recorded in a 3 column table as
Credit account -- value -- Debit account
Cash -- $100,000 -- House equity
Note: 1. Debit and credit dont have much to do with increase decrease. 2. A transaction can be modelled to have affect more than 2 account. For example if Alice were to make the purchase with $80,000 loan, then the book keeping could go like
Credit Lender $80,000
Credit Cash $20,000
Debit House Equity $100,000
Transaction one ->
Credit Lender $80,000
Debit Cash $80,000
Transaction two ->
Credit Cash $100,000
Debit House equity $100,000
You can think of it as “conservation of value”, so you can’t just create money out of thin air in your payment service (credit), without tying it to some account with a corresponding debit.
This originally was intended to protect against typos; eg write a 10 instead of 100, at the end of the day your ledger needs to balance. In software typos are less likely bit it still provides auditability to prevent a large class of bugs from wiping you out.
So to be clear, there are 4 accounts. Bob's Money, Bob's Books, Alice's Money, Alice's Books.
Because these two homeless librarians only have money and books, you can add the two balances together for each person to get their net worth.
If Alice owns 3 books worth $120, then the "Alice's Books" account would show a balance of $120. Meanwhile, Bob has 12 books worth $700.
When Alice buys the books, she -credits her bank account $20 and +debits her books account $20 (the value of the new book). Thus her net worth stays the same, but she has more books assets and fewer cash assets.
Similarly Bob -credits his books account $20 and +debits his bank account $20. His net worth also stays the same but he now has more cash than before.
On Alice's way back to the bridge she resides under, it starts to rain. Alice's new book is ruined. She -credit's her books account $20 and her net worth goes down by $20.
Life as a homeless librarian is harsh.
- one for the assets/liabilities account involved in sending or receiving the money ($30 credit, bank account) - one for the income/expense account to which the transaction corresponds ($30 debit, "education" expense account)
one of the two entries is a credit and the other a debit
I'll give a description shot, since I've been doing finance work recently. Other people can feel free to correct.
A company using double entry (as opposed to single) has a "chart of accounts." This means they have a bunch of imaginary accounts for tracking everything, including:
- Assets (e.g. cash on hand.)
- Liabilities (e.g. loans)
- Equity (e.g. investments in the company from outside parties)
- Income/Revenue: (edit: as PopAlongKid kid mentioned, I forgot this one. This could include sales revenue, but also things like interest.)
- Expenses (e.g. team lunch or a flight cost)
Some of these "accounts" may map to actual bank accounts: there is likely a liability account for a credit card or an asset account for the company checking.
Knowing all that, every time money is deposited or withdrawn (a transaction) the "double" references the fact that it's recorded in the journal (a.k.a ledger) of two accounts. (Edit: As bregma mentioned, one records where money is coming from and the other where it's going.) Often, an expense is often recorded in the checking "account" and the and the corresponding expense "account." E.g. a flight may be recorded in a travel expense "account," but you also record that the money came from the checking account. Every transaction is recorded in two places.
Beyond just being more accurate than single entry, this helps with important finance reports like Profit & Loss, since you can now see how money is moving around.
Edit: Now that I'm back on my desktop, these are a couple of useful links for understanding basic double entry bookkeeping: Accounting for Computer Scientists [0] and Accounting for Developers, Part I | Modern Treasury Journal [1]. What is a Sample Chart of Accounts for SASS Companies [2] illustrates some charts, which may be helpful for some folks.
[0] https://martin.kleppmann.com/2011/03/07/accounting-for-compu...
[1] https://www.moderntreasury.com/journal/accounting-for-develo...
Money can not be created out of thin air, and it can not be destroyed. Every movement of money has to be accounted for, which is why it's called "accounting". Double-entry accounting means you have to account for where the money comes from, and you have to account for where it goes, and each of those is a separate entry and it all has to add up to zero.
Where it can become confusing is when money leaves you or comes in from an external source. There are still two entries, but one entry is in one party's books and the other entry is the other's. For example, I get a paycheque and I enter my income in a little book with green paper and DB/CR columns. At the same time, my employer has entered an expense in their book. Double entries.
From an individual account perspective, there's a doubling of the number of columns you could enter a transaction's amount into.
$100 appears in your account. That’s one part. The other part depends on why.
* you moved money from another account, the double is -100 in that account.
* you sold stuff, +100 in income.
* you borrowed some money, +100 in ‘debt’.
In a physical book each of these categories would have a left and right column, and each transaction has numbers in one left and one right column. Or in many columns but the sums of left vs right columns must be the same.
https://www.investopedia.com/terms/a/accounting-equation.asp
For example, a bank might decide you likely can't pay your loan and write it down to zero. You might still have the liability on your books because you plan to repay it. They'll make the relevant entries in their system (and the debits and credits will balance) and you'll do nothing (which balances).
Double entry bookkeeping has zero to do with other entities. It's solely about your own books.
[0]: https://www.winstoncooke.com/blog/a-basic-introduction-to-ac...
Therefore (and to your point) the observation is of limited usefulness.
What if Alice does double-entry bookkeeping but Bob does single-entry bookkeeping?
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
[2] https://en.wikipedia.org/wiki/History_of_accounting
[3] https://en.wikipedia.org/wiki/History_of_ancient_numeral_sys...
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.
You don't need negatives in accounting, because anything that is affecting a number differently than the rest (reducing rather than increasing), needs to be accounted for separately. Imagine showing negative revenue. That would be mostly useless. You want to see how much revenue you had, and in a separate entry, how many expenses. Imagine how misleading it could be to show $0 in expenses last month, when in reality, you had $100 in expenses, but you subtracted $100 out because you returned some big purchase from last month and got a refund.
* you can actually think of oddball reasons you might consider a "negative credit/debit", but it's more akin to something like a negative mass in physics
There are many important aspects of organisational design that are only loosely correlated with financial statements.
It was only after bookkeeping became ingrained into all levels society that negative numbers were considered equally real as positive numbers.
That is very different from understanding concepts like owing someone money, which is a form of negative.
Chinese and Indian mathematicians and accounting from Babylonian times didn't have the same mental blocks.
The Bakhshali manuscript is still the first known example of modernish notation I think, but used +
It can also obfuscate it pretty well!
[0]the third basic type of statement, in addition to balance sheet and profit & loss.
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.)
This is a bad design, please don't do this.
The better design is to have header and detail tables:
Header: TransactionID, Date, Description, (other fields as required, e.g., posting status, reconciliation status, etc) Detail: TransactionID, LineNumber, Account, Amount, Description, (other fields as required, e.g., reference numbers for subledgers, etc)
This allows a transaction to affect any number of accounts. In effect, the transaction ends up reflecting a business transaction which may affect many accounts.
You're adding an abstraction to enable more flexibility and functionality. That doesn't change the fundamental event-sourced nature of totals.
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.
> 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
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/).
As far as I can tell, the point is to double the amount of work in the hopes of catching certain kinds of errors. Which makes sense when you have humans making the entries and humans doing the arithmetic.
But I grew up in a world where computers do all of the math, and it always looks to me like it's violating the Don't Repeat Yourself principle. If you say the same thing in two different places, one of them is always going to be wrong.
I feel as if, had accounting been designed in the modern era, we wouldn't have done it that way.
I'm not an accountant and my failure to understand does not make the thing wrong. But my bafflement at "credits decrease an asset account" feels emblematic of something being genuinely off base.
This is wrong on a couple of levels.
In your understanding do RAID disk arrays and backups violate “the Don’t Repeat Yourself principle”? Is one of the copies of the data guaranteed to be wrong? Do data backups duplicate data because of pre-modern thinking?
But on another level it’s irrelevant, because in double-entry bookkeeping, there is no duplication of information. If you buy an apple for a dollar, your journal entry will mark a dollar out of cash — which is true because you now have 1 less dollar — and a dollar against your “Food” expense account — which is true because the thing you just spent a dollar on was food. If you took away either entry, you would be losing information. The fact that both entries have to balance isn’t because of duplication, it’s because the same dollar can't exist in more than one place at a time, which is axiomatically true regardless of whether you use a computer.
The fundamental unit of a double-entry system is the transaction, which records from where things came and to where they went. In software parlance, it's an event-sourced system rather than the stateful/interactive system of single-entry accounting.
In double-entry, you’re tracking two different things: - Your current net worth. These are tracked in State accounts (Asset and Liability). - The reasons your current net worth changed. These are tracked in Change accounts (Income and Expense).
Say $5 enters your bank account, that’s recorded as an increase in an Asset account. Whether your net worth changed or not depends on the reason. There’s lots of reasons that could have happened, and that’s recorded as the second entry: - Took out a loan: increase in Liability (no net worth change) - Got paid back for a loan: decrease in Asset (no net worth change) - Sold something: increase in Income (net worth did change) - Got a refund: decrease in Expense (net worth did change)
I agree that re-engineering accounting is necessary for software engineers to build financial systems. I think it’s time to ditch credits and debits and instead deal in State and Change accounts with negative numbers.
PS I go more into it here: https://news.ycombinator.com/item?id=39994335
I think this is meant mostly to apply to code. For data, redundancy is a very common strategy for assuring accuracy and durability.
> If you say the same thing in two different places, one of them is always going to be wrong.
Yes! This is the exact point. The mismatch flags that there is an error that needs to be investigated and added to the ledger as a correcting transaction.
That's also how I like to think about it, as a kind of checksum mechanism. Double-entry bookkeeping originated in medieval European markets, which were often open-air, noisy, dirty, full of thieves and other dangers. Keeping your records straight in that environment must be a challenge, and having a logic that allows you to catch some mistakes can be a powerful tool in that context.
But there's more to it, eg it allows you to make a distinction between expenses and investments, so it is actually a truly different way to think about your financial situation than eg looking at cash flows only. Spending X on a buying livestock has a different economic meaning than spending X to pay a security guard. There are economic historians who argue that this kind of perspective was an enabler of early capitalism, because it enables people to see that money spent on an investment isn't lost value.
Not really, the meaning of debit and credit depends on the type of account
EDIT: see this link for how this relates to the accounting equation https://news.ycombinator.com/item?id=32501707
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.
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!
[1] https://martin.kleppmann.com/2011/03/07/accounting-for-compu...
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.
Let me know if it doesn't work for you!
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.
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.
I don't understand how describing debit/credit (accounting jargon) in layman's terms smacks of jargon, but maybe that is because I am a layman =)
As someone with no accounting background, credit/debt described as "money go in, money go out" seems like a good enough explanation in the context of this post.
Do the "true" definitions of credit/debit differ from that in a meaningful way here?
> A debit decreases assets or increases liabilities, while a credit increases assets or decreases liabilities. [1]
> A debit is always used to increase the balance of an asset account, and the cash account is an asset account. [2]
[1] https://xendoo.com/blog/debits-and-credits/ [2] https://www.fool.com/the-ascent/small-business/accounting/ar...
It's not just that they're a bit confusing, it's that those words serve exactly one purpose, which is to disambiguate the exact thing that people find confusing about them.
The biggest indicator of their failure is that they are always explained in terms of something clearer, and the reverse it not true. No-one says: "I don't understand what 'we received $50' means, can you explain that in terms of credits and debits?"
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.
[1]: https://www.reddit.com/r/plaintextaccounting/comments/1bh3x7...
Interesting context on negative numbers, thanks for that!
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?
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.
I wish OP included a working project that lets one ingest a ledger, producing a graph. Perhaps this graph view might be used for "forensic" purposes, where a one-line entry buried deep would stand out as an odd node?
Still a hard sell with only one very basic example provided -- especially in a domain that's been around forever and where any advantage is critical. The DE ledger seems like a basic, simple tool, iterated into perfection over millennia. You'd think you could improve it, but good luck if you try.
Engineers stumbling on foundational principles baked into other fields that software happens to be replicating.
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.
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).
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.
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.
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?
I believe this same plain text format is used by other tools, which you can find info about here: 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/
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.
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.)
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.
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
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
[0] http://collegecatalog.uchicago.edu/thecollege/economics/#Fun...
I think this is yet another good example of thinking with double entry bookkeeping.
[1] https://www.investopedia.com/articles/investing/022416/why-b...
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)
Shudders
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.
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.)
- 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.
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
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.
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...
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.
There's a way easier way to explain double entry bookkeeping for the article's target audience, it's just statics for accounting.
Thank you!
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-requirem...
[1] https://guac.sh
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.
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.
Events being constrained to historical statements of fact.
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 :)
But so far with little success. I think I’m the only active user of Transity.
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.
Credits actually increase the revenue account, which is a pretty important one!
- 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.
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.
The impression of that poor software reflects poorly on the rest of us.
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.