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.
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.
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.
That's not quite the point of double-entry. When one account is credited, at least one other account must be debited.
All debits and credits sum to zero, but the accounts will have positive or negative balance.
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)”.
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).
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.
> "debit" and "credit" and
> think they have to do with
> "owing" or "being owed" money.
When you credit an account, you either increase what you 'owe' on that account OR decrease what you 'own' on that account.
Examples:
- bank credits a customer account => bank owes more to its customers
- company credits income account => company owes more to its shareholders
- company credits accounts receivable => company owns less in unpaid invoices
> Without the context of the
> specific accounts being debited
> or credited the terms
> themselves mean nothing.
> A debit is the entry in the left
> column, and a credit is an
> entry in the right column.
> 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").
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.
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.
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 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).
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’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.
That's definitely not the reason I consider GP's comment incorrect.
(I'm a qualified accountant.)
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.
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).
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.
Can you share a couple of example (or maybe use the same examples I did)?
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.
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.
Money OWNEd = Money OWEd
Assets = Liabilities + Equity
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.
"Red means positive, as in I'm positively sure you owe me a lot of money."
It's kind of like being given a cheat code.
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.
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.
Problem with this is it's a convention. Accountants in Australia could do it the other way (credit on left) and it works just as well.
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.
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.
Or just read this by Martin Blais, it's still the best: https://beancount.github.io/docs/the_double_entry_counting_m...
> 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.
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
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.
Does that make more sense?
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.
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
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 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.
[1] https://martin.kleppmann.com/2011/03/07/accounting-for-compu...
If you instead update account values in place (stored as sums) then you can't check your accounts are balanced (missing money bad)
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.
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).
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.
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.
Assets + Expense = Liabilities + Equity + Income
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.
Or, in a computerized system,
Assets + Expense - Liabilities - Equity - Income = 0
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.
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 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.
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.
Worth looking at.
[0] - https://www.tigerbeetle.com/ & https://github.com/coilhq/tigerbeetle
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
- 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.
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.
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.
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 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.
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.
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.
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.
https://arxiv.org/abs/1204.1583
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.
https://en.wikipedia.org/wiki/Double-entry_bookkeeping (obviously the most technical as it's Wikipedia)
https://anderscpa.com/accounting-102-startups-double-entry/ (specifically startup-focused)
https://www.nerdwallet.com/article/small-business/double-ent...
https://www.fool.com/the-ascent/small-business/accounting/ar...
This is what double-entry looks like in a database.
Ironically, single-entry would have one column, and two records for each transaction.
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.
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:
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.)
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.
[1]: https://news.ycombinator.com/item?id=32136384
[2]: https://www.gnucash.org/docs/v4/C/gnucash-guide/index.html
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?
Also then it'll quickly show you where the existing software falls flat (and it does) in terms of scriptability, scaling, etc.
(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)
DR accounts receivable
CR income
DR bank account
CR accounts receivable
Normally accounts receivable has a DR balance (because apartment owners pay you AFTER you invoice them, so they are usually DEBTors).
Like a sub-account? This is probably the mindfuck part. So every apartment owner who opens up their statement is seeing a filtered balance?
Either way you can get a sum of all txns that have hit that apartment's AR 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:
https://www.worldcat.org/title/accounting/oclc/1127092943&re...
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).
Free thoughts on forward-looking accounting systems @ https://raw.githubusercontent.com/globalcitizen/ifex-protoco...
Not sure if the author is reading comments here, but the diagram after this sentence shows the opposite!
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.
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 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!
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!
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
Expenses = $30 (salaries only)
Net profit = gross profit - expenses = 135 - 30 = $105
Your balance sheet at the end of all this will be :
Capital: Cr $100
Accumulated profit: Cr $105
Bank: Db $20
Cash: Db $75
AR John: Db $110
Inventory: 0 (as you sold all).
Note the balance sheet balances nicely as Capital + Accumulated profit = bank + cash + AR + inventory
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:
Before inventory purchase:
$1 (Asset/Cash) = $1 (Equity, assuming it wasn't borrowed) + $0 (Liabilities)
After Inventory Purchase:
$1 (Asset/Inventory) = $1 (Equity) + $0 (Liabilities)
After Sale:
$2 (Asset/Cash) = $1 (Equity) + ($2 (Revenue/Sales) - $1 (Expense/COGS)) + $0 (Liabilities)
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...
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.
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.
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.
2022-08-17 * "Purchase Widgets"
Assets:Cash -100.00 USD
Assets:Inventory:Widgets 10 WIDGET {10 USD}
2022-08-18 * "Sell Widget"
Assets:Cash 20 USD
Assets:Inventory:Widgets -1 WIDGET {20 USD}
Reading: https://docs.google.com/document/d/1imIgNckZ_kM564fpGgTBtsqi...
1hr Youtube workshop: https://www.youtube.com/watch?v=Lelq40jILA4
2hr Audio podcast discussion: https://share.transistor.fm/s/0b9270a5
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.
It's reassuring to see so many comments here expressing positive sentiment around the topic!
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.
One can treat it as a primer on double-entry accounting as well.