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.
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.
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.
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?
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...
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.