Sometimes non-accounting people get hung-up on the words "debit" and "credit" and think they have to do with "owing" or "being owed" money. The effect of a debit or credit on the business depends on the accounts in the transaction and debit and credit don't have anything to do with the "direction" of a flow of money.
My 100-level accounting instructor summarized it as: "A debit is the entry in the left column, and a credit is an entry in the right column." Without the context of the specific accounts being debited or credited the terms themselves mean nothing.
Aside: A 100-level knowledge of accounting can confer near "super powers" when it comes to dealing with finance and accounting people. Double-entry bookkeeping is one of the oldest and longest-practiced "IT" disciplines. Your work probably touches revenue / expenses for your employer and someday you'll need to interface with accounting or finance people. Being able to speak the language, even poorly, has helped me gain trust and credibility that I don't believe speaking only in IT terms would have.
Debits and credits is the only way to give your team a common, consistent "language" for dealing with money, and being able to speak this language as a dev gives you superpowers.
Accounting was invented before negative numbers. Because of this, instead of counting money as positive or negative amounts, it uses the debits and credits. Instead of subtracting funds from one account and adding them to another, we talk about crediting one account and debiting another.
But it’s the 21st century and we have negative numbers now - why not just use positive and negative numbers? Using positive and negative numbers gets ambiguous.
If your app lets Alice sends Bob $5, we remove $5 from Alice’s account and add $5 to Bob’s account. So it seems fair to say that if both user accounts started at $0, Alice’s balance is -$5, and Bob’s balance is $5. Let's represent it that way in your DB.
Your CFO would disagree. From your company’s perspective, what these balances mean is that Alice owes you $5, and the company owes Bob $5. In other words, if the company went out of business tomorrow, you'd have to go out to collect $5 from Alice so that you could give Bob the $5 he rightfully thinks he’s holding inside of your app. Wouldn’t it be more logical to show Alice’s balance as $5 and Bob’s balance as -$5?
It gets even more confusing if your software deals with financial instruments like loans, investments, or invoices. Dealing with every balance in your application as a simple positive or negative number gets really confusing, and will cause both ledgering issues and communication breakdowns between your eng and financial teams.
> But it’s the 21st century and we have negative numbers now - why not just use positive and negative numbers? Using positive and negative numbers gets ambiguous.
In computerised accounting it is completely normal to use negative numbers for credits and positive numbers for debits. That way a whole trial balance sums to zero. Very neat indeed.
What is missing above is the concept of accounts to put the balance in. For instance if I have a loan I put it in an account called 'loan', and list it on my balance sheet as a creditor. It will always have a negative balance. If it doesn't there is a problem.
Alice from above owes me 5 bucks so goes in the debtors (or receivables account).
I owe bob five bucks it goes into creditors (or payables)
One classic piece of error checking is to review debtors for credit balances. It means someone has overpaid, needs a refund or screwed up posting it.
What you're describing is accrual accounting (accounts payable/receivable). It is one method of bookkeeping, but a lot of other businesses tend to use cash (which deals in absolutes, you spent 5, you earned 5, etc).
Not sure what you mean, as far as I know the government requires businesses to pick one form and stick to it. Unless you're building accounting software you'd have no need to support both ways.
That's like choosing whether +x is a rightward or leftward facing coordinate axis. You can still use negative numbers, but you have to indicate whether positive means left or right. See also: positive and negative longitudes vs. east or west longitudes.
But it’s the 21st century and we have negative numbers now - why not just use positive and negative numbers?
Because debit and credit may be looked at differently in fee calculation. You may not be able to un-debit the same amount easily. This is just a historical/established practice, but you cannot squash the two into +/-, because you would lose “cancellation” in cases when a mistake is discovered but the quarter is done and already git-pushed to IRS/etc. See “storno (accounting)”.
>Wouldn’t it be more logical to show Alice’s balance as $5 and Bob’s balance as -$5?
That wouldn't make sense. Alice sent Bob $5, so now Alice's balance would be $5 and Bob's would be -$5? The amounts should display their balances within the app, and Alice and Bob should have their own personal balances which are independent of the app's. Before the transaction, both Alice and Bob were at $0 on their personal balances and afterwards they were still at $0, since neither of them had more dollar bills on their persons. The difference between their personal balances and their balances in the app is the value you're alluding to. $0-(-$5) for Alice and $0-$5 for Bob. This difference could be interpreted as the amount that each owes to the app (positive for Alice because she owes and negative for Bob because he is owed).
I agree that from a developer's perspective and certainly in the frontend it doesn't make sense to show a positive user balance as negative. But to a finance team, cash on your company's books (debits) needs to have the opposite polarity of money that your users hold (credits). My underlying point is that it's really hard to make that the case without using the credits and debits language.
This little comment chain has done more for my understanding of accounting than at least 3 hours of reading online and trying to have my accounting friends explain it.
>But to a finance team, cash on your company's books (debits) needs to have the opposite polarity of money that your users hold (credits).
Then you're arguing how the value should be displayed. There's no reason to prefer one sign or the other in the codebase, as long as it's always displayed correctly to the correct actors.
Having been involved in various roles of double entry accounting adjacent tools, the next level up is realizing that it is easier to display the correct sign if you store things unsigned and use debit/credit nomenclature even in your DB model/codebase. It's not just that this makes it easier to talk to the accountants using your system about the internals of that system, but that showing the right sign becomes simple "pattern matching" based on entirely on the type of account and the user's type. There's no "math" involved to switch signs based on how it is "stored" in the codebase, the displayed signs are always a UI element that is clearly dependent on its inputs.
The centuries of accountant's aversion to using negative numbers in day to day accounting usage has abstraction uses even in your codebase.
> Accounting was invented before negative numbers.
Counting was invented before negative numbers, but "double-entry accounting", which is what people refer to when they say debit and credit, was only invented in the 18th century, IIRC.
> > Without the context of the specific accounts being debited or credited the terms themselves mean nothing."
> This seems incorrect to me.
You can't derive the change in assests, liabilities, or equity without know which accounts are being debited and credited. The terms "debit" and "credit" themselves don't tell you anything by themselves. Without the context of accounts the terms are meaningless. I think programmers get hung-up on thinking that they have meaning in isolation (i.e. thinking that "a debit means somebody owes us money").
> I think of it as 'owing' (liability) or 'owning' (asset).
> When you credit an account, you either increase what you 'owe' on that account OR decrease what you 'own' on that account.
That's my point. When you know they type of account being debited or credited you can reason about how it affects the balance of the account and the managerial context of the transaction (i.e. "somebody owes us money because the debit was to a receivable account").
"When you know they type of account being debited or credited you can reason about how it affects the balance of the account and the managerial context of the transaction"
This is true, but it doesn't negate my point (that debit and credit have meaning independent of the type of account).
I know this because I have used the principle many times in practice, to define charts of accounts, to define rules for posting different types of transactions etc.
I think we're talking past each other but I'm not sure how to rectify.
Given a debit of $500 and two matching credits of $250 how is the owner's equity position affected?
A programmer, unfamiliar with accounting, might think that "debit" and "credit" carry enough meaning in this context to answer the question.
You and I know that without knowing what account types are being debited and credited we have no way of explaining what the managerial result of that entry is. That's an unanswerable question w/o more context. That's my point.
"I think we're talking past each other but I'm not sure how to rectify."
Let me give it one last try :)
You're claiming the truth of two propositions:
A) Without the context of the specific accounts being debited or credited the terms [debit and credit] themselves mean nothing.
B) Without the context of the specific accounts being debited or credited we have no way of explaining what the managerial result of that entry is.
I agree with B, but do not agree with A.
When an account is CREDITED, this always represents an increase in liabilities[0] (or equivalently, a decrease in assets).
When an account is DEBITED, this always represents an increase in assets (or equivalently, a decrease in liabilities).
The two statements above are true as written. If you were to exchange the capitalized text (turning CREDITED into DEBITED and vice versa), the statements would no longer be true. Therefore credit and debit each have some distinct meaning.
[0] I treat 'shareholders equity' as being a liability in favour of shareholders
> When an account is CREDITED, this always represents an increase in liabilities[0] (or equivalently, a decrease in assets).
> When an account is DEBITED, this always represents an increase in assets (or equivalently, a decrease in liabilities).
This is where you're wrong. You can credit and debit Accounts Payable and Accounts Receivable. If you credit AP, you're increasing liability, if you credit AR, you're increasing assets.
Your link shows that AR is a subaccount of Assets and AP is a subaccount of Liabilities, so credits to each have the opposite effect with respect to a balance sheet. GP has a different understanding of the "polarity" of debits and credits, but if anything this seems to support rather than undermine proposition "A" above?
"so credits to each do indeed have the opposite effect with respect to a balance sheet"
I think what you mean here is that a debit balance in an asset account is presented as a positive amount, whereas a debit balance in a liability account would show as a negative amount.
This is true, but that doesn't mean a credit has the opposite effect depending on whether it's applied to an asset or liability account. Consider that you have two different accounts with your bank:
- a current account (usually the bank owes you money, i.e. usually a credit balance from the bank's POV)
- a loan account (you bought a car on credit, and owe the bank money, i.e. a debit balance from bank's POV)
For the bank, the current account is a liability ($1,000) and the loan account is an asset ($25,000).
When you deliver a bag containing $5,000 to the bank, the bank will credit one of these two accounts. They'll either increase the current account to $6,000, or decrease the loan account to $19,000.
In either case, the credit has the same effect: your net debt to the bank is decreased by $5k.
rahimnathwani is correct here and has explained himself well. I generally don’t think of equity as a liability, but if you think of it is money owed to shareholders, then a credit can indeed be seen as an increase in money owed. Since debits always equal credits,
I prefer not to ascribe semantics to accounting credit/debit - only thing that matters is it is consistently applied and balances out.
I think of this as being similar to primary key constraints - my rule is primary keys should not have a business meaning. I have walked into many situation where they would have implemented so - and usually will fail to convincing them otherwise.
...my rule is primary keys should not have a business meaning.
OMG I so agree with this. I worked at a company where we wasted so much time, and moved so much more slowly, just because some previous technical person hadn't completely thought through the implications of ever including primary keys on the GL feed. The whole time I was there I begged the accounting drones to forget about this concept, repeatedly enlisting the marketing department who claimed to believe that velocity was a good thing, but I too failed. Eventually I realized that if we didn't give them primary keys they would have to lay off multiple people whose only function was to look at primary keys. Instead I should have invested more effort in programmatically generating the database entries that drove this whole boondoggle.
Not the first, and also not the last, place I worked where the CFO could have been the least honest person in the building.
It certainly depends on if you are working with natural keys or artificial ones. Somewhere in the decades of applied relational calculus we lost sight of natural keys and what those even are. In part because they are hard and it turns out that few natural keys seem to exist "naturally" in real life because everything is mutable, everything is a ship of Theseus, names/addressses/everything changes. So we've turned to artificial keys for primary keys and out of momentum most of these artificial keys are simple auto-incrementing numbers and a dumb part of brain looks at simple auto-incrementing numbers and thinks "I understand these" and "I see the patterns in these" and runs off and starts using them everywhere for business logic and corporate procedure and potentially information disclosing URLs and so forth.
(And then simple auto-incrementing numbers turn out to be not so simple indeed the first time you need to shard or otherwise decentralize your database for whatever reason.)
I don't think there's an easy answer here. We can't return to the ideal of natural keys, because reality has shown that's a pipe-dream. We can focus on using more artificial primary keys that don't look like simple auto-incrementing numbers like GUIDs and Snowflakes and ULIDs and string slugs and more, but those aren't without overhead or tradeoffs both at the database level in the raw and in the user experience and these business processes that we don't want to use our raw database IDs but we can't just give a more natural equivalent either. ("How can I refer to Issue 6D038E7E-A0D8-45EB-AAC6-1E3FEC9DA5B8 on the phone or in a meeting?" "How can I excel spreadsheet my way through the system's data without being lost?" Etc and so forth. On the one hand it feels like a failure in the system if so many processes still need to work outside of and around the system, but on the other hand humans and businesses are social creatures and these side processes arise naturally like breathing to that combination of humans inside a business.)
This is correct. There are some sensible business defaults, but pure debit and credit have no specific meaning. It’s just yet another analytical dimension handily entangled with double-entry.
This fact is rarely mentioned in business talks so people have a whole variety of ideas what they mean, as you can see itt.
> I prefer not to ascribe semantics to accounting credit/debit
I think most people agree with you. They prefer to memorize some rules, or just look them up. Personally, I find having a simple principle helps me reason about new situations (new transaction types).
> Debits/credits concepts can exist (and we can operate on them) without the existence of left/right columns.
Taking this as sympathetically as possible - which is tough - because do you really think the person you are replying to on this forum with the given response does not understand principles in the abstract?? This really is quite condescending.
The entire point of a statement like this is that debit and credit are fundamentally abstract - such that when they have no essential features above their effect on the account.
I mean did you bother to read the clarifying following sentence before you selectively quoted?
That seems uncharitable - the person you're replying to is saying that debit/credit are more than fundamentally abstract, and that they have conceptual meaning consistent across all accounts.
> conceptual meaning consistent across all accounts.
Except programmers quite often get the conceptual meaning wrong and incorrectly generalize further. Credit and debit just mean increase or decrease in account balance. You cannot know how it affects liabilities or assets without knowing what type of account is being modified.
That’s because the system is not built by programmers. Some accounts (that’s accounting accounts, not bank accounts) are positive for you and some are negative. You need to know what kind of account it is to know if debit is good or bad for you.
Very simple explanation: Entries in double-entry accounting always need to balance - you need two.
So if somebody gives you $100 in cash, you book that as $100 in your "cash" asset. But... the books must balance! And so, you need to book -$100 on the "income" side, because that's where the cash comes from.
If you're not happy with "because it needs to follow the rules" alone, replace "income" with "other people's money". For you to get cash, somebody else needs to give up cash.
The reason you differentiate between asset/liability and income/expense accounts is that you can't really fully balance the latter two. You don't know all the details happening to "other people's money". You know everything happening to your assets and liabilities.
As a result, income/expense are accounted over time ("I made $x/year") while assets liabilities are a value ("I have $357 in my cash drawer") - for the former two, all you know is the delta over time you cause.
Maybe the following will help. It might not click immediately but, when it does, there will no longer be any need to memorize what debits/credits are in the context of each of assets/liabilities/equity.
Think of "shareholder's equity" aka "owner's equity" as being a liability. After all, doesn't a company owe all its earnings to its owners?
Now, consider that:
- all income is a liability owed to shareholders. So any new income is an increase in the amount owed to these shareholder 'creditors', represented by a credit entry
- similar but opposite reasoning says that a new expense is represented by debit entry
If you feel uncomfortable seeing shareholders in the same category as creditors, consider that companies can choose two ways to fund themselves: equity (which creates shareholders) or debt (which creates creditors).
That's because it's just wrong, like everything from the docs of ledger and its descendants (and every "accounting for developers" article, except surprisingly not TFA here!), and accountants are just correct to use unsigned numbers.
A credit entry is a source, and a debit entry is a sink. When I do $4000 worth of consulting services work for Joe Bloggs, this gets entered as a $4000 credit to Income - Consulting Services (the source of the flow of funds), and a $4000 debit to Accounts Receivable (the destination of the flow of funds). Income, here, represents the outside world from the perspective of my business. Later, the receivable becomes cash when Mr Bloggs writes me a check, so I credit Accounts Receivable $4000 and debit cash (actually something like Assets - Coolbank Business Checking) $4000.
This makes a lot more sense to me. Source and sink. And I think illuminates why double-entry is confusing to non-business individuals, because we don't tend to think of Accounts Receivable for our persons.
An income is something you owe to your shareholders. So if you think of what you own as (+) and what you owe as (-), which is how debut/credit is conventionally shortcut, an income is a negative number.
In my thinking, as a programmer, debit = positive, and credit = negative. NOW, what type of account those are going to like others have said changes things, but fundamentally if you are adding a positive amount to an account thats a debit, and if you are adding a negative amount thats a credit.
You just look silly trying to build financial software without understanding and implementing double-entry or ledgers. You have to know when to employ debit and credit nomenclature and be able to easily explain the reactions in the system...or you look silly. Sort of like when accountants start talking about databases and APIs without proper training.
I have had to train developers on the simple concept of a ledger, which totally baffled them. It is event sourcing. You write, never update. If you want to offset a previous transaction you just record a new one. Want to know the account balance, just add up every amount within the range of entries you care about.
Once they grasped that they were wanting to use the terms debit and credit in that context. Not cool. If you are tracking single accounts you only need negative and positive amounts. If the account/ledger is not offsetting another debit/credit there is no need to introduce that concept and complicate things. If you do, the finance team is going to wonder what other accounts you are offsetting. If the answer is none, brows wrinkle and confusion sets in.
And ffs don't ever send them a spreadsheet or report with currency symbols in it. Major peave.
Accountants have been using event sourcing (immutable ledgers) for hundreds of years. Powerful.
Every complex finance problem I have run into in software dev was easily and elegantly solved with immutable records.
It's correct that "debit" and "credit" don't have to do with "owing/being owed" money. But they do have to do with "OWNing/being owed". This apparently subtle difference provides powerful insight.
If you look at equity as money owed to shareholders, then the left side of the balance sheet is money owned, and the right side of the balance sheet is money owed.
Sadly, I gave up accounting in high school after failing to reason through the meaning of 'credit' and 'debit' (Yes, I went in too deep!). My epiphany came in B-school when I tackled it again, when I finally figured out what your instructor summarized.
Yep, you debit or credit an specific account, and to make things extra confusing, a debit on one account is always the same as a credit on a different account (and the other way around).
Somehow transaction intermediaries made some incredible bullshity product differentiation out of those words... and what makes everything worse is that, since they are intermediaries, every transaction is both a debit and a credit on their own accounting.
It gets really confusing when you talk about "in the red" or the black / red coloring and it depends on which side of the books you're on for what it means. I get this mixed up with electrical engineering every time now. I never feel comfortable jumping a car.
"Red means positive, as in I'm positively sure you owe me a lot of money."
I was lucky enough to work on a billing system early in my career and pick up some rudimentary knowledge of accounting. I can confirm that even being able to 'speak the language' a little bit provides immense value to you as a developer.
> Sometimes non-accounting people get hung-up on the words "debit" and "credit"
In took an undergrad accounting class centuries ago. I'm a CS major, but we were required to take a beginner class in accounting, which in retrospect was a good thing.
In the accounting class (the double-entry bookkeeping part), for any transaction two accounts were involved:
- Money was "debited" into one account. ie., money came into that amount (balance increased)
- That same money was "credited" from another account. ie., money left that account (balance decreased).
However, my bank seems to use the terminology in the opposite way. If $10 comes into my bank account, I get a message saying "$10 was credited into your account".
Likewise, if I send money elsewhere the message would be "$10 was debited from my account".
I'm told that if you look at it in some convoluted way the meaning of "debit" and "credit" is infact the same, even though at first glance is seems to be the opposite.
Now that I think about it, there was something to do with "asset", "liability" etc, on which the meaning of the terms depended on.
> If $10 comes into my bank account, I get a message saying "$10 was credited into your account".
That's because you are a creditor to the bank. After you put cash into your bank account, the bank owes you cash. You are lending them your cash, and the more you lend them, the more of a creditor you are. That's why they say your account is in credit.
When you take too much cash out of the bank, it's obvious you are a debtor to the bank. You owe them. You're in debt to them. That's why taking cash out is called debiting. The more you take out, the closer to a debtor you become, though hopefully on balance you've been more of a creditor than a debtor.
On the bank's books your account is a liability (money the bank owes you). Simplistically, when you deposit money the bank's cash balance is debited and your account is credited.
Any time the idea of double entry bookkeeping comes up there is nothing but unanimous advocacy for it. This thread echoes the same sentiment where there's several comments about the importance of double entry. And yet like all previous endorsements I've heard, I've not been able to take away why it is so important. The reasons are always around error tracking, tracing source of funds, standing the test of time etc. and yet in my head I'm not able to envision the specific problem double entry can solve that single entry cannot.
Somewhere in my head I feel a double entry system makes sense if you have two different parties making respective entry. But if it's all with a single party, single entry system should be equivalent to a double entry system. My accounting concepts are weak so I'm unable to justify. Hoping someone with more expertise can shed some light here.
The name "double-entry bookkeeping" may be misleading: what matters is not how many times / in how many places you do entry, but whether you're tracking both (or all) sides of a transaction. (With a computer you only need to enter the transaction once, as long as you track the "from"/"to".)
A couple of examples from personal money-tracking:
• say you have a bank account, and you track when the bank balance increases / decreases. That's single-entry. When you withdraw cash from your account at an ATM, your bank balance decreases, and when you buy something with cash your balance doesn't change — this is probably not what you want. With double-entry bookkeeping, you track separate "accounts" for (say) "bank account", "cash" and "outside world", and every transaction is an edge in this graph (or in general, hyperedge in hypergraph). (E.g. withdrawing $100 cash means a transaction that is -$100 on "bank account", and +$100 on your "cash" account, which add up to 0.)
• Similarly, with your bank account and credit-card account, when you pay your credit-card bill it's a transaction between your bank account and credit-card account, and when you buy something with your credit card it's a transaction between your credit-card account and the "outside world" account (which you can break down more granularly if you want to track your expenses).
Summary: double-entry bookkeeping means that instead of entering "this balance decreased" or "this balance increased" (without a direct way of linking where the money came from or went), you enter transactions that track all the changes as one unit, and in each transaction the sum of the "postings" is 0.
> This is called the single-entry method of accounting. But we’re not going to do it this way;
Why? So you have a graph now, what does that allow you to solve? What issues will you hit with single-entry (maybe with tags)?
I _think_ the simple answer is that if you have multiple accounts, any transaction moving money between them needs to decrease one if you increase another or else you'll magically gain/lose money in your records. Then if you use it to answer something like "do I have enough money to buy X" you'll get an incorrect answer. It doesn't seem to be a suggestion/improvement/technique and more of a mathematical reality for this model.
The double entry requirement for money entering/exiting the system (salary, sales, payments) doesn't seem to matter for that though.
Double-entry is kind of a bad name, but the concept is sound.
I like think of each entry as the complete journal entry - a set of debits (abbreviated DR) and credits (abbreviated CR) that describe an event. Debits and credits are, as many accounting instructors have taught many students, names that effectively mean "Left Side" and "Right Side". Some accounting systems represent debits as positive numbers and credits as negative numbers - this is perfectly valid too.
Say somebody purchases a product for $60 and a service for $40 from me. The product that I sold cost me $40 to purchase, and both the product and service have a 5% sales tax applied. This is a very common transaction - car repairs, for example, are usually a combination of products (e.g., oil, oil filter) and services (e.g., oil change and inspection).
Account DR CR
Cash in bank 105
Tax Payable 5
Sales Revenue 60
Services Revenue 40
Cost of Goods Sold 40
Inventory 40
In this example, I collected $105 in cash from my customer which will go into my bank account. Because of this sale, I now owe the relevant tax agency $5 because I collected sales tax on their behalf. I recognized sales revenue of $60 and services revenue of $40. Since I sold some physical goods that I had in inventory, I also reduced the value of my inventory by the cost of what I sold.
This is, in my mind, one "entry" which has six detail lines to recognize all of the different things that need to be recorded for this event. The important point is that everything balances, credits always equal debits.
Some businesses might not do the Cost of Goods Sold / Inventory entries with each transaction, instead they might count their inventory once a month and calculate out how much they sold (inventory at start + inventory purchased - inventory at end = cost of goods sold) and just do one entry a month to get the books in sync with reality.
Think of each transaction as a movement: it has a source and a destination. Therefore, you need to account for it in two places: where it came from, and where it went.
I think you can expand this explanation with database terminology.
In modern RDBMS, you could have naive implementation with two account's balance, and increment one decrement the other. But without transactions it just isn't safe, its better to have one row in a table with a debit and credit.
Now if you're doing accounts by hand you really need that single line transaction record.
> its better to have one row in a table with a debit and credit.
No. Some transactions have 3 lines, eg: two debits and one credit. Some examples:
- Split payment at a shop, $100 item bought with $70 cheque and $30 cash would be
credit sales $100
debit cash $30
debit bank $70
Now if you introduce sales tax or VAT/GST, its more complicated. Say the $100 item is actually $90 + $10 VAT, then entries goes:
credit sales $90
credit vat-payable $10
debit cash $30
debit bank $70
I saw some systems that used single line, even in these cases. It had an ephemeral/transitory account to help on this.
And to map it together, all these entries would be related to a single transaction.
It seemed a nice solution for me.
Quite simply each entry contains both the "to" and "from" for the transaction. It's a construct to guarantee atomicity. The two "sides" of the transaction can never be out of balance with each other. If you lose an entire entry the system remains in balance-- you've lost a transaction but you're not in a situation wondering "where the money went" because nothing moves without both sides of the transaction.
"Single-entry accounting" usually means that you have one account that is the source of truth for the whole operation. For example, you use the checking account balance. When you take in sales, you put it in the sales column and increase the balance. When you pay the electric bill you put it in the electric column and decrease the balance. You have a couple issues:
1. How do you keep track of unpaid invoices and bills?
2. How do you account for things like asset values, depreciation, etc.?
3. If you have income or expenses that register multiple accounts, you have to sum the right columns.
4. If you missed a leg of a complicated transaction (recording the income and sales tax liability for the day across multiple payment forms, for example), you might never know it, e.g., you might accidentally record the sales tax payable as income.
Using the accrual accounting method (as opposed to the cash method), where you book sales at the time they occur, is next to impossible with single-entry accounting. If you have a mostly inventory-based business, you have to use the accrual method in the US. Most businesses that must make financial statements available to investors will use the accrual method.
This article [1] "Accounting for Computer Scientists" may help. Visualize money movement between Accounts / Nodes triggered by Transactions / Edges.
This model is used to construct a "Fund flow" representation of how money should be moved. One of the essential concepts we use to verify that money is moving through the system is "Clearing", where we add up all of the edges and the balance should equal 0 - that is money reached its intended destination.
Easy: double entry is append only database (immutable data). To compute account value you sum() over all transactions. Each transaction is required to sum to zero (credits=debits), so the sum over all transactions is also zero (balanced). You store the history of transactions.
If you instead update account values in place (stored as sums) then you can't check your accounts are balanced (missing money bad)
Single entry bookkeeping is essentially a list of your income/expenses. A list of this nature means you can't be certain you got everything, if an item is missing or has been double counted it wont be obvious at first glance that it is wrong.
Double Entry bookkeeping adds a layer to your lists to ensure that everything has been accounted for, you are creating the same list but also tracking the opposite side which is what it affected.
The most simple case here is that the income/expense also affects your bank account. By tracking the bank account you now can check that your "Predicted" bank balance according to your list is actually what is in the bank account. If they don't match then you know for certain something got missed.
It doesn't solve all the errors that can possibly occur, but it makes sure that the basics are at least covered.
How does it make sure something hasn't been double counted? I assume you mean this situation:
1. Debit for X added
2. Credit for X added
3. Debit for X added again
Then you'll get a discrepancy when you sum them.
In a computerized system though you wouldn't make that mistake though, or else you could make it with double entry accounting too (just, you'll have double credit entries as well).
The only way to prevent duplicates is to associate upstream payment/transaction ids with records and make sure every entry is unique (which can be done for single entry accounting too).
Let’s take a simple example I buy a plane ticket on January 1st with my credit card for $100 for a flight on March 15th. I paid my credit card bill on February 15th.
I simplistic view would be I spent $100 on January 1st.
Using double entry accounting I can track what is actually happening in that transaction,
1. I buy the ticket w/credit card (CC lent me $100 for an asset (plane ticket) = (cash +100, liabilities +100, assets +100, cash -100)
2. I pay my credit card bill (cash -100, liabilities -100)
3. I take my flight (+100 expense, -100 net worth)
Steps one and two I have yet to incur an expense, cash is changing hands and the composition of my balance sheet is changing, step three I actually incur an expense. That’s the beauty.
> And yet like all previous endorsements I've heard, I've not been able to take away why it is so important.
Double entry accounting is basically a shorthand for the Fundamental Equation of Accounting:
Income - Expenses = (Assets - Liabilities) + Equity.
We call it "double entry" accounting because within the constraints of that equation you cannot adjust one account without also adjusting at least one other account. It applies equally to the books as a whole as it does to the individual transactions, so you can validate one by validating the other. So at data entry time, you can be relatively sure that you did the right thing because the transactions balance. And later, when your bank statements come in, you can easily reconcile because you have them broken out by account already -- and given the double entry system was already in balance, we know that any mistake you detect at this stage likely means a mistake in another account!
It also serves to disambiguate certain transactions. One example would be a cash advance from a credit card. In a single entry system, I don't have sufficient metadata to determine whether that is income, or a liability that needs to be repaid. In a double entry accounting system, I can simply check the source of that credit and see "ah, this came from a liability account".
If it helps, you can think of it as a complicated form of transaction tagging, with some mathematical constraints on the sum of tags in any transaction.
The two accounts on the left normally carry a debit balance, and three on the right normally carry a credit balance.
At the end of the accounting period, subtract the Expense balance from both sides of the equation, and close out (Income - Expense) into Equity, i.e. if that was positive, Equity increases.
If you dig in deeper you’ll see that there’s never a single party. Money always moves from someone to someone else. So even if it’s a single party the money is moving from marketing department to customer acquisition. Let’s say you are giving customer 10$ signup bonus. That money has to come from somewhere and has to be accounted for.
One just can’t create or destroy money. And the best way to ensure that is double entry accounts.
If you are interested in error-preventing and tamper-proof fund tracking systems, have a look at the UTXO model. Bitcoin and many cryptocurrencies use it, but the actual model predates Bitcoin.
For those who use single-entry systems, if you've ever had to "split" a transaction into multiple categories, you're halfway to understanding double-entry. Especially if your "split" has both income and expense categories. For instance, if you want to accurate categorize your paycheck, some of the categories will be income like "gross salary", and some will be expense like FICA and tax. The trick is that all those amounts, positive and negative, need to add up to the net deposit that hit your bank account. Whereas in double-entry accounting, the combined debits and credits need to add up to zero.
I transfer money from savings to checking. That is a double entry. Money comes out of savings and goes into checking. Savings->Checking
I need to use the food money envelope to buy clothing. Double entry is just keeping track of what I did. Food Envelope->Clothing. Then 6 months later I can see where my money actually went, and how much I spent on food, and clothing, separate from how much I put in the food money envelope.
You may not need double entry if you’re just tracking your personal checking account to see if you can pay your bill… but it still may help.
You answered your own questions though. It’s useful for error tracking and consistency. As a simple example to explain how it can help from a consistency perspective - think about a tool like Mint or Personal Capital or Nerd Wallet. They let you sign into your bank account and use a GUI to track all of your transactions. Ignore any privacy concerns. If you have 5 credit cards (because points), 2 checking accounts (you+spouse), a savings account, brokerage, mortgage, etc - there’s a lot of room for money to jump between accounts. Now imagine that you don’t include your mortgage account in the app. Whenever you pay money… it looks like your net worth is decreasing. In these apps, it might show up as a “purchase”. But you’re actually getting richer (by paying off debt and gaining house equity). If you include the mortgage account, you get to bring “the other side” into scope - boom - you now have an accurate view of the world when you didn’t before. That’s kinda sorta ish comparable the value of double entry. One side doesn’t tell the whole story, but always tracking both sides does.
Of course, the error-correcting part comes when there was a mistake or a correction that needs to be added. (Mortgage lended says balance is wrong?Here’s the sum of all transaction from checking acct to mortgage!). If double entry, both sides of a single tx have to match, and you don’t track the balance, you derive the balance from the sum of all transactions. So you theoretically can’t get a case where one ledger (eg mortgage) doesn’t match the other (eg checking). Helps a lot more when you’re a multinational bank with $1T and 50 million customer accounts.
Another example is a cash registers in stores. There’s a much higher chance the balance of cash is wrong (more room for human error). Being able to compute the balance over time based on the transaction history is useful for determining register 5 keeps losing money. Every change in cash balance should match another transaction so the total value of business’s money doesn’t change. Or just confirming that once you bring the cash to the bank there will be enough balance to pay a loan.
Does this directly impact you on a day to day basis? Maybe no. But I hope that’s a super simple illustration of why it’s conceptually useful and what “error tracking and consistency” means.
To be a little pedantic, the beauty of double entry is that you can actually see that you DON’T get richer by paying down your mortgage (or poorer - also excluding the effect of lowered future interest payments), you’re just shrinking your balance sheet (by reducing an asset (cash) and a liability (loan) by the same amount)
It is essentially a checksum for transactions. You record where money came from and where it went to. All those entries should balance out to zero if you have recorded them correctly. If you haven't, you can detect an error because you'll have more money going in than going out or vice versa.
I'm going to chime in on this. Note, however, I'm not an accountant/CPA/etc. and in that sense my take is my own; I have spent the majority of my career working with accountants implementing accounting systems so have some practical experience with the subject.
As others have mentioned a basic double-entry accounting transaction includes two pieces of information: "where did the value come from" and "where did it go". This aspect of double entry book keeping I think is the less interesting one and you'd be right in not seeing any big deal as compared to single entry accounting... a check register style accounting with categories fits that definition pretty well. The debit/credit recording of double entry book keeping is really about the next point. Note that I used the word "value" because that value isn't necessarily cash, though value is always expressed in money terms.
The next aspect, and the important aspect, is not the transaction but the accounting equation: Assets = Shareholder's Equity + Liabilities. This is where the formalisms of double entry accounting start to differentiate itself from single entry accounting. This equation expresses what it is we ("the company") own (assets) and who has a claim on it (shareholders and others we owe such as lenders). All of our accounts are assigned into one of these three categories and whether we debit or credit an account depends on this categorization relative to the accounting equation. So if I buy a hot dog for lunch with my bank card I'll credit my bank account (an asset account) which reduces it's value and debit an expense account which is a special kind of shareholder's equity account. Shareholder's equity = retained earnings from prior years + (current revenue - current expenses). When I book the expense debit the result is that shareholder's equity decreases. On the other hand if I use the same bank account to buy a house... I still credit the bank account (an asset account) but now I debit a real estate account (a different asset account) which reflects that I changed the form of the property I had (cash to real estate), but I didn't change the shareholder's equity position or the liability position (yes, there are fees and most people buy houses with borrowed money... but ignore that for this discussion).
In the single entry world everything aside from the transaction itself is simply left to you to figure out. There really aren't additional formalities which guide you in getting a deeper understanding of the accounting data you generate. You could emulate this stuff, but typically something like Quicken isn't going to help you be sure your following these formalities. For many interested in personal accounting, not having these formalities is fine. But in business, the accounting equation and the many expansions of that equation tell you about the business is a way that is (should be) reasonably consistent from business to business. It's more than: "do I have enough in the bank for the next transaction", it's really about a clear statement of health and direction derived from the transactions.
For those interested, Tigerbeetle[0] is a high-peformance purpose built accounting database. It supports
- double entry transfer
- two-phase transfers (ie reserve an amount and post it later)
- linked transfers (move money across multiple accounts atomically)
What we realized for TigerBeetle, is that double-entry is often lifted and brought directly into the networked world of distributed systems as double-entry, as a ledger database.
However, most distributed financial systems of record also spend alot of their time talking to other distributed financial systems of record. So there are all these different entities (e.g. banks) all running different infrastructure and all wanting not only to track money within their own system but also to move money safely between systems.
Historically, double-entry is great at tracking transactions within a system or entity, but it's not great at this intersection between double-entry and distributed systems, because of the way that networks fail.
We were seeing that these systems all end up with the equivalent of a two-phase commit coordinator, which is alot of work to implement correctly on top of double-entry. And everyone is building these ad hoc ledgers that are not only ledgers but also two-phase commit coordinators.
So what we've done for TigerBeetle [1], is to take double-entry and marry it with distributed systems, to make it really easy to track transactions as money enters and leaves a system, by providing two-phase double-entry transfers out of the box. For example, not only a debits/credits balance, but also the concept of pending/posted debits/credits balance.
And then to package this all up as a mission-critical safe and performant (1m TPS) open source database that the whole ecosystem can partner with and build on.
[1] I did a deep dive into TigerBeetle in a recent talk at the Recurse Center called “Let's Remix Distributed Database Design!“ going into the storage fault research that we've implemented for TigerBeetle. For example, the safety reasons for why we didn't pick RAFT as our consensus, or the latency reasons for why we don't use LevelDB or RocksDB, and how our testing is inspired by FoundationDB's Deterministic Simulation Testing — https://www.youtube.com/watch?v=rNmZZLant9o
Thanks! I don't think we could have done TigerBeetle the way we did, without Zig. It's been two years now, and looking back the choice has worked out well for our design decisions. For example:
- single-threaded control plane (thread-per-core architecture),
- static memory allocation at startup (we never call malloc() or free() thereafter—no UAFs) for extreme memory efficiency (TB can address 100 TiB storage using only 1 GiB statically allocated memory),
- explicit memory alignment expressed in the type system (for Direct I/O), and of course,
- Zig's comptime which is insane. We use it to do all kinds of things like optimize the creation of Eyztinger layouts, or to eliminate length prefixes in our on disk LSM table formats.
Interesting, I'd heard of "double entry" before but I've never used it. I've written and maintain code that uses only 1 record per transaction and I'd love resources to look into that go into the "why" of double entry.
For example my current "transactions" table has fromUserId and toUserId columns (1 user = 1 account) and so purchases/transfers/reloading your account all take just 1 row. For reloading the "fromUserId" is a system user that is allowed to go "into the negative" since it's responsible in a way for "minting" money into the system.
I'll be the first to agree that a double-entry system would make some of my code simpler. Currently listing out transactions is somewhat annoying since you need to know the context (the user requesting the list) so you display the data correctly. "Spent $X at vendor" makes sense as a description from the user's perspective but not from the vendor's. Double entry would solve this as I could generate a description specific to each user's perspective "Spent $X at vendor" "Sold $X to user" or something like that.
But I'm sure there are other advantages to a double-entry system that I'm missing so any resources would be appreciated.
I've got some time to rewrite that system and I think double-entry sounds like the right path forward. It probably was the right path from the start but I was busy building, not researching accounting methods like I probably should have been. That said, this project of mine has been very successful (from my perspective) and who knows if it would have been had I gotten mired down in accounting from the start.
One of the big advantages of double-entry accounting is that it lets you model pretty complicated events in a simple way. I think its a common misconception that transactions have two sides to them, debits and credits. It probably comes from the name, and that most simple examples only have one two sides. Really, its at least two sides. The important characteristic is that the debits must equal the credits, in value not in quantity.
In reality, its very infrequent that transactions will only have one debit and one credit. Lets say you sell a service to someone, a year of service for $100. This sounds simple, debit cash for $100 and credit sales revenue for $100. But was there sales tax on it? You might have actually collected $115 from them, in which case the entry is to "debit cash for $115, credit sales revenue for $100 and credit sales tax liability for $15". This impacts three different accounts, but really any transaction could impact n accounts. This both simplifies what you need to do to model it, but also acts as a shortcut to the user.
It also has the side effect of being a signal that the sales tax collected and the sales revenue are related. You could also record two separate transactions, one for $100 and one for $15, but the bank statement probably has $115 instead of $100, so how could you ever know what was what? As a former auditor, this is crucial to understanding how past transactions occurred and what they were for.
> Lets say you sell a service to someone, a year of service for $100. This sounds simple, debit cash for $100 and credit sales revenue for $100
I'm confused, this seems like you would credit both cash and sales revenue $100... since you'd have received $100 from whomever bought your service, so youd have $100 more cash, and for tax accounting, you'd have sold $100 worth of stuff as well.
In the double-entry model, things follow the accounting identity:
Assets = Liabilities + Equity
and its more dynamic corollary since Equity = Capital + Income - Expenses, simplified to keep everything positive:
Assets + Expenses = Liabilities + Equity + Income
Assets and Expenses are considered to have a debit balance and the other three have a credit balance. Debit represents money "owed to" the business and credit represents money "owed by" the business. People get hung up on these terms because they think of credits as good things when their checking account gets credited and debits as bad things. But that terminology is because the bank has exactly the opposite relationship. Your checking account is their liability (and your mortgage is their asset).
Thus, when you are paid $100 by bank transfer for a service, you credit "Sales" by $100 and debit "Checking" by $100 as well.
In the accrual method, you might prefer to credit "Sales" by $8.33 and "Prepaid Sales" (a liability) by $92.67, and debit Checking by $100. Then each month you would debit "Prepaid Sales" by $100/12 and credit "Sales" the same amount. This would keep you from having weird ups and downs when looking at monthly income statements. It gets tedious to do by hand, but computers make it easy when they do it right.
Double entry bookkeeping doesn't mean that you have two records for each transaction. In fact, it's the exact opposite! Transactions fundamentally have two parts -- where the money is coming from and where the money is going -- and double entry bookkeeping says that both of those entries are part of the same record.
My understanding was that historically double entry accounting very much had each entry stored separately (although tied together by some transaction identifier). You would normally add both at the same time, so one could consider it "one record" on that basis, but physically they were separate entries often in separate physical books.
In computerized systems, having a single record in one place, and virtually constructing the ledgers from it is feasible. Under the constraints that all transactions debit from just one ledger, and credit to just one ledger, storing each transaction as tuple (id, amount, debited ledger, credited ledger) is feasible.
Double entry does have the slight advantage of being possible to generalize to allow one transaction to debit from multiple ledgers or credit to multiple ledgers, as long as all the debited amounts sum to the same as all the credited amounts.
It has a disadvantage in that the storage format does not guarantee validity, unlike the tuple method.
You are right that there would traditionally be separate books. The first, a "day book" would be a list of transactions that a merchant (or his servant/employee) would write down as business took place. This would say something like "I sold 10 spools of yarn for 8 florins apiece to Mr. Lucio" (remember that this all started a system to keep track of the affairs of Florentine Renaissance merchants). Later, after business had concluded for the day, the merchant (or his bookkeeper) would "post" the transaction to the ledger, which was a book that had a page for each "account." He would go through the daybook and, for each transaction, post it to (at least) two accounts, debiting and crediting equal amounts so that the books "balanced." This left him with a single number for each account which represented the total net activity for that account. This is the account's "balance" and is a very interesting piece of information for a merchant, so much so that it warrants all the associated ceremony.
Today, the "posting" can usually be done by a computer. There is some human creativity/regulation involved in deciding which specific accounts to credit/debit, but this can be noted in the "daybook entry" (more likely a database record somewhere than something literally written in a book) instead of being put off until the posting step.
The important characteristic is what the grandparent noted, that each transaction (in the daybook) tracks completely where each cent (or florin) came from and where it went. If a system of bookkeeping has this characteristic, I think it can be called double-entry, at least in spirit. A hard requirement that a transaction occur between exactly two accounts makes some kinds of events difficult (or impossible) to model, but is still conceptually the same.
Liabilities (Edit: plus equity) must always equal assets. This is the basic accounting principle.
Double entry enforces this and also ensures that nothing is lost into thin air by requiring that debits and credits match.
So for instance, if you spend money to buy a new laptop that money hasn't disappeared into thin air, it has been used to buy a tangible asset so while your cash has decreased your tangible assets have increased by the same amount (double entry) and your accounts are still balanced.
Or, if you pay a bill then both your liabilities and your assets (double entry) have decreased by the same amount and, again, your accounts are still balanced.
That's how you keep track of this and ensure (well, at least it helps) that your financial situation is accurately recorded.
Right. Was going to comment the same. If you sell a product for $100 that only cost you $90 to produce, that $10 isn't a 'liability', it's profit / retained earnings (an equity account).
From my, very limited understanding, the big benefit is the representation of obligations and receivables.
For example, if you take a bank loan of $1 you’d make an entry for your cash balance to be $1 and your obligations to your bank being $1. Your books are balanced.
Now you use that $1 to buy a machine. $1 down from your cash, $1 up in your non-cash assets.
For what if instead you pay someone for a service for $1? $1 added to your expenses, $1 down from your cash.
And so on, and so on. At the end of the day you have a fairly good idea where your money is coming from and where it’s going as well as any outstanding obligations and receivables.
One of the main aspect is that there’s an element of validation in here. If your books aren’t balanced, something is off.
I'm incorporated in Canada and have done my own corporate taxes in the past.
There is no hope to get this done right unless you use double entry accounting as every dollar has to be accounted for.
Unlike personal taxes, where you only declare your income and pay a tax on that, every dollar that enters or leaves the company, or becomes a different kind of asset (say computer hardware) has to be declared and everything has to balance at the end of year.
Above and beyond other reasons, double entry book keeping has some very nice error detection properties (the original reason for its invention) that actually make it quite nice to use as a basis for this kind of software, as it provides a way to catch some bugs very quickly.
> For example my current "transactions" table has fromUserId and toUserId columns (1 user = 1 account) and so purchases/transfers/reloading your account all take just 1 row
This is what double-entry looks like in a database.
Ironically, single-entry would have one column, and two records for each transaction.
Double entry is helpful when you have a large number of internal accounts that regularly transact with each other. The primary benefit is that you can determine the balance of any given account by just looking at that one account, and the business as a whole by combining all transactions across all accounts.
In an accounting sense, it's useful for implementing accrual bookkeeping. Accrual bookkeeping matches every dollar of revenue with all associated expenses by hiding cashflows in asset and liability accounts, until it's time to match them all up and recognize them simultaneously.
If you're not working with a system where you have a lot of transactions flowing between accounts where you control both ends, you might not get as much benefit from double-entry.
In addition to the detail/rigor that most describe, double entry accounting acts as a checksum. If things don't balance there is a problem somewhere. It may or may not be malicious, but there is something wrong.
One sentence from the article should be emphasized: “Double-entry systems are more reliable at tracking money than any other viable alternative.” So true, 100’s of years and no better system has ever evolved. I would argue that any blockchain system that attempts to tackle this problem has a double entry aspect if it’s useful.
Whenever accounting comes up in geek circles, it's worth mentioning ledger and similar systems it inspired which use plain text files to implement double entry accounting:
I used this system for years as a consultant - it's also pretty easy to extend - I did this using the Python API to implement an arbitrary RPN calculator on top of it:
I use this, except I use Beancount. It's written in Python and is easier to write your own little extensions. There's also a GUI called Fava that goes along with it and is really good.
Great post. This is so overlooked. I had a career in accounting and finance before technology and consider myself so lucky that the accounting concepts important to business and financial database design are no problem for me.
Another one, with completely different graphs, is by Martin Kleppman at https://martin.kleppmann.com/2011/03/07/accounting-for-compu... — despite the name ("Accounting for Computer Scientists"), on reflection / trying it out, I find it less useful than the Beancount one.
(Both of these are actually linked in the second paragraph of the posted article, but they're independently worth mentioning / good.)
Funny that this would show up when a month ago, GnuCash was submitted on this site. [1]
I decided then that I would take the opportunity to learn how to use it and learn accounting properly for my family budget, mostly because I want to start a small business eventually, and double-entry accounting will be necessary for that.
So I did.
It went extremely well. The GnuCash Tutorial and Concepts Guide [2] was exactly what I needed.
For all you developers wanting to learn double-entry accounting, I have one piece of advice: actually learn to use the terms that accountants use.
Sure, it may be annoying that you have to say that something is a "debit" or a "credit" versus just saying that it's a positive or a negative amount.
But in my experience, that annoyance passes quickly once it clicks.
Do take the time to learn it right. And if you use GnuCash, set it to use the standard terms.
Can someone help with a few ideas on this topic? I've been volunteered to be the treasurer at my building home owner's association, and trying to keep accounts for the whole building on a single excel sheet is a shitshow.
So obviously I'm building a SaaS that will handle all the accounts for every HOA in the whole world and become a trillion dollar product. But I need to figure out which accounts are debit normal and credit normal and how transactions should flow first.
So far I have the following accounts:
* Per-apartment accounts, like the account for Apt#A1, Apt#A2, Apt#B1 etc.
* A Maintenance Receivable account - the account for maintenance payments that should have come in.
* A actual current operating account - account that reflects the building's bank account, showing money that came in from apartments for maintenance payments and also expenses.
* An Expenses account. For expenses.
So far the typical transactions I can think of are:
* Beginning of every month the maintenance is due (say 100), so each apartment gets a -100 with a corresponding +100 on Maintenance Receivable.
* When an apartment pays, they get a +100, but this is money that actually lands in the current operating bank account, so that's a +100 too? I'm guessing this is where the genius of not using plus or minus but using debit and credit comes in. That avoids the confusion, one is a debit and one is a credit, but which is which and which is a debit normal and credit normal account?
* When there's an expense, I remove money from the bank account account and put it in the expenses account.
Seems sort of ok, but the Maintenance receivable account is always increasing. How do I set this up so I can correctly represent what an apartment owes while also capturing what it paid as inputs to the buildin's bank account?
I would recommend getting comfortable with some basic double-entry accounting software like GNUcash [1]. I found that extremely helpful in learning how to reason about these things, as well as grasp the purpose of different types of accounts (asset vs A/R vs income etc). They also have pretty good docs and tutorials as I recall.
Also then it'll quickly show you where the existing software falls flat (and it does) in terms of scriptability, scaling, etc.
If you're serious about building a SaaS tool (and I encourage it!), make sure to find someone with an accounting background to help you / advise you. Maybe they can be a good co-founder.
(I've been working on a SaaS in the accountancy space for 6 years and our two co-founders are an accountant and a software engineer. It's a good match)
This is currently just a side project, but yeah, if I have more than 10 buildings using it I'll probably take it seriously and bring in an (accountant cofounder).
Just chiming in - I'm an engineer who is also a CPA :). I'd be happy to attempt to answer any questions you might have. It's been a few years since I was accounting professionally, but maybe I can still be helpful.
You could implement it as either a subaccount per customer (in which case the balance is just the sum of all txns in that account) or have 'apartment' as another dimension (field) you store (optionally) for each transaction.
Either way you can get a sum of all txns that have hit that apartment's AR account.
So when an apartment pays, is 4 entries in the single transaction? Credit their apartment account, debit the bank account, credit cash and debit receivables? Never thought of making 4 entries for a single transaction.
You would have accounts receivable as a super-account for all your apartments. Its value would be the sum of the sub-accounts. The bank account would be a sub-account of all your cash accounts. So you only need to make two entries, one to the apartment's AR and one to the bank account.
You should do yourself a favor and read a good textbook. The online resources are not great and are mostly geared toward getting you to buy a product. For example:
I've implemented tens of accounting systems, always multi-currency and usually multi-lingual. Originally in RDBMS, but in the last decade generally with triggers in SQLite. The most complicated one I've done was Kraken (~2011) which needed arbitrary precision support for unknown future crypto asset types.
Opine: (1) Accounting as a profession is being automated away as governments create APIs to facilitate report submission and SCM/ERP/payroll become automated. Not too soon. (2) Yes, IMHO absolutely the debit/credit account terminology needs to die. It's backward and a source of confusion for the non-indoctrinated. Use negative numbers and present formatting for antiquarians where required. (3) As a student of ancient history, falsely ascribing off-handed western-inventors to things is so 19th century colonialist. Double entry is just an overly-lauded stage in the development of accounting anyway, not the endgame. Ancient societies got by just fine tying knots in cords (ancient China, Maya, Polynesia, etc.) and many ledgers run fine without double entry now. It's primitive compared to what's available in computer science today. (4) Distributed transaction systems are an algorithmic problem, not an excuse for manual documentation. Let's give away autonomous implementations for free, make GAAP about reporting, standardize account and transaction identification and innovate on process.
New systems recommendation:
(1) For account identification, use IIBAN which provides IBAN-compatible account identification and checksums and is an open system @ https://github.com/globalcitizen/iiban
(2) For all accounting, use UTC.
(3) For transaction identification, use UTC second of origination (UTCSO) + account of interest (AOI; eg. IIBAN) + intra-second transaction identifier (ISTI).
I noticed this, too. The summary bullets at the end of the post also oppose the diagram. Probably a simple mixup of credit/debit in the left column. The rest of the article usually lists do it first.
Some practical cases where you really need such a system:
A customer pays one product with two different sources of payment (gift card + visa, or one half with cash and the other with card)
You want to verify if the balance in the cash register, or on the credit card account are correct.
You already received money from a customer, but it will take some time until you can create the invoice (for example you want to print the serial number on it, and don’t know it yet), but for legal reasons you are not allowed to change an invoice later. So you have to record a payment without having an invoice yet.
One of my favorite resources on accounting is https://www.ledger-cli.org/3.0/doc/ledger3.html It's application specific, but has enough examples in there to remind me of accounting principles from years past.
Combined with the other plain text accounting resources, it was the first resource that made everything "click" for me, well, for varying definitions of "click". I often refer back to it when I need to remind myself of things.
One thing on my todo list to expierment with is modelling double entry accounting as a graph, with nodes of the graph an account, and edges of the graph a transaction with the two amounts on the edge.
That's nice and all but the part I'm really interested in experimenting is modelling reconciliation as equivalencies of graphs. I have a separate graph that models the real world bank accounts and flow of cash, and organisational flow of money, and then I have my accounting graph that models all the transactions. For reconciliation I would go "these whole bunch of edges in this graph A are the same as all these other edges in graph B"
I just want to see what falls out the other end...
I had a pleasure to dive deep into this topic and we built a double-entry bookkeeping system from scratch in a heavily regulated industry that tracked debt consolidation for thousands of customers with payouts to thousands of creditors.
I think this is one of the most proudest things I was ever was involved in architecting, designing and building. I left before it got to prod, but from people still there, I've been told it's been working flawlessly!
I have 2 main issues with understanding double entry accounting, that i haven't really been able to grasp properly:
1 - How do i use it to keep track of multiple "currencies"? It's simple enough to remove 1$ from the cash account into the inventory account, but that 1$ i now have in the inventory isn't actually cash... How can i use this to keep track of the number of widgets i actually have in storage? Rather than the cost it took me to get them there.
2 - How do i account for profits? Back to the example, i move the 1$ from my cash onto the inventory. Great now i have 1$ in inventory. I sell half my inventory for 2$. How exactly do i account for this? I still have presumably 0.5$ in inventory, and now i got 2$ in cash, but where did that come from and go?
Presumably i'd take 2$ from the inventory and put it in a client account, but does that mean i now have negative 1$ inventory? Sure the client account would also have another transaction putting the 2$ into my cash account. And wouldn't this make one transaction into actually 2 transactions? One from inventory to client, and one from client to cash?
If you can help me grasp this i would really appreciate it!
Inventory is not a second currency. Multiple currencies are handled using Exchange loss/gain accounts.
I will try running your example from scratch. You begin business with $100 capital which is deposited to your bank account. I am using Cr for credit, Db for Debit
1. Starting capital: Capital Cr $100, Bank Db $100
2. Purchase widgets worth $50: Bank Cr $50, Inventory Db $50
3. You sell half of this inventory (valued $25) for $75 in cash:
Sales Cr $75, Cash Db $75
Inventory Cr $25, Cost of goods sold Db $25
4. You sell rest of your inventory on credit to John for $110:
Sales Cr $110, Accounts Receivable-John Db $110,
Inventory Cr $25, Cost of goods sold Db $25
5. You pay $30 salaries via cheque: Bank Cr $30, Expense-Salary Db $30
At the end of all this your PL (profit loss statement) would look like this
Sales: $185 (110 + 75)
Cost of goods sold: $50 (as you sold all of the inventory)
Gross profit = sales - cost of goods sold = 185 - 50 = $135
This is going to be quick, dirty, and simplistic. I've explained deeper in a different comment. But this should help.
Things to keep in mind...
The accounting equation: Assets = Shareholder Equity + Liabilities. This expresses what we own (assets) and who has a claim over what we own (shareholders, creditors). Shareholder's equity can be expanded as: Retained Earnings + (Revenue - Expenses); retained earnings is revenue - expenses in prior years.
Transactions assuming you start with $1 in cash.
When you buy the inventory you credit the Cash Account (asset) by $1 and debit the Inventory Account (asset) by $1. In essence you've converted the cash asset into an inventory asset.
When you sell the inventory you have a multi-part transaction. Inventory movement: Credit the Inventory Account (asset) by $1 and Debit the Costs of Goods Sold Account (Expense) by $1. You no longer have the inventory.
The Sale part: Debit the Cash Account (asset) by $2 and Credit the Sales Account (Revenue) by $2. You have received a new $2.
In the end you remove the inventory as an expense to Costs of Goods Sold and you have new cash from sales revenue. From the accounting equation perspective it looks like:
>When you sell the inventory you have a multi-part transaction. Inventory movement: Credit the Inventory Account (asset) by $1 and Debit the Costs of Goods Sold Account (Expense) by $1. You no longer have the inventory. The Sale part: Debit the Cash Account (asset) by $2 and Credit the Sales Account (Revenue) by $2. You have received a new $2.
So that answers part of question 2, but not entirely. And it doesn't address question 1 at all.
You statement works if you're zero-ing out your inventory account, but what happens if you have 3 dollars, and put them into your inventory account in 2 transactions, one for 1$ and one for 2$. Both transactions actually added the exact same number of widgets to your actual inventory, say 2 widgets one cost 1$ the other 2$. They are otherwise in differentiable.
When you go to credit the COGS account because you sold 1 widget, how much do you credit? 1$ (the cheapest you bought), 2$ (the most expensive), or 1.5$ (the average)? Whichever one you pick, you're going to have issues later on when you buy/sell additional widgets...
Under GAAP rules, you could use FIFO, LIFO, or average for inventory costs. IIRC firms generally use LIFO, since that usually results in higher cost of goods sold, and therefore lower taxes. They can't do exactly "most expensive first," but LIFO is pretty close to that since inventory prices tend to increase.
Tracking how many units were bought at each time at each price is not part of the core accounting ledgers of debits and credits, that would be supplemental info that helps you determine how large the debits and credits should be whenever you use up inventory.
It depends on the accounting treatment that you need to track under. Average cost is easier to track with a Ledger type solution.
You keep track of inventory in two ways on two different Ledger Accounts under different "currencies." Inventory in dollars and inventory in units.
When you make a sale calculate average per unit value by dividing inventory USD value by number of units. Then your COGS value is driven by that average * units.
Each purchase adds to both the USD and the units accounts.
Unfortunately, I'm doing a half-assed reading job, so giving half-assed answers :-). My apologies.
For question 2, the whole thing is actually in my answer. It's in the Equity side of the equation. Revenue - Expenses = Profit. The inventory and asset side doesn't really have anything to do with profits per se; sure those profits may be cash assets in the cash accounts... but so might cash from a loan or similar non-revenue source. So the income statement is based on those bookings. The cash, the inventory, etc. on the Asset side of the equation don't really have much to say about profit. It's just stuff you own. The reason it's in the breakout of the Shareholder Equity side of the equation is because it's the shareholders who are exposed to profit or loss; the concept of profit/loss just doesn't need to appear elsewhere. Often times you'll hear accounts talk about "income statement accounts" and "balance sheet accounts". Revenue and Expense accounts are the "income statement accounts". At the end of a fiscal year, the income statement accounts, which state the profit or loss, are basically netted out and booked as a "Retained Earnings" entry. The "balance sheet accounts" including asset accounts like cash and inventory valuation or liabilities, on the other hand carry their values year over year.
To your inventory valuation question (you may ultimately be sorry you asked :-) ). Inventory valuation accounting is more complicated than it first appears and how it happens can best be summed up as: it depends on a number of factors. The nature of the business, the preferences of the accounting management team, etc. Sometimes there can be multiple inventory valuation methodologies in operation at once depending on who is consuming the information being produced or the specific inventory being valued. Note that with all methods, the basics from my first comment will still apply: these different methods are primarily aimed at how to arrive at a unit cost
First, a couple disclaimers. I'm not a CPA/Accountant/etc. I am principally a technologist and some of what I'm going to be giving you is based on the understanding I've developed for my own purposes of the issues rather than something more textbook. I do have around 30 years of experience which consists of a combination of management roles within companies with significant and complex inventory management accounting (think chain retailers), ERP implementation consulting into retail, distribution, and manufacturing companies including working with finance teams for accounting implementation, designing a Retail Method stock ledger for an ERP system, and finally redesigning the costing mechanisms of a manufacturing-centric ERP system (as well as doing the development work) along with a fair amount of research into these questions. None of that promises that I know what I'm talking about, but at least I've had to think about the kinds of questions you are asking at some depth.
Inventory valuation. There are a number of different approaches as others now in this thread have mentioned. First In-First Out, Last In-First Out, Weighted Average Costing (more on this in a bit), Standard Costing, Actual Costing, Job Costing, and Retail Method, to name a few. These methods have different histories and traditions and some are more prevalent in certain industries than others.
Knowing which to use involves knowing which goals you're pursuing. First there's a division at large in accounting which needs to be understood. There are two kinds of accounting of interest here: Financial Accounting and Management Accounting. Financial Accounting is about producing financial statements for investors, banks, etc. and for tax reporting (a whole other can of worms I will mercifully/largely avoid here). Then there's Management Accounting. Management Accounting is concerned with internal nuanced understanding the operations of the business at large. These goals don't always see the world the same way and will have different demands of accounting. You'll see terms like GAAP ("Generally Accepted Accounting Principles", the U.S. standard for Financial Reporting) and IFRS ("International Financial Reporting Standards", same as GAAP for much of the rest of the world). These are targeted at investor financial statements and so fall into the Financial Accounting category.
Costing methods associated with Financial Accounting (GAAP/IFRS) are Weighted Average Costing (conditional for tax purposes), FIFO, LIFO (only under GAAP, not IFRS, allowed by the IRS under certain conditions), Job Costing (conditional), Actual Costing, and I believe Retail Method is also accepted in GAAP/IFRS, but not tax (I could be wrong), but I really see it as a Management Accounting method. Management Accounting methods include Standard Costing and Retail Method. Note that for the Retail Method especially and Standard Costing to a lesser degree, their usage has changed over time from use in Financial Accounting to be more Management Accounting focused. Also know that many applications implementing costing conflate these purposes, especially on the lower end of the market: they rely on expertise in the accounting area to produce correct reports or laxity by investors and taxing authorities to care. Bigger systems tend to get it and implement things right (if annoyingly so).
Of all of these, for Financial Accounting, the most popular would be a flavor of weighted average costing or FIFO. Others mentioned LIFO as being more accepted, but that's backwards: it's FIFO. LIFO is not acceptable under IFRS and really only the IRS acceptance (and interestingly the tax advantages that can show up with LIFO) that keep it alive at all.
-- Weighted Average Costing. As you've suggested, when you have inventory where individual units stocked are fungible with all other units of the same item (I call this "Unit General Costing"), you can simply average the receipts of inventory with that already on hand and arrive at an average cost. There are different flavors of this basic approach. What I'll call "perpetual average costing" involves immediate updates to the average unit cost whenever new units are received into inventory; simply put: (new receipt value + existing inventory value) / (new receipt quantity + existing on hand quantity) = Current Unit Cost for things like sales transactions. Note that transactions like sales shipments don't change the current unit cost, only receipts of new inventory such as new purchases. There's also what I call "periodic average cost". In periodic average cost methods, the cost is calculated at the beginning of some period of time: a day, a week, maybe even a fiscal month. The same cost calculated for that period is used in all transactions that issue inventory (e.g. sales order shipments), when the period rolls over to the next, the current inventory with the actual receipts of the period are then used to calculate a new average cost for the new period.
-- First In/First Out. The basic mechanics of this costing method is pretty evident from the name. You keep a log of received inventory quantities and the costs they were obtained at. As you issue (ship) units you relieve the inventory at unit cost with the oldest inventory going first using the costs from the log. Sure you might not be shipping the specific units in FIFO order, but who cares? If the inventory is truly in that "unit general" accounting category... it doesn't matter.
Naturally there are conditions that crop up that can foil things. For example, there are cases where taking your on-hand inventory quantities into negative territory is valid; also, there are companies that have legitimate reasons for backdating transactions. Think what that does in either of the Average Costing or FIFO costing cases :-). And we haven't even discussed loading the costs that you find out about later for things like capitalized freight, etc. There are ways of dealing with these things, but the common-case gist of it all I think is captured above. (plus I'm a couple or four beers in now and should probably stop :-) ).
I don't know if that provides clarity, but at least it should give you some sense of the size of the question you're asking.
Two transactions are happening at the same time. Your "sales" revenue account is going up (Credit) by $2 and your cash asset account is going up (Debit) by the same $2. That is the first balanced transaction.
The second transaction is that your inventory asset account is going down (Credit) by $0.50 as you have less inventory now, and an expense account called "Cost of Goods Sold" is Debited by the same $0.50.
Your profit gets calculated on demand. There are two ways to do it, both yielding the same result. You can look at revenue minus expenses over a period, giving $2 sales minus $0.50 cost of goods sold = $1.50 profit for the period. Or, you can look at how your equity (assets minus liabilities) has changed over that period. In this example, no liabilities have changed and your assets (bank account) have increased by $1.50 because bank has gone up by $2 while inventory has gone down by $0.50.
My non-expert understanding for number 1 is that you would record the widget account in denominations of widgets, and separately, record the widget cost for that transaction. That's what you do in beancount anyway, which is what I use for home budgeting. Like this:
former CFA turned developer here. I've been doing an informal workshop on "Finance for Developers", figured I should share my material here for people looking for more. Not selling anything.. yet but this stuff is easy for me to pump out given my previous career haha
to make a point directly related to this post - i believe accounting is the starting point for finance - but you can learn "just enough" accounting to make it work.
Great article by a company that's honestly been great to work with, I think it's interesting that they write such an entry level piece when their solution is enterprise grade but it shows their dedication to educating not just the users and stakeholders of the end product but also the implementers, which very few software companies do.
As a CPA looking for an entry-level job as a software developer, it has been disheartening to see hiring managers brush aside my accounting knowledge and experience as next to worthless. I think the theory behind double-entry accounting is super interesting and a base-level knowledge would be helpful for many developers. Particularly those working at a small startup that have to wear the accounting/financial hat. The sooner you use double-entry accounting, the better your life will be in the future. Double-entry is an incredibly old system that's battle-tested, so it's remarkable to see some people still opposed to it today.
It's reassuring to see so many comments here expressing positive sentiment around the topic!
I think the figure / chart in "Effect on balance by account type" is wrong / flipped. It says that debits decrease debit normal account balance which doesn't match the text description or subsequent examples.
Author here. This is helpful feedback, we could have perhaps taken more time before jumping in on the Modern Bagelry example. A common misconception is that one account needs to increase while the other needs to decrease. But what we are actually showing that they can both increase or decrease in tandem, depending on the debit and credit entries in the transaction and the direction of the accounts. In the first transaction cash increases because it's a debit entry in a debit normal account (cash); and equity also increases because it's a credit entry in a credit normal account (equity).
So you basically have these two types of account, because you want all accounts to have a positive balance in general? If we would not care about certain types of accounts having negative balances, then we could say that for each transaction the sum of all account changes would always have to add up to zero. We could then still -depending on the account type- flip the sign after calculating the account balance. Am I understanding this right?
The main issue was that at the time the "Effect on balance by account type" figure was reversed / incorrect, and so the example was just not making sense. Reading on further and again I realized it was not the example but that figure that was wrong. I see that you fixed that now. Thanks.
When I went to school for an AAA in Computer Programming in 1989-90, a quarter of accounting was required for graduation. The instructor didn't like computers (which was the reason about half the class was there), and tried his best to convince everyone they needed to major in accounting, but he was a good teacher and I learned a lot of stuff, none of which I've needed over the last 30+ years but all of which I was glad I learned.
I cannot upvote this enough. I worked at a fintech company that was vehemently opposed to using double entry accounting and it created an incredible amount of inefficiencies and massive errors and expenses at the company. If you are dealing with money in any system and tracking it in a database, double-entry accounting is not an option.
Can someone explain. From their definition it looks like the credits and debits column in their example transaction table is flipped e.g. the first "debit" to the cash (debit normal) account increases the value, while the "credit" to the equity (credit normal) account also increases the value. (edited for spelling)
This is a pretty good article about the basics! I'm a CPA who is now working in the tech space. I've helped work on some accounting software and other finance-type processes. I'm happy to answer any questions if anyone has them! Either here, or my email is in my profile.
Accounting is also a strange field because its a bunch of almost unrelated fields stuck together. Accounting covers financial accounting (dealing with recording transactions, representing reality, etc), tax, management and cost accounting (things like tracking performance, figuring out what the widget you produced actually costs you, once you've included the direct costs and an estimate of overhead) and a whole slew of other things like internal controls, governance questions (how do you align incentives in an organization?), etc. Picking up a textbook on financial accounting is probably a good starting place to get the basics of debits/credits, but from there it depends what your interests are.
For books on finance, I recommend Niall Ferguson's Ascent of Money as
a pretty good introduction into the history of finance and how it all sortof fits together.
Ok this is an interesting post but I as understand it, its more like "what can go wrong when developing accounting software" and not that developers need a special type of accountant?
Yes this post is about developing accounting or other kinds of software that tracks money (from the subtitle: "... we walk through basic accounting principles for anyone building products that move and track money").
One can treat it as a primer on double-entry accounting as well.
For those of you who like the blockchain, think of that as triple entry accounting -- you put one charge as credit in one column, debit in another, and a public record on the blockchain.
My 100-level accounting instructor summarized it as: "A debit is the entry in the left column, and a credit is an entry in the right column." Without the context of the specific accounts being debited or credited the terms themselves mean nothing.
Aside: A 100-level knowledge of accounting can confer near "super powers" when it comes to dealing with finance and accounting people. Double-entry bookkeeping is one of the oldest and longest-practiced "IT" disciplines. Your work probably touches revenue / expenses for your employer and someday you'll need to interface with accounting or finance people. Being able to speak the language, even poorly, has helped me gain trust and credibility that I don't believe speaking only in IT terms would have.