I always felt that equation was confusing. Because then the sign has to be taught separately, or numbers have to have two columns (credit and debit) and you need to understand where each one is.
assets + liabilities + equity = 0
Seemed much more general. Double entry just became: everything (transactions, whole companies) sum to zero. Then just one other little thing (where money comes from in a transaction is positive, where you put it is negative) and you have the math.
Your formula is not correct. If you want to do it that way, it should be assets - liabilities - equity = 0.
Think of it this way. When you start a company, you invest $100. For the company accounting, that is $100 in the bank account/asset and $100 in equity. $100 - 0 - $100 = 0
Now you take a loan for $100. Now you have $200 in the bank account, a $100 liability, and $100 in equity. $200 - $100 - $100 = $0.
It is not incorrect. To make everything positive (and use the subtraction as you have) you need to have two different types of 'positivity' Credit and debit. And then you have to remember which things are subtracted and added so it gets back to balancing. That's why it gets so complicated.
Money in your bank account is _negative_. It is a _debit_ in your accounts (this is not my invention this is true). Your bank account statement is from the bank's perspective. The money came from you, so it is a credit from their perspective only. Try to submit your statutory accounts with 'bank credit' and you'll get in trouble! Your software or accountant will definitely flip it to become a debit!
> Equity is similar to a liability. Ít is owed to the owners of the entity.
You can kind of see the easy rationale there. I'm not sure it's very deep though. Revenue is in the same group (Credit). And the assets are like expenses (Debit). That is a bit more of a just-so-story in my mind.
> Making assets positive in code is conventional.
Are you sure? What code are you talking about?
Making everything positive in the UI is certainly common. And not showing whether a value is credit or debit. But I really hope my accountancy software isn't coded that way! It needs to track whether a number is a credit or a debit. It could do it with an unsigned value in a struct with a 'is_cr' Boolean and some custom operations to combine the money structs. But I've only ever seen code using signed values, because it is so much faster and less errorprone. Doing it manually is just reinventing the math of negative numbers. And then, the overwhelming convention is the former is positive, the latter negative, not the other way round.
> For one example, read the docs for Beancount, which is mentioned above.
Do you have other examples too?
You are dead right with this one. It is the opposite way to the way the systems I'm familiar with did it. Debit is positive, And credit negative.
Thanks so much for the link.
I'm still not sure what I would concede that it is conventional ;) But my assumption it was nothing but the other way is definitely incorrect!
I wonder if they did it this way because they felt people would understand negative income being a good thing better than a negative bank accounts being a good thing. The bank account is usually the big problem with understanding debit and credit.
As usual, the world is more complex and interesting then I assume!
When you first open a business, you put in capital - owner's equity. So the cash account (an asset) increases, and the equity account (a liability) also increases.
In a computerized system, one of these accounts carries a negative balance, the other a positive balance. A choice has to be made - but it's not a matter of good or bad.
There are several implementations of the Ledger system. The transaction registers and GL are human-readable. I looked at Ledger, and assets were positive.
I looked in the code for the GNUCash engine, but there are so many features that I didn't manage to get to the bottom of it w/o spending too much time on it :-)
I do recollect working with low level GC transaction data years ago, and I think I would remember if the assets were negative.
There are a couple of Wikipedia pages with links to FOSS accounting systems.
Say I have two million dollars and deposit one million in the bank and buy a one million house.
What is the value of my assets? -$2mn? $0mn? Something else?
The "confusing" answer would be that the value of my assets (which is equal to the value of my equity, as I don't owe anything to anyone) is two million dollars.
Deposit
Asset>Cash in Hand CR$1m
Asset>Bank: DB$1m
House purchase
Asset>Cash in Hand CR$1m
Asset>Property: DB$1m
So all I'm suggesting is to use of negative numbers instead of tracking everything in terms of credits and debits.
Deposit
Asset>Cash in Hand $1m
Asset>Bank: $-1m
House purchase
Asset>Cash in Hand $1m
Asset>Property: $-1m
In either case the value of your assets at the end is unchanged, because you're just turning assets into different kinds of assets.
But let's say you started with DB$2m (inheritance say, or you won the lottery). You end with DB$2m assets.
I'm not reinventing anything here. Where do you want to label your $2m as 'debit' every time, or use negative numbers, either way is the same.
People do always struggle when learning accounting to comprehend how money in their assets is debit. Because they are so used to seeing 'credit' on their bank statements. But it is only credit because there was from the banks point of view.
I'm not talking about credits and debits. In the version of accounting I know the balance sheet (edit: I'm not talking about the transactions, I'm talking about the aggregate balance) says simply:
ASSETS
======
$1mn Cash (in the bank)
$1mn House
----
$2mn
What does the balance sheet look like for you? -$1mn plus -$1mn, i.e. total assets -$2mn?
Is that less confusing than total assets being $2mn when you have two assets worth $1mn each?
If the things you're doing are so simple that you don't have to worry about credit or debit, you are free to show it that way.
But if you are doing accounting, debits and credits and balancing is important.
So yes, if you are happy to ignore debit/credit/balanced books, you are welcome to view asset as $2m. And lots of the simple accounting software will show it that way.
But by the time you are having to understand different types of accounts and different types of money in it, I think it is easier to use negative numbers are rather than CR/DB.
Yes, balancing is important. That’s why I’d prefer to end with assets that make sense in the balance sheet (or maybe you're happy to ignore balance sheets and don't want meaningful numbers?). I don’t see what do you gain by making the assets negative.
Believe it or not, I’ve seen financial accounts quite more complex than two lines (and they never included those CR/DB annotations in the balance sheets or income statements).
This has been an interesting conversation with several people. I am really surprised how much negative numbers are confusing or interpreted as my idiosyncrasy.
> I’ve seen financial accounts quite more complex than two lines
Definitely.
For hundreds of years the convention has been columns. Credit values in the right-hand column, debit values in a left-hand column. The column is the label of which type of money it is. Most accountancy software (other than very simple personal tracking apps) use this when displaying.
Your printed bank statement probably does (and it may label the columns credit and debit as well, though never line by line, iirc). Mine did back when paper was the thing.
Digital bank statements usually do use negative numbers (DB being negative, as I've been saying). You are used to seeing this, but not used to thinking in your own accounting terms rather than theres. Which is fine. But there is a reason that accountancy education has to undo that assumption.
It's definitely not my idea! It wasn't Goldman Sachs, but I did a consultancy 15 Years ago for a large bank (my little job was a long way from programming the core, but used it extensively). Their system stored debit as negative numbers. That's when I learned it and had the aha moment when everything instantly simplified. Since then all the accounting software I've seen the inside of do.
Most lay-people find double entry in accounting idiosyncratic. It has this bad reputation for being full of special case rules.
It is interesting that the one comment I got from an accountant on here it seemed fine with debit as negative numbers.
Goldman Sachs absolutely know that they have DB$1tn! Anyone who thinks it is either a credit account or just a bare number is not going to be dealing with that!
It's an API. There are many tools built on top of it, many with UIs. I'm sure they display things in many different ways for people internally and externally. The system I was working was back-end. It used negative numbers for debits. And it was really important you didn't confuse credit and debit numbers.
> Was that accountant fine with assets as negative numbers?
I find it hard to believe they didn't understand that's what Using negative numbers for debits means. They would be pretty aware that assets are debit accounts.
> The did have $1tn in their balance sheet. No DB, no CR. Just $1tn.
Did they have a complex balance sheet (I.e. beyond that just a couple of lines summary) with no columns? How do they represent a balance if you couldn't tell which were credits and debits?
And that makes sense. You can see the balance. Because it will balance. Or you'd know which of the things were debit accounts and which went credit accounts.
Yep.
But I definitely bet it's not raw unsigned/untyped numbers behind that document! I suspect we've just been mismatching on different levels: I began this discussion about developers understanding double entry bookkeeping. I would be surprised if you could get very far if you didn't understand the difference between debit and credit. But your pushback makes sense. Thank you.
I do understand the difference between debit and credit. The point is not whether you can balance the books looking at them when they fit in a single page. The point is that in a balance sheet assets appear as $x (where x is rarely negative, an asset with negative value would become a liability).
People want assets to be positive in the balance sheet. This may be a convention but it's a reasonable convention. I don't think you're helping developers who try to understand accounting by telling them that assets are negative quantities (it may make sense as an implementation detail, but not so much as an accounting concept).
If you are using a negative numbers you can do it in three ways.
1. positive numbers represent the default for an account (A positive number in a debit account is a debit, but a positive number in a liability say, is a credit). This is done a lot. But he causes a lot of rules about when to add and went to subtract what the balance with what. I think this is why they lot of double entry bookkeeping and has a hard reputation. Certainly if you coded it you would have to code all those rules manually.
2. The approach I'm used to of having negative numbers in the debits and positive credits. This makes all the double accounting balancing much simpler. But I can see it may confuse some people when assets are negative.
3. Make credits at the beauty of an debits positive (incidentally I only today learned that beancount does it this way). Again balancing and double-entry accounting becomes simpler. Now money in the bank would be positive, like your bank statement. But sales income would be negative (it is a credit). I wonder if that would confuse people.
So maybe that's why UI should make everything positive and undifferentiated. But given the amount of time the Accounting 101 has to drill in all the rules of what
> 2. The approach I'm used to of having negative numbers in the debits and positive credits. This makes all the double accounting balancing much simpler. But I can see it may confuse some people when assets are negative.
So, if people were able to overcome their confusion, would you have balance sheets written like this?
$ in millions
ASSETS LIABILITIES AND SHAREHOLDERS' EQUITY
Cash and Short Term Investments -133546 Deposits 117756
Other Assets -859422 Other liabilities 784947
------------ ------- ----------------- ------
Total Assets -992968 Total liabilities 902703
Shareholders' equity 90265
==================== ======
Total liabilities
and shareholders' equity 992968
If you really want to change the signs in one of the sides, so instead of getting the same totals they sum to zero, it would make much more sense to do it the other way: keep assets positive and let liabilities be negative (as other commenters have suggested).
$ in millions
ASSETS LIABILITIES AND SHAREHOLDERS' EQUITY
Cash and Short Term Investments 133546 Deposits -117756
Other Assets 859422 Other liabilities -784947
------------ ------ ----------------- -------
Total Assets 992968 Total liabilities -902703
Shareholders' equity -90265
==================== =======
Total liabilities
and shareholders' equity -992968
But one property of the usual presentation is lost: equity is no longer equal to net assets (which are $90265mn). You would need to change the sign of equity when considering it as an asset.
> But sales income would be negative (it is a credit). I wonder if that would confuse people.
It does tend to cause some confusion, but IMHO less than you would get with negative asset balances, much less the traditional version where "credits" and "debits" have different signs depending on the type of account and nothing ever just sums to zero.
The less confusing way to think of it is that an income account represents not "how much income have I received" but rather the source of the income, e.g. your employer or customer. They paid you, so they have less than they started with.
⋄ Money moves from employer to me: decrease "Income:Employment" and increase "Assets:Cash".
⋄ Money moves from me to my landlord: decrease "Assets:Cash" and increase "Expenses:Rent".
⋄ Deposit money at the bank: decrease "Assets:Cash" and increase "Assets:Bank:Checking".
⋄ Take out a loan: decrease "Liabilities:Loan" (negative since I owe them money) and increase "Assets:Cash".
Note that Income and Expense account balances are relative—which is why it makes sense for Income balances to sometimes be negative, and why these accounts are zeroed out at the end of the reporting period with transfers to or from equity—in contrast to most other accounts which have absolute balances.
is true because L and E are Credit dollars and A is Debit dollars. And the total Debit is equal to the total Credit.
But instead of using debit and credit unsigned dollars, you can use negative numbers: Credit is Positive, Debit negative.
In that case
(-Assets) = Liabilities + Equity, so A+L+E=0
-Assets because you've made those debit dollars negative.
In fact you don't even have to remember which. Sum(Everything)=0. 'Balancing' means summing to 0.
The software I am aware of that does large-scale double entry calculations for large banks works this way (I did some consulting 15 years ago on data laundering for that system). And all those accounting rules about what accounts are debit or credit accounts, whether a credit increases the debit account, etc, it all isn't needed at a low-level. The confusing bits are only in the UI. Where a number stored as -10 is displayed as 10DB, while +10 becomes 10CR.
So it's definitely not 'just simple maths'. It is the convention you use to express numbers: turning debit numbers into positive, and having rules to keep the math consistent in other places. And since the original article was aimed 'at developers', I think that the widespread negative number format is much stronger.
Yeah. It's all left over from the fact that double entry bookkeeping is older than the use of negative numbers. Start with the rule that every account has to be positive and you get all of the inane rules.
CPAs are the OG Luddites, refusing to use negative numbers to make their jobs simpler and easier to understand.
Except in your case you need all the rules about income and expenses. And loads of grey cases get weird (it is possible to have assets or liability of the wrong sign), and require serious accountancy expertise to know all the rules to get them back to the signs that you expect.
Or you can use negative numbers and everything just works.
Your financial software _will_ use my approach. As do the most sophisticated software of the most complicated companies. But their presentation gets mangled through a complicated series of rules for archaic reasons.
So how does this actually work? Say I worked for 8 hours at $25/hr. I get a $200 deposit in my checking account; that increases my assets. How is the sum still zero?
This is exactly how it would be stored in any software system behind-the-scenes, and how it would be submitted in statutory accounts. The only thing that makes this look weird is that you are used to seeing your bank account statement with 'credit'. But that's only because the bank account statement is from their accounting perspective.
Money comes from somewhere (Positive, Credit); it goes somewhere (Negative, Debit).
The entire confusion about signs and what to add and remove, and what categories 'increase' with debit or credit, it all disappears when you allow negative numbers. I guarantee your accounting software _will_ simply store them as positive or negative. It is frustrating that it appears so complex simply because of avoiding negative numbers.
Debit is where you put money. Credit is where it came from.
I am not inventing this. Money in your bank is debit in _your_ accounting.
You are very welcome to treat it as positive and add. As long as you keep track of where every positive number is a credit or a debit, and you learn all the rules about which accounts to add and which ones need taking away.
Or you can just treat credits as positive numbers and debits as negative.
Literally the only 'weirdness' is that money you have put somewhere for future use (like a bank) is negative.
Your initial reaction might be "that's just nonsense and ridiculous!" But I guarantee that is how your accountant and accountancy software is storing it. Your bank balance is debit from your accounts. Legally and intuitively. The only reason it is weird is because you receive statements from the bank from their perspective (a credit because they received the money from you).
If you have made it to junior high school you are quite capable of the math. Treat debits as negative and credits as positive. No accountancy ed / special rules needed.
If you want to get it more intuitive you can think of it as: Negative numbers are money that you put somewhere and is now owed to you. If you have $1000 in 'your' account, legally that means you are $1000 down because you are owed that money by the bank. It is your debit. You have given them credit.
It may not feel like a loan because it feels like you can get the money any time you want. But loans you have given and bank accounts are both assets in your accounting. They are both debit. They are both money you have put somewhere.
I think you're confused on what I'm confused about. The positive or negative sign isn't the issue. You could flip all the signs and I'd still have the same problem.
> Literally the only 'weirdness' is that money you have put somewhere for future use (like a bank) is negative.
But that is literally what I'm talking about. Whether the sign is positive or negative isn't the issue. It just makes no sense for this to be a zero-sum game, is all I'm saying. You're telling me if I get $200 out of the blue I suddenly owe someone that $200 instantly? How does that work?
I see, sorry. Thanks for clarifying your question.
Transactions always balance. Money always comes from somewhere, and it always goes to somewhere. Total debit always equals total credit.
In a double entry accounting system you have to say where that $200 came from.
Did it come from a sale (you sold your work, an item), a loan you took, someone you loaned money yourself, or an investment in your company.
In double accounting it always balances.
Here I am talking debit and credit because this is nothing to do with my point about positivity or negativity. This is how double entry bookkeeping works.
If you make all the numbers positive, then the total credit has to equate ('balance') with the total debit.
So treating debit as negative and credit as positive, means 'balancing' is just summing to 0.
Before double entry bookkeeping was invented in the Renaissance, single entry accounting just kept separate lists for all things. This works for basic tracking of money. For individuals particularly. But has massive weaknesses for tracking where money is coming from how it moves around, and making sure there aren't errors. Money doesn't come out of the blue. Which is why it is the business standard. And the legal requirement in most of the world. One of the most amazing and significant human innovations, IMO.
The credit and debit/what to add/what to subtract rules are only because double entry accounting was invented before use of negative numbers (they were only a weird mathematical curiosity at the time).
I still don't get it, sorry. So I worked and earned $200 for my work. It (obviously) came from somewhere—that "somewhere" being the pocket of the dude that paid me. But why is that relevant here? Am I not doing accounting properly until I start tracking what's in others' pockets'? I need to make an "account" for that dude and write down a debit of $200 for him just because he gave me $200 and the sum just has to be $0, or else some catastrophe happens? Isn't that nonsensical?
I suspect the misconception might be that you think individual accounts must balance (Or think that what I'm saying). Transactions always balance, companies always balance.
In double entry accounting you track where money came from to you. You are right in not having to worry where they get their money from. But you do have to track how/why it came to you.
You will have an account in your accounting of 'income' (it's usually called 'Revenue'). If you have even the slightest complexity in your business, you will have many income accounts. Some businesses will definitely track at the level of detail where they have accounts for each customer, so they can see who purchased how much.
Each transaction balances.
Each line in a transaction is associated with an account.
So if you have done 50 weekly transactions of:
Revenue>Consulting $1,000CR
Assets>Bank $1,000DB
Each one balances.
But in total you will have $50,000CR in Revenue>Consulting and $50,000DB in Assets>Bank, but your company will still balance.
If you pay yourself $45,000 in salary from that, let's say in one go at the end of the year (to save me typing) you would have a transaction:
Assets>Bank $45,000CR (it came from your bank account)
Expenses>Salary $45,000DB (it went to your salary)
So at the end, your accounts are:
Assets>Bank $5,000DB
Revenue>Consulting $50,000CR
Expenses>Salary $45,000DB
This still balances. Double accounting always balances companies and transactions.
Historically it balances credits and debits. All I'm saying is it makes more sense to think of debits as negative and credits as positive, and all the math becomes much much simpler. Which is how accounting software is written.
Ah okay thanks a ton! I think that clears it up. So basically:
- The idea is that every source/destination ("node") of funds keeps their own account for every node they deal with. And every transaction ("directed edge") necessarily needs to be tracked by both accounts in an equal and opposite manner.
- This is mainly only useful for businesses, as they generally have multiple sources of income (and/or multiple creditors) and need to be able to explain/track them. (At least as far I can see, I don't really see much of a point in doing this for the average person.)
Yes on both fronts. Thanks for continuing until we've got on the same page.
The only slight curve ball in your part one is that transactions are not always between two accounts. The joke is that 'double entry' sometimes has more than two.
The classic example is sales tax. E.g. a transaction:
Revenue>Product $100CR
Liability>Sales tax $5CR
Asset>Bank $105DB
(Although the specific form/standard categories will massively depend on how sales tax works in your jurisdiction.)
There are plenty of other examples (in my consulting: the customer paid some their bill in advance, or I pay a bill in a different currency and have to pay a fee).
So I like the idea of making it a topology question, but it would be nice if it were only two.
If you receive money out of the blue, then you credit your "Received Money Out of the Blue" account and debit your "Cash" account.
An account doesn't have to be money that you actually owe someone and have to pay back, but regardless of whether you have to pay the money back or not, you still want to track where the money came from and where you put it.
The amounts have to balance because you can't create or destroy money unless you are the Federal Reserve.
This is why "assets = liabilities + equity" works much better.
You would increase assets by $200, since you got that much cash (cash is an asset). You would increase equity by $200 as well (often accountants will call that "Owner's Equity") since your personal stake in this business (yourself, here) has gone up. That's the double entry.
"I found the core explanation of double entry accounting to be confusing. After some time I distilled it down to the following:
"Debits decrease the value of an account. Always. [1]
Credits increase the value of an account. Always. [1]
"[1] (1, 2) This is absolutely not what accountancy teaches. You’ll quickly see that there is a lot of wrangling over what account types get increased/decreased with a debit/credit. I’ve simplified this on the backend as I strongly feel this is a presentational issue, and not a business logic issue."
I mean, this is just....wrong. Maybe I'm not smart enough to see why this isn't completely incorrect? I mean I feel mathematically this will work but goes against so many core accounting principles it won't have much use except in the simplest of cases.
It would not work for a bank. The only reason they 'sort of flip' is that they give your account from their perspective. Your statement is a slice of their accounting.
Banks and non-banks don't treat assets/liabilities in different ways in accounting - banks just engage in transactions most other businesses don't, as a normal matter of business.
For example - if you're holding someone's money for them, that's a liability - you have to pay it back some time. If someone owes you money, that's an asset - it's worth something. Banks use the cash from liabilities (people's savings accounts) to pay for assets (mortgages) and make money on the spread.
Except Fractionnal Reserve. It kinda throws off the idea, how do they do then ?
Let's see, when they lend money they don't have (which is what it is) they increase the number on your account, that is they create a big liability for themselve. On the other hand they create an asset wich is your debt to them. So accounting-wise, it works out, like theorically I could do that (lending) even if I have €0, it's all paper.
But then you're gonna go and empty that account to buy your house, reducing their liability and taking (reducing) their cash instead... that they don't have !
So how does it work ? Does it just work because you don't actually buy houses with bills and coins but with bank transfers, then just shifting the paper magic to another bank ?
To be honest I know they can do something my broke self can't, and it has to du with central banks, but what is it exactly ? Something like "if everybody happens to empty their account to cash at the same time, don't worry mate we'll print them bills and give them to you, pinky promise" ?
They’re not flipped. From a bank’s point of view, any money they hold on your behalf is a liability. Your bank statement is an extract from their books. When they take a fee, it’s a debit on your statement, because it’s a credit to revenue on theirs.
All account balances should normally be positive. Depending on what side of the balance sheet they are, a debit or credit could increase or decrease an accounts balance.
In general, nothing. It's just not the software developer's job. If the accounting profession decided to change certain terms to fix inconsistencies, that would be fine.
I think that's missing the point of the original article. Of course you have to present a view of the accounts that is consistent with accounting rules and conventions. But that doesn't necessarily mean you have to adopt that external view as an internal model for any software you're writing.
At audit time the world of “holy shit what were these people thinking?” will be colossal, because we do not get to pretend that a system is a black box at audit time.
If those records don’t make sense to an accounting professional, then they’re fucked up, and that’s all she wrote. The world of audit has seen a million shysters try to falsify their books under the guise of alternative methods, and they are not interested in some self-serving hubris from programmers about re-inventing their own profession.
So this guide isn’t just philosophically off beam. It could get someone fired or sued.
Yeah I've worked on so many systems that dealt with money. Telephone invoicing, business accounting, ticket sales, etc.
One of the businesses I worked for did online invoicing and they initially started off without double ledger accounting. I was employee 30 or so and I kept repeating "we need double ledger accounting" every month or so. Nobody really listened to me (to be fair I was young, but this was after the telephone invoicing job) until the cracks started to form. It took them years to transition to a new system. Do not re-invent accounting with your own terms. International commerce runs on it and it has figured out a lot of the edge cases.
Accounting professionals can only ever look at user interfaces. If there is a suspicion of fraud then a court can ask expert witnesses to look into the software itself.
The law does put some constraints on what accounting software must and must not allow users to do (e.g change data without leaving a trace).
But I'm not aware of any specific legal requirements regarding data representation or mandating the use of specific algorithms where mathematically equivalent ones exist.
Nothing, if you can convince the entire user base to do it at the same time. If you decide to unilaterally fix inconsistencies, you've just made it impossible to understand what anyone is saying without additional metadata saying which version you're using.
And if you start telling learners that your "fixed" version is all there is, hiding the actual standard that most of the world uses, you are basically lying to them and setting them up to fail.
It's wrong in the sense that anyone who's studied standard accounting will look at your books and consider them to be incorrect.
This is important if you want to share your books or reports with your local tax office, who will begin investigating you for committing tax fraud. It's the same reason why no one fixes the HTTP "Referer" header typo. You can, but if you do then you'll have difficulty communicating with the outside world.
I think OP is encoding the sign-reversal internally though, right? It "displays" the two incorrectly classified account types exactly per the standard convention instead of re-applying the convention at every operation. All reports would follow the 'Classic' conventions. At least that was my reading!
It doesn't, the Equity account displays a negative number if the company is in the green (it decreases when you emit stocks), the Expense account displays positive numbers (it increases when you spend money), the Income account displays negative numbers (it decreases when you earn money).
In beancount, the accounting equation is Expense+Income+Equity=0 and all signs are always left intact (there is only addition).
So you start a company with a seed capital of $5. You borrow $5 to the bank, buy an expensive apple for $10, sell it for $15 and give the money back to the bank with an interest of $1, then close the exercise and carry the profits (don't distribute dividends). Your ledger is:
Initial capital
Assets:Cash +5 USD
Equity:Seed -5 USD
Borrow to the bank
Assets:Cash +5 USD
Liabilities:Bank -5 USD
Buy an apple
Assets:Apples +10 USD
Assets:Cash -10 USD
Sell the apple
Income:Sales -5 USD
Assets:Apples -10 USD
Assets:Cash +15 USD
Reimburse the bank
Liabilities:Bank +5 USD
Expenses:Interest +1 USD
Assets:Cash -6 USD
Close the exercise # beancount does that for you for any time period btw
Expenses:Interest -1 USD
Income:Sales +5 USD
Equity:PreviousProfit +4 USD
Notice how every transaction balances to 0 just by summing it, no need to remember anything.
Now, you're at the beginning of the next exercise. To know your accounts you just compute a sum of every operation to it, again no special case. So your accounts are:
Expenses 0 USD
Income 0 USD # as expected at beginning of exercise
Assets:Apples 0 USD
Assets:Cash 9 USD
Liabilities:Bank 0 USD
Equity:Seed -5 USD
Equity:PreviousProfits -4 USD
And yet again, the sum of all of that is 0.
Personally I like it, not having any special cases. Yes, it may confused an accountant (because they learned the special cases by heart ! Somebody coming with a fresh mind has no reason to be confused, it's all just conventions !) but it's simpler for me and just as consistent.
FWIW I did an accounting elective at college and ran the books for a small business for a couple of years. I'm comfortable with the conventions :-) I was just saying OP was choosing to encode the conventions differently internally and display them a different way to meet the external convention, like GMT+TZ. You need never known your computer stores time in GMT and most people don't, even the accountants.
There are no inconsistencies to fix; the credit/debit model is fully consistent, just implementation inconveniences. And I don't think anyone would have trouble with this if it was titled “implementing double entry accounting in software” rather than “double entry accounting for developers”; that is, it's a fairly decent explanation of how, if you have preexisting understanding of the domain, to reduce it to software internals, but very bad as an explanation of the domain (whether to an audience of developers or otherwise.)
> Established accounting terms are from 500 years ago when people had trouble with subtraction.
People still have trouble with substraction compared to addition, especially with large numbers.
We have an algebraic indentity, a + b = x + y. (Let's not even think about what those might represent; it doesn't matter.)
The two sides must always be equal. Any transaction must maintain that equality. Therefore, any transaction must increase both sides by the same amount, decrease both sides by the same amount, or leave both sides unchanged.
One way to ensure this is respected is to add up everything which increases the left side or decreases the right side, then add up everything which decreases the left side or increases the right side, and ensure these two subtotals match. If they do, the transaction balances, and is legal.
By convention, we call things of the first type (which increase the left side or decrease the right side) "debits", and things of the second type (which increase the right side or decrease the left side) "credits". This lets us say "debits must equal credits" as a shorthand, although again what we really mean is that the two sides must continue to balance.
The operation performed by debit/credit depends on the classification of the accounts. Accounts are listed traditionally with Assets on the left, and Liabilities and Equity on the right. A debit to a Liability account is a minus, and a credit is a plus, but it's the other way around on the asset side, where a debit is a plus, and a credit is a minus. (This kind of thing happens when English mugs other languages - Italian in this case - for its vocabulary).
The easy way to remember this is just to think that the right hand side is what you think it should be, and the left hand side isn't.
Double entry book keeping is under appreciated - it's one of the earliest examples of error correction and detection coding kicking around.
I’ve found the best way is to remember the phrase, “Debits come in and credits go out.”
Let’s say you have a bank account. Your view of that account is opposite from the bank’s view.
You have $100 cash. That’s an asset from your POV, and it carries a debit balance on your books - when you received it, the cash “came in”.
You walk into the bank and deposit it. The cash goes out of your books, but an asset (the increase in your bank account) comes onto your books. You credit cash and debit asset.
From the bank’s POV, cash came in - they debit their cash account. And they credit your account in their books. That account is a liability from their POV - they owe you the money.
Notice how the debit and credit to cash even balanced across entities. If you talk about pluses and minuses, you’ll get confused quickly.
One of the worst things that ever happened was banks issuing “debit cards”. When you take cash from an ATM, it’s a debit from the bank’s POV. The bank carries your account as a liability, which carries a credit balance. (You are the bank’s creditor!)
So the bank debits your account (credit came in again) and credits their cash (cash went out).
You credit the bank account on your books (asset went out) and debit your cash (cash came in)
Just remember that a “debit card” reflects the banks POV and don’t let that confuse you about the meaning of “debit”. Debiting an asset is generally a good thing!
When making accounting transactions, debits always balance credits - meaning they total to zero in the code itself. It’s conventional to make assets positive (hey, having lots of assets is good, right?).
OP gains nothing but confusion by turning everything upside down.
That is the complete opposite of common usage. When I get a credit on my credit card statement, it means money is coming in to me. When I get a debit on my debit card, it means money is going out from me. It's not rocket science, or at least it shouldn't be. And yet somehow accountants have managed to turn it into something even more confusing.
Isn't this just a matter of perspective. You are being debited by the third party, meaning they are requesting money. The bank credits your account with money when they put something in your account.
>It’s conventional to make assets positive (hey, having lots of assets is good, right?). OP gains nothing but confusion by turning everything upside down.
I agree. However, the problem is that you can either make the vocabulary consistent or you can make the math simple, never both.
Making the math simple means you have to make a decision to always treat debits as positive and credits as negative or the other way around. You just have to be consistent.
Making the vocabulary work means you have to switch signs based on account type. But that makes the math and hence the software complicated and error prone.
Assets being positive makes sense. But debiting an asset account to make it more positive is counter intuitive. And expenses being positive doesn't make much sense either, because having lots of expenses is not so good, is it?
We're just accepting the inconsistent vocabulary as a price for having a simple mathematical model.
Not inconsistent. It’s a matter of POV. Your mortgage is an asset from the bank’s POV, but a liability from your POV.
Expenses come in and cash goes out. Debit expense, credit cash.
From an accountancy POV, the debits of a transaction equal the credits. From a software POV, the account changes total zero. There is a difference in what the word “balance” means.
I prefer to think of double entry accounting (with reasonable controls) as the first reasonable implementation of a blockchain. At its core, a double entry accounting system is a giant ledger where each transaction is linked to the last one ‘forever’ (assuming proper controls).
It’s likely the only reasonable implementation of a blockchain but we won’t know that for sure until cryptocurrency matures enough to develop reasonable controls. I’m not holding my breathe because then it’s just an accounting system with reasonable controls built in and there are already more than enough of those built with databases.
> The operation performed by debit/credit depends on the classification of the accounts.
OP has chosen a consistency in the operation of debit+credit sign and applied a 'display adjustment' to implement the classification. This actually sounds like a lower entropy way to remember it -- no left hand/right hand stuff, just 'There two account types are sign reversed on display'. But it will confuse anyone who isn't indoctrinated to the convention, but one could argue that it is these various conventions that make double entry seem arcane in the first place!
I learned from my accounting 101 professor, "debits on the left, credits on the right."
Then later after learning about natural account balances, it all made sense. If an account has a debit balance, a debit increases the balance and a credit decreases it. An asset or expense account has a debit balance.
Credit balance is just the opposite. Liabilities, revenue, accounts. Credit is an increase, debit decrease. (I think equity too but I always have to look it up. Rarely work with equity accounts in my day to day)
I wish I could tell you how to remember it from first principles, but I can’t do what I did was burn the A = L + (OE/Equity) accounting equation into my head. Then I remember that the when my bank balance goes up, the bank speaks of a credit in their accounts which is a debit to assets in my account. Then L + OE must be credit accounts.
Why are OE and L on the same side? Well to finance an asset, say a new car for your business, the company would either take on some debt (L) or you’d put in some of your own money (OE) in exchange for more ownership. I don’t know if that’s more confusing or less
This comment expressing confusion on this valiantly misguided OP seems like a good place to throw my standard explanation out into the aether to do neither readers nor myself any good.
A transaction has two polarities, because it represents a flow of value. The credit side is the source, the debit side is the sink/destination/whatever. Let's temporarily pretend that every transaction hits exactly two accounts for the moment (which is not true), to make it easier.
Let's say we have $1000 in Cash, which is an Asset, and we want to buy a Pizza, which is also an Asset, for $20. How does this look in accounting?
Cash provides the source side, and Pizza provides the sink. Cash is credited $20, and Pizza is debited $20. If we ran the balances now, Cash would come out to $980, and Pizza would come out to $20.
Let's unwind that transaction. We're a business; we don't trade cash for pizzas. We contract for delivery of pizzas with a pizza vendor, who invoices us.
So here we are, with $1000 in Cash and $0 worth of Pizza. The pizza delivery driver comes, and hands us a pizza and an invoice. We know we have to debit Pizza $20; what is the credit source for this debit? Well, the pizza vendor has actually extended us a loan worth $20, in a sense (this is called "trade credit"), and the offsetting entry is the fact that we owe the vendor $20, as memorialized in its invoice. This goes in a Liability account, usually called something like Accounts Payable.
Current balances (if we ran them - "running the balances" is thought of by accountants as a discrete operation, just FYI):
Accountants think of accounts as being naturally debit-increased, like Assets, or naturally credit-increased, like Liabilities. I find it a bit misleading to try to think of these as positive or negative signs, as you might be inclined to at this point. It's just $20 - don't even think of it as cr $20, IMO. (dr and cr are the abbreviations for debit and credit.)
Let's just leave that on the books and eat the pizza. After eating the pizza, we no longer have $20 worth of pizza, so we have to credit Assets/Pizza $20. What do we debit to offset this - i.e., where did the pizza value flow to? In this case, it would be a Depreciation account (these are debit-increased) - something like Depreciation/Eaten Pizzas. So we have:
(a commenter below points out correctly that this would be an Expense, not a Depreciation, and I'm still in the edit window!)
Meanwhile, someone pays us on one of our invoices, which we had sent out earlier offscreen. When we delivered our fine $50 widget and invoiced the buyer, we entered that into our accounting system as a debit of $50 to Assets/Accounts Receivable, and a credit of $50 to Assets/Widgets. This part of the system looks like (we still have 9 widgets in stock):
But now that the invoice is paid, $50 of value flows from our receivables asset into our cash asset - i.e., we credit A. R. $50, and debit cash $50. Getting paid is nice.
After the customarily long delay, our accounts payable department has approved payment of the pizza invoice. Cash has to be credited, because cash is flowing out, and it's probably easy to guess the debit where it goes to - that's right, our Liabilities/Accounts Payable is finally cleared, because we don't owe the pizza vendor $20 anymore.
BTW, why is "running the balance" a discrete operation to accountants? Because accountants' source of truth is the transaction log, which they call a "ledger".
Ledger entries look (conceptually, not literally) like this:
with the constraint that a transaction is not valid unless the sum of debits equals the sum of credits (and, no, you can't have both nonzero debit and credit in one line, though sometimes both are zero).
Accounting is, of course, way older than computers, so accountants like to regularly "close the books" (checkpoint the state and generate reports).
Aside, I think the mental block for techies when it comes to accounting is just that many don't want to accept that accountants understand accounting. It looks like databases to them, and those are TECH!
Well, they are databases. That doesn't imply accountants don't understand accounting. Both can be true.
I think a large factor in the "programmers reinterpreting accounting" phenomenon is the fact that accounting is full of somewhat idiosyncratic terminology and conventions which are somewhat counter to modern mathematical conventions. These conventions should still be upheld in order to be mutually intelligible with the accounting world, but it seems quite unlikely they are the optimum in terms of ergonomics and ease of understanding. If we designed accounting from scratch today, I doubt we would end up with these conventions.
A naive programmer is perhaps in one of the best positions to see these idiosyncrasies and think "This is using the wrong conventions and can be made much simpler by just shifting some signs around!".
Ex-finance SWE here. I closed the article after that part. If you don't understand accounting and read this, you'll only be more confused when you learn how accounting actually works.
For the most part, devs in general should not be teaching accounting. There's a reason that it is so challenging to earn a CPA.
>For the most part, devs in general should not be teaching accounting. There's a reason that it is so challenging to earn a CPA.
Surely there's a big difference between earning a CPA and just knowing the basics of accounting.
I had a summer job helping out with entry in a family member's small accounting firm. I don't think that double entry accounting is that crazy of a concept that it cannot be grasped by someone without a degree in the field.
Yes I agree, a vast difference between basic accounting and a CPA. I am not a CPA, but I do understand accounting.
That doesn't change the fact that I'd be wary of any accountant writing a blog post on how to write good quality code for production. Are there accountants out there who can do a good job of that? Absolutely. Are there many more accountants who would do a poor job of that? My guess is also yes.
I agree with your statements. If someone has spent three years studying accounting, I would certainly expect that he or she is able to blog coherently about double entry accounting.
I wouldn't call it wrong per se, but it's about what would happen if I as accountant designed a database architecture. It would work, but any programmer looking at the dodgy code would think "omg what have you done?"
The traditional accounting identity is something like "Assets = Liabilities + Equity", or in an expanded form "Assets = Liabilities + Contributed Capital + Revenue - Expenses - Dividends" (from Wikipedia https://en.wikipedia.org/wiki/Accounting_equation). You can re-arrange that as:
Traditional accounting takes this as says: "All accounts have positive values. All transactions contain an equal number of debits and credits. Debits always come first, are always written on the left, and so it (sort of) makes sense for debits of left hand side accounts to always increase the value of the account, while debits of right hand side accounts always decrease the value in the account. Similarly, credits come second, are always written on the right, credits of right hand side accounts increase the value of the account, and credits of left hand side accounts decrease the value of the accounts."
It turns out if you work through the implications of this, it works perfectly. I buy lunch for $5, so I must have a $5 debit and a $5 credit. That's an expense; my expenses are going up, expenses are on the left, so they go up via a debit. The matching credit could be to cash; cash is an asset, it's also on the left, credits make left hand accounts go down, that makes sense. Or the matching credit could be an accounts payable account, that's on the right hand side, and credits make right hand accounts go up, which again makes sense.
The core logic here is that changes must balance. If your changes are both on one side, one will be positive and one will be negative (summing to 0). If your changes are on opposite sides, either both will be positive or both will be negative (still summing to zero).
But, you could also re-arrange the equation further:
Algebraically, that's the same. If you built a system on that, you could say something like "All transactions must sum to zero. Asset, expense, and dividend accounts are subtracted from the balance, while other accounts are added to it." That still works. My $5 lunch increases expenses, which is a "negative type" account, so I have to either increase a matching "positive type" account (like liabilities) or decrease a matching "negative type" account (like assets) so everything stays zero. It doesn't feel...easier, but it works.
Or you could take it a step further, and weirder, and say:
I dunno, this is getting a bit weird. Now my $5 lunch is a $5 credit and a $5 debit. Expenses has gone up, so that must be what the author calls a credit, but since expenses is a magic negative account the displayed value will go down. And then we must have a match debit (in the authors terms) which will make an account go down. And again, we can pick assets to go down (if I spent cash), except again assets is a magic flipped account so will make the displayed value of assets increase, or we could pick liabilities which is a normal account and thus the value will actually go down.
Technically, all this is interchangeable. However: The standard form (LHS = RHS, debits increase LHS and decrease RHS, credits increase RHS and decrease LHS, debits = credits) is universally used around the globe, and has been in active use since the middle ages. It's also, in my view, relatively intuitive once explained. The middle form (all accounts sum to zero) is unorthodox, but also fine. Both require to ...
Spot on. This is another situation of trying to solve a problem that doesn't exist and the writer does not understand at all. There are reasons why GAAP and IFRS exist. Accounting can make a lot of sense to a programmer, I've moved between fields early on with relative ease because accounting is extremely rule based/puzzle-oriented and adheres to a structured and specific framework. I haven't touched accounting in years (though I do have a bachelors in accounting) but this is jarring and would not recommend this to anyone.
Nothing too special, I worked for a few large tech consulting companies early on in finance but did a bunch of a side development projects/freelance work as well. One of those ended up becoming a full-time gig so jumped ship and went from there.
Well, if you want to define accounting in an alternate universe, you can define it that way.
However, if you want to describe accounting as it is done, it is utterly wrong. Doing this will bite you once you read other sources on accounting, talk to accountants, the tax office, etc.
From my experience, if you're doing accounting beyond a hobby, you likely want to follow whatever GAAP (generally accepted accounting practices), and likely need to consult references for how specific cases are represented. If you then don't use the same language and conventions as everyone else, it's just even more of a pain than it is.
My experience here is that I was with a large audit company, albeit as an actuary rather than an accountant. I did have the opportunity to dig quite deep accounting records of insurance companies there. Now I own an incorporated company and do my own accounting and taxes (with GnuCash for accounting, even if I hand-rolled reporting for XBRL export and all).
I kind of expected to see a good, pragmatic explanation of why double-entry accounting is useful, the kinds of mistakes it catches, etc... kind of weird to see almost no emphasis on the double-entry nature at all.
I agree: it catches entry errors, which is really handy in a system where you're hand-writing them twice.
But if you're writing a computer system that's simply duplicating one entry from a human in two places in data store, is that "double entry"? is it useful?
But the idea that you would want to reconcile one view with another independently reported one is super useful. (Almost every financial-oriented company builds a system like that, I would bet.)
I once used Mint, which is single entry. One day I logged into my account and noticed my net worth is a bit off. Looking at my monthly expense and income, I didn't see anything out of ordinary, so I just shrugged it off.
A couple of months later I finally realized I opened new savings account to take advantage of a promotion and forgot about it. The opening deposit was deducted from my checking account. Since it's classified as a "Transfer" it doesn't show up in expenses. I linked the account, and now I am a few thousand dollars richer than I previously thought.
This kind of mistake will never happen in a double entry accounting system.
It was then I began migrating my personal accounting to a double entry system I developed myself. Hopefully I can make it available to the public soon :)
"debits and credits balance" is a very useful constraint to have in your system in order to maintain data integrity. Transactions can also get quite complex - think of a salaried payroll deposit - this is a transaction with 5-10 splits from various accounts. Even a typical ecommerce sale might have 4-5 when you include commissions owed, shipping, sales tax, etc.
One thing I really appreciate about YNAB is that they ditched the obscure words with murky Latin roots and rules to memorize about flipping signs and whatnot, and just used the words "inflow" and "outflow". They don't mean anything different in this context than "debit" and "credit." But still, somehow, when you use the traditional words, the topic seems to be as difficult to explain as monads, while with the YNAB terms it ends up being obvious and intuitive.
The problem with "debit" and "credit" is that everyone learned the words backwards, thanks to the banking industry's terrible UX. "Your" debit and credit accounts are actually the bank's accounts for their relationship with you.
So when you start being your own enterprise, you have to unlearn the two most fundamental words you know.
This is the right model, and the easiest way to explain it. It's all stocks and flows. A balance is a stock, a transaction is a flow. A flow has to happen between two stocks, and the sign in each side is opposite so it adds to zero
Depreciation is also neither a credit nor a debit.
Doesn't one normally handle depreciation by creating an expense account called "depreciation", and recording the depreciation as a debit in the asset account and a credit in the depreciation account?
And couldn't one just as easily word that as, "We track the depreciation by creating an account for it, and recording a flow of money into it from the asset's account?"
Yes, but the other way around: you debit the "Depreciation" expense account (since it is the sink, it increases) and credit the asset account (it is the source, it decreases).
I used ledger [1] to track all of my expenses for roughly four years. It's a command line based double entry accounting tool. It was super interesting in terms of figuring out where money went and general double entry accounting techniques.
That said, it was a ton of work to keep up to date given that I was trying to track money when I spent it vs when it cleared my bank account, and those two often varied by several days. Add on top of that three kids and various purchases my wife would make, and it just became too much of a hassle. But it also helped me understand where my money was going each month much better.
The whole double entry idea is basically that every time there is a flow of money, it is going from one place and to another.
This is what I use as well and I concur it can become pretty tedious. My biggest issue is with Amazon purchases - I can enter everything in at the time of purchase but Amazon will batch together various charges, so what I have in my ledger never matches my credit card statement unless I carefully sum the correct batches together. First world problems, I suppose.
Depends what you mean - signs for input or signs for output?
If the reactions to TFA are any indication, compared to the amount of effort you have to go through to explain the credit/debit notation, account signs are fairly straightforward.
Just start from the rule that assets are positive and you can derive the rest with some fairly basic examples.
For output? I guess you could apply some sign normalization so that Income or Accounts Payable would be positive, but if you understand where the signs come from I don't see the benefit in dropping them.
The other thing to know is that Ledger itself isn't aware of what constitutes a debit vs. credit (or a "naturally positive" vs "naturally negative") account, so you'd have to tell it up-front which ones should be sign-normalized for display.
Can’t tell whether it’s intentional as part of this slightly modified approach, but under classic accounting the contribution in the first example would be equity not income.
I’m glad more accounting software is out there but tbh as accountant I can’t see myself using this. The whole debit always decreases thing kills a core part of the mental framework I use to reason through more complicated scenarios. I guess that doesn’t particularly matter though for the target audience coming at it with no prior knowledge.
It might be more accurate to say that Western accounting evolved before the concept of negative numbers became widely accepted in the Western world. Negative numbers were invented (or "discovered", depending on your preferences in the philosophy of mathematics) in China, and from there spread to India, and from India to the Islamic world by the Middle Ages. But when Western mathematicians learnt about them from Arab/Islamic mathematics, there was a lot of philosophical pushback – at first, Westerners didn't think the idea was valid. The idea was rather alien to the Western philosophical tradition originating in Plato and Aristotle. It was only really in the 19th century that Western mathematicians overcame all their philosophical objections and embraced them wholeheartedly. And then it took even longer for the concept to spread from academic mathematics into other disciplines and general education. By then, a lot of the Western tradition of accounting and bookkeeping had already formed without any reliance on the concept of negative numbers. (The concept of "credit" and "debit" serves a somewhat similar function, but is not quite the same concept.)
And accountants do use negative numbers. But, maybe if modern Western accounting had developed in a culture that looked on negative numbers more positively (excuse the pun), they might use them much more than they do?
> And accountants do use negative numbers. But, maybe if modern Western accounting had developed in a culture that looked on negative numbers more positively (excuse the pun), they might use them much more than they do?
The division of accounts into credit- and debit-normal with a strong anti-negative-entry bias (to the point of contra sub-accounts for recurrent activities that go in the opposite direction of the parent account’s normal) seems to me like it provides an important QC feature, especially when books are kept or reviewed manually. It's a lot easier to see “this is not the kind of thing that belongs in this account” than “that is not the right sign for that activity”. And the resulting categorizations are useful in their own right, and it's important to remember that accounting is not just about adding numbers, but about categorizing the associated activities.
Gee, you're the first in the whole thread to have actual arguments instead of "B-B-But, you're wrong, I can tell because school told me !", thank you for that (and making me reconsider my position) !
One of the best developer-oriented explanations of accounting I've read is "Accounting for Computer Scientists" by Martin Kleppmann.[0] He explains double-entry accounting visually in terms of graph theory. Even though I'm not very good at graph theory, I found the diagrams and explanations extremely intuitive.
It just clicked for me what to "open an account" acually means. Literally adding a node to the DAG, or in the old school accounting world, creating a new page in the entry book.
Here's one for computer scientists: "Accounting for Computer Scientists" by Martin Kleppmann [1]. It was discussed on HN [2]. There have been several reposts of it since then, including one 8 months ago, but only the original got any discussion.
Yeah, Klepperman's is the best explanation I've read of accounting. (And I had a college course on the subject). The clarity of it reminds me of the classic "Calculus Made Easy" text.
In contrast, the article in this post is terrible. Tons of footnotes referring to exceptions. I feel like the author is trying to summarize a subject he doesn't understand himself.
I learned double entry accounting. "Debits decrease and credits increase" is just one way to represent the numbers; I have also seen the other way around (where debits are positive). But more commonly, the presentation is such that debits increase the accounts on the left, and credits increase the accounts on the right. (Nevertheless, the explanation there does work.)
Some time ago (while I was bored in the accounting class), I invented "matrix accounting" (I was trying to invent something else, specifically, using complex numbers in accounting, which I concluded was impossible, but matrix math works). In this matrix accounting, "debits" and "credits" don't really exist and the presentations mentioned above are really just different eigenvectors. The accounting equation has this form:
<BAL|FSV> = 0
(Note that all of the components here are real, and not complex; also note that financial vector space is a kind of projective space.)
BAL stands for "balance", and FSV stands for "financial state vector". Let's say that you have a transaction T, where $500.00 is debited to one account and credited to another account; in mathematical notation, this can be written as:
T = I + |A>$500 - |B>$500
or:
T = I + |A>$500 + |B>$500
depending on what basis you are working with (since you can just define |B> to point in the opposite direction if you want a different basis vector).
Unfortunately, I don't have a complete write up on the computer. I could take the time to write it (since I know how it works, and could write about it), although I do not want to do right now (but maybe later).
Note to people looking for job security: there is a HUGE need for developers who understand finance. The fundamental problem is that most finance people can't speak the language of software development (the biggest problem I've seen is that finance people tend to be very poor at writing out a spec of what the software should do - they're much better at looking at a set of examples and then telling you if the calculations are right or wrong). Similarly, most software developers don't know enough about the intricacies of the finance world when building financial software.
I had a colleague who (over years of experience) got to be so good at teasing out requirements from the finance people that I called him "The Finance Whisperer". His skill at crossing the finance-software worlds was unparalleled, and he could command a large premium for this knowledge.
There would surely be a huge amount. Another space where you'd need a whisperer would be anywhere near regulatory data. E.g. government mandating data is reported in a certain way. These are domain specific and typically cruel and unusual.
Health and tech. In the US the CURES act rules just went into effect. Personal health records are ours, finally, and workflows around managing and leveraging for life extension, health, quantitative self are just in early, early stages.
Real estate and tech. Rona is a full on once in a lifetime disaster for much of the industry. All of the financing models are going to collapse. But the buildings are still going to be there. And there is, finally, after 25 years, a full digital title workflow. So from the smallest details of managing them to the biggest deals in financing, selling, servicing, earning, and tokenizing- green field.
Neither; 25 is somewhat arbitrary, and I'm very much not an expert in the space, just an interested observer, but generally speaking the idea that the various artifacts and workflows needed to establish and trace and transfer and finance and so forth real property could be fully digital and supported by adequate legal infrastructure started in earnest in the mid 1990s with MERS [1], early eNote [2] work, and many others. I don't have good references handy for early work on digital titles themselves, but my understanding is that this also started, more with the rise of PCs than the internet specifically. This all has only recently reached maturity, and now COVID has accelerated adoption [3].
There's a lot of very antiquated technology still kicking around in the finance sector, especially banks. You will likely end up working on mainframe code. It's something to bear in mind when considering making it a career path.
Big banks. I used to work at Morgan Stanley - they value this intersection a lot.
In my group, there were business analysts and developers. Guess who got more comp and recognition within the company? And there were a select few who could do both - they were intensely valued.
It's good career advice especially if you're working in a capacity where engineering is supporting a business, rather than the business itself.
Any sort of mid-to-large e-commerce company will have a large back-office ERP system (e.g. SAP, Oracle Financials, etc.) that needs to correctly account for data coming from the user-facing transactional systems (i.e. the website or mobile apps). How the transactional data from your runtime systems (usually stored in a relational DB) is accounted for in these ERP systems is tricky and can have big implications if not done correctly.
Those businesses are about transactions. Now think about assets, deposit and cash management accounts, and debt. Not so much about companies, but transformation of industries.
Yup. I just commented above to someone, saying their accounting BA before switching to CS was a waste of time. Too bad they feel that way. Opportunities for that combination have never been brighter. Enormous niches in debt and banking are in the midst of a wholesale tech transformation.
I'm not so sure. I reckon you just hire the people who know a lot about finance in to a Business Analysis role and you're OK. You don't need single brains that know everything, just people working well in a team.
Completely disagree. I'm not saying the dev needs to know everything about finance, but they need to know the nuts and bolts and how things that finance people care about translate down into software. Most importantly, they need to be well versed in the language of finance so they can have intelligent conversations with the finance people.
Just sticking another "Business Analysis" person in the mix just means there are more hand-off points where things can slow down and get confused.
We are probably both right - and the difference is in the size of company. For a start up you probably don't want a BA. Well you do, but as a role not a title. That person you call "developer" is really a hydra with many hats.
For a bigger company, the BA path (or SME - Subject Matter Expert, might be a better term) is like bringing in a expert in the team on finance. No different to bringing in a MongoDB tuning expert, or a React expert. Yes the developers need to learn some MongoDB/React/Finance etc, but the expert is worth having.
And having the expert reduces your need for unicorn people, the 10xers etc, and you can hire regular coders who are keen to learn a bit of subject matter (they should always be!) and the smart thing to do is send them on a course (rarely see this done in the real world - the normal approach is to let them introduce a bunch of bugs, get heat from QA and learn that way).
Oh wow, I posted this earlier and assumed it hadn't been picked up. From people's comments here it sounds like I may have missed the mark on some of this. Pull requests always gratefully received.
None the less, the result has been some software which seems to have worked well for those that have used it. I certainly haven't received any angry issues.
Hey! Hope any criticism didn’t come off too harsh. I appreciate the effort that went into this!
I checked out the GitHub repo. I’m a CPA who’s getting into web development and has some Django experience. Would definitely be interested in contributing.
Hey! Only just see this comment, no worries at all. I can take it all in my stride :-)
I think Hordak could really do with a version 2 anyway. There are a number of issues open which I think would make for a big improvement, but would also result in breaking changes. I'm not precious about the codebase either, it hasn't been a priority for me for a while and it would be great to see it given some love (especially from someone with a better knowledge of accounting than I!)
Definitely get in touch if you are interested in being involved. I'd be happy to add you as a maintainer after a pull request or two.
Not an accountant or a mathematician, pt 4 reminded me of an issue I had dealing with numbers in a table. The annoying thing that happens with SUBTRACTION (i.e. the process that generates negative numbers) is 2 milion - 2 million and 2 - 2 both give the same result. What is lost, is whether a big change has happened or a small change.
And sometimes when change happened I didn't want to loose that info so I used addition instead and put it in a "special" column.
Way back when I first tried switching to using Open Source alternatives to my previous apps, I wanted a Quicken alternative and tried GnuCash. Opening the help for the first time, I found it hilarious and ever so "open source software" of them that the help document opened with a whole chapter on how double book accounting worked, because of course you'd need to know that if you wanted to use GnuCash well.
"GnuCash" was the first thing I looked for when I opened this thread. This application is an absolute godsend and I'm not sure why it's not more popular with developers. It takes some getting used to / setting up, but once you understand how it works it will revolutionize the control you have over your finances.
Balance Sheet Accounts carry over every year. Things like cash, accounts receivables and payables, loans and equity in the company carry over year after year.
Income Statement Accounts close out at the end of the year and close in to the equity and cash parts of the balance sheet (depending if a dividend was declared). The Income statement accounts are zero at the beginning of every fiscal year. The balance sheet accounts carried over from the previous year.
One example of the above to illustrate the mechanics of double entry accounting:
Lets say you bought a car for your business in cash. you would credit cash (to decrease your cash account) and debit an asset account (a balance sheet account) for the car. when you depreciate the car over time you would credit the car account at some interval for the depreciation amount thus reducing its value and debit the expense in the current period thus increasing expenses in the current period.
The reason I know this is because completed an undergrad at ASU in finance/accounting and then CS after that. It was waste of time.
Presumably that means the Finance/Accounting was a waste of time. That's too bad. From an opportunity perspective the combination of accounting and CS has never been stronger. The tech in debt and banking is going through total wholesale rebuilding over the next 10 years. Asset tokenization changing the definition of ownership. On and on. Hope you get to leverage that special expertise. Good luck.
Please take a look at document [1] by author of beancount regarding how to do double entry accounting, including introduction to single entry bookkeeping. So far I find this is the best resource for developers to learn about accounting along with illustrations. Debit and Credits are introduced later once the basics are explained in details grounded in accounting principles in play for thousands of years.
Not only is Martin Blais' explanation very helpful, his software, Beancount, is also very suitable for any personal finance projects, especially if you have a background as Developer.
Personally, I combine beancount with fava and find it much better than e.g. GnuCash.
Is beancount the kind of tool that's mostly useful if you put a lot of time into it, like Emacs? Or is it immediately useful with even small investments of time?
I found it easy to get started with the very basics (e.g. recording of simple transactions) and I'm just reading up more over time on how to handle more complex things like splitting expenses with a partner or investments. Thanks to Python I was also able to customise my setup almost right away.
There is also an Emacs mode for those who have already made that investment.
I found ledger-cli (upon which beancount is based) immediately useful. However, since you mentioned Emacs, I should say that I use ledger-mode in Emacs to add entries. But I do most of my reporting directly on the command line.
If you're familiar with double-entry bookkeeping, I found it very easy to get started. If you're not, it will take some time to familiarize yourself with that concept.
1. The sum of all accounts is zero: that's the fundamental equation. Nothing about assets, liabilities or equity.
2. A transaction updates at least two accounts, by applying deltas to them. The sum of the deltas is a transaction zero. Because of that (1) continues to hold.
3. Accounts which represent outside interests in the business run negative: these include loans and owner's equity. For instance, if the business somehow makes $1000 out of thin air, its cash account goes up by $1000. At the same time, because the owner has interest in the business, the equity goes down by $1000. Equity is like a loan that the business owes to the owner. Or, if the business gets a loan for $1000, the cash goes up; but the loan account goes down by $1000. Other accounts are what the business has, and run positive, like expenses, cash and assets. E.g. if a routine $50 expense is covered, cash goes down by $50, expenses goes up by $50.
4. Expensese are periodically reconciled (e.g. end of year): they cancel out equity. If there is -$1500 equity, and $500 expenses: poof: expenses are blasted to zero, and equity goes to $-1000. (Of course, expenses are also, separately of this, used for claiming tax deductions and whatnot.)
That's it; no confusing debit/credit nonsense, with an increase in such and such account being a debit, but an increase in another kind being a credit. That system is deliberately twisted so that people of typical intelligence need to rely on expensive accountants.
#1 and 2 are generally correct. Personally, I would remove the quote "nothing about assets, liabilities or equity". Accounting is "all about" those accounts.
#3 couple edits:
Change "the equity goes down by $1000" to "either equity or liabilities will increase by $1000". Equity will either remain the same or increase when a business obtains $1000 out of thin air.
Change "the loan account goes down by $1000" to "the loan account goes UP by $1000". Obtaining a loan will increase cash/increase liability accounts.
That is wrong; the equity and liability accounts run negative in this view, because they represent external interests in the business. When equity increases, the equity account representation of it decreases; i.e. decrements toward negative infinity.
> Equity will either remain the same or increase when a business obtains $1000 out of thin air.
By "out of thin air" I meant that the business doesn't owe the money other than to its owners as equity. Like say the business won that in a lottery or something.
> Obtaining a loan will increase cash/increase liability accounts
You don't get the system obviously; you're thinking in the broken credit/debit system.
Though in accounting you have to be clear about what you have versus what you owe, and transactions must target the correct accounts in order to make sense, there is no need to befuddle the fundamental equation with those details. It is much clearer mathematically to have the fundamental equation be "all accounts always add to zero". That's it; no mention of their "type". Likewise, the increments/decrements in a transaction just have to add to zero.
This is the same as conservation laws in physics; e.g. integral over a closed path over a conservative field. Or the Kirchhoff voltage law (sum of voltages around an electric circuit is zero).
Debit/credit accounting is like designing a circuit in which for some silly reason we decided to mix conventional current and electron current! Oh, this is a liability resistor, so we use electron current, but this is an asset capacitor, so we use conventional current. The circuit law then doesn't add to zero, unless you remember which elements need to have their sign flipped, and you end up with strange rules like equity volages equal asset voltages minus liability voltages.
Can you imagine doing such a thing when designing a device with hundreds of parts? Yet, big ledgers can likewise have hundreds of accounts. Then a corporation needs a small army of accountants to keep a simple thing straight.
It's not just the adding to zero that is crystal clear, but the polarities of the accounts. When I see a negative balance account in the ledger, I have a good idea that it's an equity/liability account just from the balance alone. Minus means owing, plus means having: very clear.
Ah, but the simple matter of fiddling with the sign has ramifications. You end up with people having to cram mnemonics into their heads like DEAD CLIC, and PEARL. On top of that, there are awkward limitations like a transaction having to work with exactly two accounts, one of which is debited and one of which is credited. The actual numeric deltas applied to the two accounts by the debit/credit can be any of the four combinations: UP/UP, DOWN/DOWN, UP/DOWN, DOWN/UP.
Under the sum-to-zero system, it's very simple. Negative-running accounts is what the system owes to the outside, including to its owners. Positive accounts are what it holds. It doesn't own anything: all of what it holds is either owed to its owners, or else to other creditors, so the sum is zero.
A transaction can update two or more accounts. The only rule is that all the deltas in the transaction add to zero.
That's as far as keeping balance is concerned: of course, the transaction has to reflect reality and accounting principles. For instance, if $1000 is injected into the business somehow (the company wins a lottery draw), that could be mistakenly applied as "+1000 cash, -1000 bank loan" which validates, due to summing to zero. But it looks like the company made a $1000 draft against the bank loan, which doesn't reflect what happened. The correct transaction is "+1000 cash, -1000 equity": the company is $1000 richer and so the owners have a greater interest: it "owes" more to the owners. (It's sort of as if the owners actually got the money, and loaned it to the business).
The debit/credit system's rule that a transaction must have a credit and debit of equal size also do not prevent bad transaction semantics: transaction from using the wrong asset or liability/equity account. It's just a gratuitous complication which provides exactly the same sanity check as summing to zero.
In my accounting system for self-employment, I have transactions that update four or five accounts. In double-entry, that would have to be done via an awkward series of binary debit/credit pairs. Moreover, I also have some "virtual" accounts: pairs of accounts that maintain precisely opposite balances that sum to zero. These accounts provide figures useful for reporting. For instance, suppose that transactions for receiving income are broken down: income doesn't go into a single lumped account, but some of it into "cash", some of it into "income tax withholding", and some into a third account like "health fund". But, for the sake of periodic income reporting, we need the whole lump together. For that, we can instantiate a virtual account pair "income" and "income-neg". In the same transaction, "income" receives the total, and "income-neg" the additive inverse of that to keep the ledger balanced. We can query the "income" account to see the lumped income, and not have to ferret that out of the income transactions.
> (the company wins a lottery draw) The correct transaction is "+1000 cash, -1000 equity"
In the end it will come to that (when the books are closed) but to be able to generate correct income statements you may need to create some kind of income account for that gain.
> (It's sort of as if the owners actually got the money, and loaned it to the business).
If we’re talking “accounting for developers”, I’d like to plug the FOSS accounting system we wrote which uses event orientation to model the entities that a business owner actually things of (invoices, wages, etc). Side effects like taxes and legally required artifacts can be generated by rules.
We’ve used it successfully for the last years to do our companies bookkeeping.
I'd recommend you avoid this article. It is more confusing than necessary, and the accounting entries (at least in the first example) are wrong/unconventional.
The articles mentioned by dragonsh (Beancount documentation) and mtlynch (Martin Kleppmann's site) are great. But I feel unsatisfied by the way they discourage understanding of debits and credits, by just giving you something to memorize, e.g.
"Now, by convention, accountants flip the sign on all of the blue and pink nodes’ balances, which means that the two sums end up being equal. And that’s why it’s called a balance sheet."
You don't need to memorize which accounts are negative and which are positive. Just relate them to the English words 'debtor' (someone who owes money) and 'creditor' (some who is owed money), and you can work out the right entries for any transaction.
You credit (CR) an account when you're recording:
- an increase in the amount your company owes, or
- (equivalent) a decrease in the amount some other entity owes your company
The other entity could be a supplier, a customer, or one of your own shareholders.
Examples of credits that can be identified by the above rule:
- A customer pays you some money they owed you: CR 'Assets - Accounts Receivable'
- A supplier sends you an invoice: CR 'Assets - Accounts Payable'
- You send an invoice to a customer: CR 'Revenue'
The last example might be confusing at first. Why is revenue like something you 'owe' someone? Because any profit the company you make does not really belong to the company, but to the shareholders.
If you can work out whether one side of a transaction is a debit or a credit, you know the other side is the opposite. So, for the above transactions:
I think simplest rule for remembering what debit and credit mean is that "debit" means "deposit/indebted" and "credit" means "to give someone credit".
Thus for an account debits means increases in the amount held by the account and credits mean decreases. Because it is Double Entry an increase somewhere is always a decrease somewhere else. When we deposit an amount to an account we must also credit another account which tracks where that amount came from.
I prefer to think of it as if every account had a person who is in charge of that account. If money comes out of the account we give "credit" to the person in charge of that account. And when we deposit to an account we debit it, in other words the person in charge of the account becomes "INDEBTED" by that amount.
I think I understand the mechanics of double entry bookkeeping, but what I find confusing about it is that it is the redundancy. People emphasize the error detection, but these errors can only exist in the first place because of the requirement to record each transaction twice. Also you get a lot of "fictious" or virtual accounts that don't correspond to concrete piles of cash or bank accounts.
It seems much easier to me to just record the transactions ($100 from bank account to shop on date). Then you can generate balanced account sheets from this automatically.
But you can go further and look at the actual cash flow. This is something you can't easily do with double entry: how much money did I have on day X? How much money will I have approximately on day Y? Will any asset fall below a certain value? And make nice graphs out of everything.
> People emphasize the error detection, but these errors can only exist in the first place because of the requirement to record each transaction twice.
That's like saying that check digits in credit card numbers detect errors that only exist in the first place because we entered more digits. Or that checking the md5sum after downloading a binary file detects errors that only exist in the first place because we downloaded two files instead of one.
Not really. In double entry bookkeping you have to always add every entry "twice" (I'm not sure how prevalent it is to have split entries, $20 in one and $10+$10 in another - I've learned in school that you don't do that).
I'm just suggesting a different entry format where you enter the number once and the computer creates both bookkeeping entries. Yeah you have the chance to make a typo, but I guess preventing that kind of error is not what this is about, is it?
It's actually not like a checksum, but more like the DRY (don't repeat yourself) principle. Where one framework requires you to define a constant, say a SQL table name, in multiple places, and another lets you type it only once. Like handrolled SQL vs- an ORM. In this case, I think less typing is less error prone.
> Yeah you have the chance to make a typo, but I guess preventing that kind of error is not what this is about, is it?
That's the kind of error it catches, where you entered one of the entries (say, the cash outflow) and not the other (say, the invoice you were paying) or they were not consistent.
Note it's not always as easy as "this number goes into two places". One entry in one account may correspond to multiple entries elsewhere (say, price plus tax). At least that's what I think, nobody told me not to do that or I don't remember...
"The purpose of a trial balance is to prove that the value of all the debit value balances equals the total of all the credit value balances. If the total of the debit column does not equal the total value of the credit column then this would show that there is an error in the nominal ledger accounts."
Any increase in redundancy should increase the raw error rate. However, with a credit card check digit or md5sum file the additional data is relatively tiny compared to the data it's responsible for checking, so you're much more likely to catch an error than to introduce a new one. Double-entry bookkeeping, in the traditional sense where you actually record every detail about each transaction separately in two or more journals, is more like a RAID-1 mirror: double the data, so approximately double the raw error rate, and if a discrepancy does turn up you'll have no idea which entry was wrong and which was right. But if you lose a journal outright you can recreate it from the mirror image.
So far as I know, most actual "double-entry" accounting software just stores each transaction once in a general ledger. The appearance of doubled entries is all in the UI where it processes the ledger to present a list of transactions from the perspective of a certain account. You still get the benefit that the system won't allow the balance of one account to be increased or decreased without an equal and opposite change in other account(s)—money cannot be created or destroyed[1], only moved around.
[1] Unless you're the Federal Reserve. They play by different rules.
I didn't see the purpose of it when I got told of the principle at school. The supposed control of error detection feel like a very vague benefit to me. Especially now with computers. Actually hashing of the chain of values would probably be more secure (like bitcoin yes).
However, I think the real value in double entry accounting is that it not only represent money you have but also things you own: If you buy a pen, you have less money, but you have an extra furniture pen and your accounting can reflect that. It can also reflect the loss of value of the pen over time.
It is also useful if you get in debt to buy something: you transfer money from a debt account to your current account, you buy the thing you wanted to buy and appropriatly report the value of what you own in accounting. You now have a thing, and a debt to be repaid in whatever term was agreed.
It's also very useful as a tool of control for state. All exchanges you have with other entities are recorded in a separate account. It's possible to take that account and check that the other entity accounting book match exchanges they have with you.
I agree, I don't understand how creating two entries in two separate locations is a good thing. You have to constantly monitor that you have matching entries everywhere. No thanks.
Instead, have a master list of transactions with money in/out in each transaction. As long as every transaction balances, you are golden.
Balances, history, cash flow, etc. can all be figured out from this one central location.
The idea would be that the form of the transaction doesn't allow you to screw up - it is neccessarily balanced because you only give the amount once. A bit like a typed language only allows well-formed programs to run.
Modern accounting systems like most ERPs allow you to specify the account and offset account in one line. It pretty much like you describe and is the preferred method for simple entries with only two accounts.
It gets a bit trickier when, for example, sales tax is involved where a simple example for a sale of $1.000 with 25% VAT would be:
236 comments
[ 4.4 ms ] story [ 217 ms ] threadROA, ROE, etc come from the above formula.
That would make some sense.
assets + liabilities + equity = 0
Seemed much more general. Double entry just became: everything (transactions, whole companies) sum to zero. Then just one other little thing (where money comes from in a transaction is positive, where you put it is negative) and you have the math.
IMH(and not accountancy)O
Think of it this way. When you start a company, you invest $100. For the company accounting, that is $100 in the bank account/asset and $100 in equity. $100 - 0 - $100 = 0
Now you take a loan for $100. Now you have $200 in the bank account, a $100 liability, and $100 in equity. $200 - $100 - $100 = $0.
Money in your bank account is _negative_. It is a _debit_ in your accounts (this is not my invention this is true). Your bank account statement is from the bank's perspective. The money came from you, so it is a credit from their perspective only. Try to submit your statutory accounts with 'bank credit' and you'll get in trouble! Your software or accountant will definitely flip it to become a debit!
Your transaction to start your account:
Equity: $100 (or $100CR)
Bank account: $-100 (or $100DB)
Loan:
Debt: $100 (or $100CR)
Bank account: -$100 (or $100DB)
Accounts:
Assets > Bank account: $-200 (or $200DB)
Liabilities > Debt: $100 (or $100CR)
Equity: $100 (or $100CR)
Making assets positive in code is conventional.
You can kind of see the easy rationale there. I'm not sure it's very deep though. Revenue is in the same group (Credit). And the assets are like expenses (Debit). That is a bit more of a just-so-story in my mind.
> Making assets positive in code is conventional.
Are you sure? What code are you talking about?
Making everything positive in the UI is certainly common. And not showing whether a value is credit or debit. But I really hope my accountancy software isn't coded that way! It needs to track whether a number is a credit or a debit. It could do it with an unsigned value in a struct with a 'is_cr' Boolean and some custom operations to combine the money structs. But I've only ever seen code using signed values, because it is so much faster and less errorprone. Doing it manually is just reinventing the math of negative numbers. And then, the overwhelming convention is the former is positive, the latter negative, not the other way round.
Signed values are the way to go!
100% agree!
> For one example, read the docs for Beancount, which is mentioned above.
Do you have other examples too?
You are dead right with this one. It is the opposite way to the way the systems I'm familiar with did it. Debit is positive, And credit negative.
Thanks so much for the link.
I'm still not sure what I would concede that it is conventional ;) But my assumption it was nothing but the other way is definitely incorrect!
I wonder if they did it this way because they felt people would understand negative income being a good thing better than a negative bank accounts being a good thing. The bank account is usually the big problem with understanding debit and credit.
As usual, the world is more complex and interesting then I assume!
In a computerized system, one of these accounts carries a negative balance, the other a positive balance. A choice has to be made - but it's not a matter of good or bad.
There are several implementations of the Ledger system. The transaction registers and GL are human-readable. I looked at Ledger, and assets were positive.
I looked in the code for the GNUCash engine, but there are so many features that I didn't manage to get to the bottom of it w/o spending too much time on it :-)
I do recollect working with low level GC transaction data years ago, and I think I would remember if the assets were negative.
There are a couple of Wikipedia pages with links to FOSS accounting systems.
Say I have two million dollars and deposit one million in the bank and buy a one million house.
What is the value of my assets? -$2mn? $0mn? Something else?
The "confusing" answer would be that the value of my assets (which is equal to the value of my equity, as I don't owe anything to anyone) is two million dollars.
But let's say you started with DB$2m (inheritance say, or you won the lottery). You end with DB$2m assets.
I'm not reinventing anything here. Where do you want to label your $2m as 'debit' every time, or use negative numbers, either way is the same.
People do always struggle when learning accounting to comprehend how money in their assets is debit. Because they are so used to seeing 'credit' on their bank statements. But it is only credit because there was from the banks point of view.
Is that less confusing than total assets being $2mn when you have two assets worth $1mn each?
But if you are doing accounting, debits and credits and balancing is important.
So yes, if you are happy to ignore debit/credit/balanced books, you are welcome to view asset as $2m. And lots of the simple accounting software will show it that way.
But by the time you are having to understand different types of accounts and different types of money in it, I think it is easier to use negative numbers are rather than CR/DB.
Believe it or not, I’ve seen financial accounts quite more complex than two lines (and they never included those CR/DB annotations in the balance sheets or income statements).
> I’ve seen financial accounts quite more complex than two lines
Definitely.
For hundreds of years the convention has been columns. Credit values in the right-hand column, debit values in a left-hand column. The column is the label of which type of money it is. Most accountancy software (other than very simple personal tracking apps) use this when displaying.
Your printed bank statement probably does (and it may label the columns credit and debit as well, though never line by line, iirc). Mine did back when paper was the thing.
Digital bank statements usually do use negative numbers (DB being negative, as I've been saying). You are used to seeing this, but not used to thinking in your own accounting terms rather than theres. Which is fine. But there is a reason that accountancy education has to undo that assumption.
But most people would find your idea of using negative numbers for assets rather idiosyncratic.
It's more natural to say that the assets of Goldman Sachs are $1trn than to say that they are -$1trn, for example.
Most lay-people find double entry in accounting idiosyncratic. It has this bad reputation for being full of special case rules.
It is interesting that the one comment I got from an accountant on here it seemed fine with debit as negative numbers.
Goldman Sachs absolutely know that they have DB$1tn! Anyone who thinks it is either a credit account or just a bare number is not going to be dealing with that!
Thanks for carrying on the chat.
Did it display assets in the balance sheet as negative numbers?
> the one comment I got from an accountant on here it seemed fine with debit as negative numbers
Was that accountant fine with assets as negative numbers?
> Goldman Sachs absolutely know that they have DB$1tn!
The did have $1tn in their balance sheet. No DB, no CR. Just $1tn.
It's an API. There are many tools built on top of it, many with UIs. I'm sure they display things in many different ways for people internally and externally. The system I was working was back-end. It used negative numbers for debits. And it was really important you didn't confuse credit and debit numbers.
> Was that accountant fine with assets as negative numbers?
I find it hard to believe they didn't understand that's what Using negative numbers for debits means. They would be pretty aware that assets are debit accounts.
> The did have $1tn in their balance sheet. No DB, no CR. Just $1tn.
Did they have a complex balance sheet (I.e. beyond that just a couple of lines summary) with no columns? How do they represent a balance if you couldn't tell which were credits and debits?
And that makes sense. You can see the balance. Because it will balance. Or you'd know which of the things were debit accounts and which went credit accounts.
Yep.
But I definitely bet it's not raw unsigned/untyped numbers behind that document! I suspect we've just been mismatching on different levels: I began this discussion about developers understanding double entry bookkeeping. I would be surprised if you could get very far if you didn't understand the difference between debit and credit. But your pushback makes sense. Thank you.
People want assets to be positive in the balance sheet. This may be a convention but it's a reasonable convention. I don't think you're helping developers who try to understand accounting by telling them that assets are negative quantities (it may make sense as an implementation detail, but not so much as an accounting concept).
1. positive numbers represent the default for an account (A positive number in a debit account is a debit, but a positive number in a liability say, is a credit). This is done a lot. But he causes a lot of rules about when to add and went to subtract what the balance with what. I think this is why they lot of double entry bookkeeping and has a hard reputation. Certainly if you coded it you would have to code all those rules manually.
2. The approach I'm used to of having negative numbers in the debits and positive credits. This makes all the double accounting balancing much simpler. But I can see it may confuse some people when assets are negative.
3. Make credits at the beauty of an debits positive (incidentally I only today learned that beancount does it this way). Again balancing and double-entry accounting becomes simpler. Now money in the bank would be positive, like your bank statement. But sales income would be negative (it is a credit). I wonder if that would confuse people.
So maybe that's why UI should make everything positive and undifferentiated. But given the amount of time the Accounting 101 has to drill in all the rules of what
So, if people were able to overcome their confusion, would you have balance sheets written like this?
If you really want to change the signs in one of the sides, so instead of getting the same totals they sum to zero, it would make much more sense to do it the other way: keep assets positive and let liabilities be negative (as other commenters have suggested). But one property of the usual presentation is lost: equity is no longer equal to net assets (which are $90265mn). You would need to change the sign of equity when considering it as an asset.It does tend to cause some confusion, but IMHO less than you would get with negative asset balances, much less the traditional version where "credits" and "debits" have different signs depending on the type of account and nothing ever just sums to zero.
The less confusing way to think of it is that an income account represents not "how much income have I received" but rather the source of the income, e.g. your employer or customer. They paid you, so they have less than they started with.
⋄ Money moves from employer to me: decrease "Income:Employment" and increase "Assets:Cash".
⋄ Money moves from me to my landlord: decrease "Assets:Cash" and increase "Expenses:Rent".
⋄ Deposit money at the bank: decrease "Assets:Cash" and increase "Assets:Bank:Checking".
⋄ Take out a loan: decrease "Liabilities:Loan" (negative since I owe them money) and increase "Assets:Cash".
Note that Income and Expense account balances are relative—which is why it makes sense for Income balances to sometimes be negative, and why these accounts are zeroed out at the end of the reporting period with transfers to or from equity—in contrast to most other accounts which have absolute balances.
It's just simple basic maths formula, A = L + E so it's either 0 = L + E - A or A - L - E = 0, or A - L = E or A - E = L all stands true.
is true because L and E are Credit dollars and A is Debit dollars. And the total Debit is equal to the total Credit.
But instead of using debit and credit unsigned dollars, you can use negative numbers: Credit is Positive, Debit negative.
In that case
(-Assets) = Liabilities + Equity, so A+L+E=0
-Assets because you've made those debit dollars negative.
In fact you don't even have to remember which. Sum(Everything)=0. 'Balancing' means summing to 0.
The software I am aware of that does large-scale double entry calculations for large banks works this way (I did some consulting 15 years ago on data laundering for that system). And all those accounting rules about what accounts are debit or credit accounts, whether a credit increases the debit account, etc, it all isn't needed at a low-level. The confusing bits are only in the UI. Where a number stored as -10 is displayed as 10DB, while +10 becomes 10CR.
So it's definitely not 'just simple maths'. It is the convention you use to express numbers: turning debit numbers into positive, and having rules to keep the math consistent in other places. And since the original article was aimed 'at developers', I think that the widespread negative number format is much stronger.
CPAs are the OG Luddites, refusing to use negative numbers to make their jobs simpler and easier to understand.
If we deduct everything that we owe (Liabilities) from everything that we own (Assets), whatever is left belongs to the shareholders (Equity).
Or you can use negative numbers and everything just works.
Your financial software _will_ use my approach. As do the most sophisticated software of the most complicated companies. But their presentation gets mangled through a complicated series of rules for archaic reasons.
So how does this actually work? Say I worked for 8 hours at $25/hr. I get a $200 deposit in my checking account; that increases my assets. How is the sum still zero?
Income > Work: $200 (or $200CR)
Assets > Bank Account: -$200 (or $200DB)
This is exactly how it would be stored in any software system behind-the-scenes, and how it would be submitted in statutory accounts. The only thing that makes this look weird is that you are used to seeing your bank account statement with 'credit'. But that's only because the bank account statement is from their accounting perspective.
Money comes from somewhere (Positive, Credit); it goes somewhere (Negative, Debit).
The entire confusion about signs and what to add and remove, and what categories 'increase' with debit or credit, it all disappears when you allow negative numbers. I guarantee your accounting software _will_ simply store them as positive or negative. It is frustrating that it appears so complex simply because of avoiding negative numbers.
If you're talking about the bank's perspective, why is that relevant to me? I'm just asking about how to do my own accounting.
I am not inventing this. Money in your bank is debit in _your_ accounting.
You are very welcome to treat it as positive and add. As long as you keep track of where every positive number is a credit or a debit, and you learn all the rules about which accounts to add and which ones need taking away.
Or you can just treat credits as positive numbers and debits as negative.
Literally the only 'weirdness' is that money you have put somewhere for future use (like a bank) is negative.
Your initial reaction might be "that's just nonsense and ridiculous!" But I guarantee that is how your accountant and accountancy software is storing it. Your bank balance is debit from your accounts. Legally and intuitively. The only reason it is weird is because you receive statements from the bank from their perspective (a credit because they received the money from you).
If you have made it to junior high school you are quite capable of the math. Treat debits as negative and credits as positive. No accountancy ed / special rules needed.
If you want to get it more intuitive you can think of it as: Negative numbers are money that you put somewhere and is now owed to you. If you have $1000 in 'your' account, legally that means you are $1000 down because you are owed that money by the bank. It is your debit. You have given them credit.
It may not feel like a loan because it feels like you can get the money any time you want. But loans you have given and bank accounts are both assets in your accounting. They are both debit. They are both money you have put somewhere.
> Literally the only 'weirdness' is that money you have put somewhere for future use (like a bank) is negative.
But that is literally what I'm talking about. Whether the sign is positive or negative isn't the issue. It just makes no sense for this to be a zero-sum game, is all I'm saying. You're telling me if I get $200 out of the blue I suddenly owe someone that $200 instantly? How does that work?
Transactions always balance. Money always comes from somewhere, and it always goes to somewhere. Total debit always equals total credit.
In a double entry accounting system you have to say where that $200 came from.
Did it come from a sale (you sold your work, an item), a loan you took, someone you loaned money yourself, or an investment in your company.
In double accounting it always balances.
Here I am talking debit and credit because this is nothing to do with my point about positivity or negativity. This is how double entry bookkeeping works.
If you make all the numbers positive, then the total credit has to equate ('balance') with the total debit.
So treating debit as negative and credit as positive, means 'balancing' is just summing to 0.
Before double entry bookkeeping was invented in the Renaissance, single entry accounting just kept separate lists for all things. This works for basic tracking of money. For individuals particularly. But has massive weaknesses for tracking where money is coming from how it moves around, and making sure there aren't errors. Money doesn't come out of the blue. Which is why it is the business standard. And the legal requirement in most of the world. One of the most amazing and significant human innovations, IMO.
The credit and debit/what to add/what to subtract rules are only because double entry accounting was invented before use of negative numbers (they were only a weird mathematical curiosity at the time).
So I am not reinventing anything.
In double entry accounting you track where money came from to you. You are right in not having to worry where they get their money from. But you do have to track how/why it came to you.
You will have an account in your accounting of 'income' (it's usually called 'Revenue'). If you have even the slightest complexity in your business, you will have many income accounts. Some businesses will definitely track at the level of detail where they have accounts for each customer, so they can see who purchased how much.
Each transaction balances.
Each line in a transaction is associated with an account.
So if you have done 50 weekly transactions of:
Revenue>Consulting $1,000CR
Assets>Bank $1,000DB
Each one balances.
But in total you will have $50,000CR in Revenue>Consulting and $50,000DB in Assets>Bank, but your company will still balance.
If you pay yourself $45,000 in salary from that, let's say in one go at the end of the year (to save me typing) you would have a transaction:
Assets>Bank $45,000CR (it came from your bank account)
Expenses>Salary $45,000DB (it went to your salary)
So at the end, your accounts are:
Assets>Bank $5,000DB
Revenue>Consulting $50,000CR
Expenses>Salary $45,000DB
This still balances. Double accounting always balances companies and transactions.
Historically it balances credits and debits. All I'm saying is it makes more sense to think of debits as negative and credits as positive, and all the math becomes much much simpler. Which is how accounting software is written.
- The idea is that every source/destination ("node") of funds keeps their own account for every node they deal with. And every transaction ("directed edge") necessarily needs to be tracked by both accounts in an equal and opposite manner.
- This is mainly only useful for businesses, as they generally have multiple sources of income (and/or multiple creditors) and need to be able to explain/track them. (At least as far I can see, I don't really see much of a point in doing this for the average person.)
The only slight curve ball in your part one is that transactions are not always between two accounts. The joke is that 'double entry' sometimes has more than two.
The classic example is sales tax. E.g. a transaction:
Revenue>Product $100CR
Liability>Sales tax $5CR
Asset>Bank $105DB
(Although the specific form/standard categories will massively depend on how sales tax works in your jurisdiction.)
There are plenty of other examples (in my consulting: the customer paid some their bill in advance, or I pay a bill in a different currency and have to pay a fee).
So I like the idea of making it a topology question, but it would be nice if it were only two.
So, you credit your income account (income generally reflects your effort "going out" - did you have to make someone like you to get a gift?)
And you debit your cash account $200. Everything is balanced.
At the end of the year, you close your books by debiting income and crediting owner's equity. That's you. Congratulations!
(See my post on debit/credit above).
An account doesn't have to be money that you actually owe someone and have to pay back, but regardless of whether you have to pay the money back or not, you still want to track where the money came from and where you put it.
The amounts have to balance because you can't create or destroy money unless you are the Federal Reserve.
You would increase assets by $200, since you got that much cash (cash is an asset). You would increase equity by $200 as well (often accountants will call that "Owner's Equity") since your personal stake in this business (yourself, here) has gone up. That's the double entry.
"I found the core explanation of double entry accounting to be confusing. After some time I distilled it down to the following:
"Debits decrease the value of an account. Always. [1] Credits increase the value of an account. Always. [1]
"[1] (1, 2) This is absolutely not what accountancy teaches. You’ll quickly see that there is a lot of wrangling over what account types get increased/decreased with a debit/credit. I’ve simplified this on the backend as I strongly feel this is a presentational issue, and not a business logic issue."
I mean, this is just....wrong. Maybe I'm not smart enough to see why this isn't completely incorrect? I mean I feel mathematically this will work but goes against so many core accounting principles it won't have much use except in the simplest of cases.
Maybe this might work for a bank where assets and liabilities are sort of flipped from a non-bank business?
It would not work for a bank. The only reason they 'sort of flip' is that they give your account from their perspective. Your statement is a slice of their accounting.
For example - if you're holding someone's money for them, that's a liability - you have to pay it back some time. If someone owes you money, that's an asset - it's worth something. Banks use the cash from liabilities (people's savings accounts) to pay for assets (mortgages) and make money on the spread.
Let's see, when they lend money they don't have (which is what it is) they increase the number on your account, that is they create a big liability for themselve. On the other hand they create an asset wich is your debt to them. So accounting-wise, it works out, like theorically I could do that (lending) even if I have €0, it's all paper.
But then you're gonna go and empty that account to buy your house, reducing their liability and taking (reducing) their cash instead... that they don't have !
So how does it work ? Does it just work because you don't actually buy houses with bills and coins but with bank transfers, then just shifting the paper magic to another bank ?
To be honest I know they can do something my broke self can't, and it has to du with central banks, but what is it exactly ? Something like "if everybody happens to empty their account to cash at the same time, don't worry mate we'll print them bills and give them to you, pinky promise" ?
All account balances should normally be positive. Depending on what side of the balance sheet they are, a debit or credit could increase or decrease an accounts balance.
It's beyond wrong. The developer here is redefining established accounting terms because he doesn't like their inconsistencies.
How so?
> The developer here is redefining established accounting terms because he doesn't like their inconsistencies.
Yes. What's wrong with fixing inconsistencies? Established accounting terms are from 500 years ago when people had trouble with subtraction.
In general, nothing. It's just not the software developer's job. If the accounting profession decided to change certain terms to fix inconsistencies, that would be fine.
If those records don’t make sense to an accounting professional, then they’re fucked up, and that’s all she wrote. The world of audit has seen a million shysters try to falsify their books under the guise of alternative methods, and they are not interested in some self-serving hubris from programmers about re-inventing their own profession.
So this guide isn’t just philosophically off beam. It could get someone fired or sued.
Probably not prosecuted though. Probably.
One of the businesses I worked for did online invoicing and they initially started off without double ledger accounting. I was employee 30 or so and I kept repeating "we need double ledger accounting" every month or so. Nobody really listened to me (to be fair I was young, but this was after the telephone invoicing job) until the cracks started to form. It took them years to transition to a new system. Do not re-invent accounting with your own terms. International commerce runs on it and it has figured out a lot of the edge cases.
The law does put some constraints on what accounting software must and must not allow users to do (e.g change data without leaving a trace).
But I'm not aware of any specific legal requirements regarding data representation or mandating the use of specific algorithms where mathematically equivalent ones exist.
Nothing, if you can convince the entire user base to do it at the same time. If you decide to unilaterally fix inconsistencies, you've just made it impossible to understand what anyone is saying without additional metadata saying which version you're using.
And if you start telling learners that your "fixed" version is all there is, hiding the actual standard that most of the world uses, you are basically lying to them and setting them up to fail.
This is important if you want to share your books or reports with your local tax office, who will begin investigating you for committing tax fraud. It's the same reason why no one fixes the HTTP "Referer" header typo. You can, but if you do then you'll have difficulty communicating with the outside world.
I think OP is encoding the sign-reversal internally though, right? It "displays" the two incorrectly classified account types exactly per the standard convention instead of re-applying the convention at every operation. All reports would follow the 'Classic' conventions. At least that was my reading!
In beancount, the accounting equation is Expense+Income+Equity=0 and all signs are always left intact (there is only addition).
So you start a company with a seed capital of $5. You borrow $5 to the bank, buy an expensive apple for $10, sell it for $15 and give the money back to the bank with an interest of $1, then close the exercise and carry the profits (don't distribute dividends). Your ledger is:
Notice how every transaction balances to 0 just by summing it, no need to remember anything.Now, you're at the beginning of the next exercise. To know your accounts you just compute a sum of every operation to it, again no special case. So your accounts are:
And yet again, the sum of all of that is 0.Personally I like it, not having any special cases. Yes, it may confused an accountant (because they learned the special cases by heart ! Somebody coming with a fresh mind has no reason to be confused, it's all just conventions !) but it's simpler for me and just as consistent.
There are no inconsistencies to fix; the credit/debit model is fully consistent, just implementation inconveniences. And I don't think anyone would have trouble with this if it was titled “implementing double entry accounting in software” rather than “double entry accounting for developers”; that is, it's a fairly decent explanation of how, if you have preexisting understanding of the domain, to reduce it to software internals, but very bad as an explanation of the domain (whether to an audience of developers or otherwise.)
> Established accounting terms are from 500 years ago when people had trouble with subtraction.
People still have trouble with substraction compared to addition, especially with large numbers.
We have an algebraic indentity, a + b = x + y. (Let's not even think about what those might represent; it doesn't matter.)
The two sides must always be equal. Any transaction must maintain that equality. Therefore, any transaction must increase both sides by the same amount, decrease both sides by the same amount, or leave both sides unchanged.
One way to ensure this is respected is to add up everything which increases the left side or decreases the right side, then add up everything which decreases the left side or increases the right side, and ensure these two subtotals match. If they do, the transaction balances, and is legal.
By convention, we call things of the first type (which increase the left side or decrease the right side) "debits", and things of the second type (which increase the right side or decrease the left side) "credits". This lets us say "debits must equal credits" as a shorthand, although again what we really mean is that the two sides must continue to balance.
The end. There's really no inconsistency here.
The easy way to remember this is just to think that the right hand side is what you think it should be, and the left hand side isn't.
Double entry book keeping is under appreciated - it's one of the earliest examples of error correction and detection coding kicking around.
Let’s say you have a bank account. Your view of that account is opposite from the bank’s view.
You have $100 cash. That’s an asset from your POV, and it carries a debit balance on your books - when you received it, the cash “came in”.
You walk into the bank and deposit it. The cash goes out of your books, but an asset (the increase in your bank account) comes onto your books. You credit cash and debit asset.
From the bank’s POV, cash came in - they debit their cash account. And they credit your account in their books. That account is a liability from their POV - they owe you the money.
Notice how the debit and credit to cash even balanced across entities. If you talk about pluses and minuses, you’ll get confused quickly.
One of the worst things that ever happened was banks issuing “debit cards”. When you take cash from an ATM, it’s a debit from the bank’s POV. The bank carries your account as a liability, which carries a credit balance. (You are the bank’s creditor!)
So the bank debits your account (credit came in again) and credits their cash (cash went out).
You credit the bank account on your books (asset went out) and debit your cash (cash came in)
Just remember that a “debit card” reflects the banks POV and don’t let that confuse you about the meaning of “debit”. Debiting an asset is generally a good thing!
When making accounting transactions, debits always balance credits - meaning they total to zero in the code itself. It’s conventional to make assets positive (hey, having lots of assets is good, right?).
OP gains nothing but confusion by turning everything upside down.
That is the complete opposite of common usage. When I get a credit on my credit card statement, it means money is coming in to me. When I get a debit on my debit card, it means money is going out from me. It's not rocket science, or at least it shouldn't be. And yet somehow accountants have managed to turn it into something even more confusing.
Your credit card is linked to an account in someone else's books. They opened that credit account for you.
Debits come in to an entity, credits go out.
> That is the complete opposite of common usage.
Nah, it's exactly the usage you are used to from statements you get.
> When I get a credit on my credit card statement, it means money is coming in to me.
When you get a credit card statement, it's a statement of the portion of your account in the card issuer’s books.
If you were keeping books for the card, they would be mirror images of the bank’s books.
Your credit card account is an asset from Visa’s POV. And a liability from your POV.
When Visa refunds that fee, it reduces their asset. And on your books, it reduces your liability.
A debit on your books is a credit on the counterparty’s books. A plus on your books is a minus on the counterparty’s books.
I agree. However, the problem is that you can either make the vocabulary consistent or you can make the math simple, never both.
Making the math simple means you have to make a decision to always treat debits as positive and credits as negative or the other way around. You just have to be consistent.
Making the vocabulary work means you have to switch signs based on account type. But that makes the math and hence the software complicated and error prone.
Assets being positive makes sense. But debiting an asset account to make it more positive is counter intuitive. And expenses being positive doesn't make much sense either, because having lots of expenses is not so good, is it?
We're just accepting the inconsistent vocabulary as a price for having a simple mathematical model.
Expenses come in and cash goes out. Debit expense, credit cash.
From an accountancy POV, the debits of a transaction equal the credits. From a software POV, the account changes total zero. There is a difference in what the word “balance” means.
It’s likely the only reasonable implementation of a blockchain but we won’t know that for sure until cryptocurrency matures enough to develop reasonable controls. I’m not holding my breathe because then it’s just an accounting system with reasonable controls built in and there are already more than enough of those built with databases.
OP has chosen a consistency in the operation of debit+credit sign and applied a 'display adjustment' to implement the classification. This actually sounds like a lower entropy way to remember it -- no left hand/right hand stuff, just 'There two account types are sign reversed on display'. But it will confuse anyone who isn't indoctrinated to the convention, but one could argue that it is these various conventions that make double entry seem arcane in the first place!
Then later after learning about natural account balances, it all made sense. If an account has a debit balance, a debit increases the balance and a credit decreases it. An asset or expense account has a debit balance.
Credit balance is just the opposite. Liabilities, revenue, accounts. Credit is an increase, debit decrease. (I think equity too but I always have to look it up. Rarely work with equity accounts in my day to day)
Why are OE and L on the same side? Well to finance an asset, say a new car for your business, the company would either take on some debt (L) or you’d put in some of your own money (OE) in exchange for more ownership. I don’t know if that’s more confusing or less
BTW, nonprofits have Net Assets accounts instead of Equity accounts.
A transaction has two polarities, because it represents a flow of value. The credit side is the source, the debit side is the sink/destination/whatever. Let's temporarily pretend that every transaction hits exactly two accounts for the moment (which is not true), to make it easier.
Let's say we have $1000 in Cash, which is an Asset, and we want to buy a Pizza, which is also an Asset, for $20. How does this look in accounting?
Cash provides the source side, and Pizza provides the sink. Cash is credited $20, and Pizza is debited $20. If we ran the balances now, Cash would come out to $980, and Pizza would come out to $20.
Let's unwind that transaction. We're a business; we don't trade cash for pizzas. We contract for delivery of pizzas with a pizza vendor, who invoices us.
So here we are, with $1000 in Cash and $0 worth of Pizza. The pizza delivery driver comes, and hands us a pizza and an invoice. We know we have to debit Pizza $20; what is the credit source for this debit? Well, the pizza vendor has actually extended us a loan worth $20, in a sense (this is called "trade credit"), and the offsetting entry is the fact that we owe the vendor $20, as memorialized in its invoice. This goes in a Liability account, usually called something like Accounts Payable.
Current balances (if we ran them - "running the balances" is thought of by accountants as a discrete operation, just FYI):
Accountants think of accounts as being naturally debit-increased, like Assets, or naturally credit-increased, like Liabilities. I find it a bit misleading to try to think of these as positive or negative signs, as you might be inclined to at this point. It's just $20 - don't even think of it as cr $20, IMO. (dr and cr are the abbreviations for debit and credit.)Let's just leave that on the books and eat the pizza. After eating the pizza, we no longer have $20 worth of pizza, so we have to credit Assets/Pizza $20. What do we debit to offset this - i.e., where did the pizza value flow to? In this case, it would be a Depreciation account (these are debit-increased) - something like Depreciation/Eaten Pizzas. So we have:
(a commenter below points out correctly that this would be an Expense, not a Depreciation, and I'm still in the edit window!)Meanwhile, someone pays us on one of our invoices, which we had sent out earlier offscreen. When we delivered our fine $50 widget and invoiced the buyer, we entered that into our accounting system as a debit of $50 to Assets/Accounts Receivable, and a credit of $50 to Assets/Widgets. This part of the system looks like (we still have 9 widgets in stock):
But now that the invoice is paid, $50 of value flows from our receivables asset into our cash asset - i.e., we credit A. R. $50, and debit cash $50. Getting paid is nice. After the customarily long delay, our accounts payable department has approved payment of the pizza invoice. Cash has to be credited, because cash is flowing out, and it's probably easy to guess the debit where it goes to - that's right, our Liabilities/Accounts Payable is finally cleared, because we don't owe the pizza vendor $20 anymore.Ledger entries look (conceptually, not literally) like this:
with the constraint that a transaction is not valid unless the sum of debits equals the sum of credits (and, no, you can't have both nonzero debit and credit in one line, though sometimes both are zero).Accounting is, of course, way older than computers, so accountants like to regularly "close the books" (checkpoint the state and generate reports).
Aside, I think the mental block for techies when it comes to accounting is just that many don't want to accept that accountants understand accounting. It looks like databases to them, and those are TECH!
I think a large factor in the "programmers reinterpreting accounting" phenomenon is the fact that accounting is full of somewhat idiosyncratic terminology and conventions which are somewhat counter to modern mathematical conventions. These conventions should still be upheld in order to be mutually intelligible with the accounting world, but it seems quite unlikely they are the optimum in terms of ergonomics and ease of understanding. If we designed accounting from scratch today, I doubt we would end up with these conventions.
A naive programmer is perhaps in one of the best positions to see these idiosyncrasies and think "This is using the wrong conventions and can be made much simpler by just shifting some signs around!".
Everything else follows from that idea plus a bunch of terminology.
For the most part, devs in general should not be teaching accounting. There's a reason that it is so challenging to earn a CPA.
Surely there's a big difference between earning a CPA and just knowing the basics of accounting.
I had a summer job helping out with entry in a family member's small accounting firm. I don't think that double entry accounting is that crazy of a concept that it cannot be grasped by someone without a degree in the field.
That doesn't change the fact that I'd be wary of any accountant writing a blog post on how to write good quality code for production. Are there accountants out there who can do a good job of that? Absolutely. Are there many more accountants who would do a poor job of that? My guess is also yes.
It's more a case of someone who has one year of writing JavaScript shouldn't be writing on the theory of software development.
I wouldn't call it wrong per se, but it's about what would happen if I as accountant designed a database architecture. It would work, but any programmer looking at the dodgy code would think "omg what have you done?"
Assets + Expenses + Dividends = Liabilities + Contributed Capital + Revenue
Traditional accounting takes this as says: "All accounts have positive values. All transactions contain an equal number of debits and credits. Debits always come first, are always written on the left, and so it (sort of) makes sense for debits of left hand side accounts to always increase the value of the account, while debits of right hand side accounts always decrease the value in the account. Similarly, credits come second, are always written on the right, credits of right hand side accounts increase the value of the account, and credits of left hand side accounts decrease the value of the accounts."
It turns out if you work through the implications of this, it works perfectly. I buy lunch for $5, so I must have a $5 debit and a $5 credit. That's an expense; my expenses are going up, expenses are on the left, so they go up via a debit. The matching credit could be to cash; cash is an asset, it's also on the left, credits make left hand accounts go down, that makes sense. Or the matching credit could be an accounts payable account, that's on the right hand side, and credits make right hand accounts go up, which again makes sense.
The core logic here is that changes must balance. If your changes are both on one side, one will be positive and one will be negative (summing to 0). If your changes are on opposite sides, either both will be positive or both will be negative (still summing to zero).
But, you could also re-arrange the equation further:
Liabilities + Contributed Capital + Revenue - Assets - Expenses - Dividends = 0
Algebraically, that's the same. If you built a system on that, you could say something like "All transactions must sum to zero. Asset, expense, and dividend accounts are subtracted from the balance, while other accounts are added to it." That still works. My $5 lunch increases expenses, which is a "negative type" account, so I have to either increase a matching "positive type" account (like liabilities) or decrease a matching "negative type" account (like assets) so everything stays zero. It doesn't feel...easier, but it works.
Or you could take it a step further, and weirder, and say:
Assets + Expenses + Dividends + Liabilities + Contributed Capital + Revenue = 0
That...uh....doesn't work mathematically, unless you flip the sign of all assets, expenses, and liabilities. So maybe:
(-Assets) + (-Expenses) + (-Dividends) + Liabilities + Contributed Capital + Revenue = 0
I dunno, this is getting a bit weird. Now my $5 lunch is a $5 credit and a $5 debit. Expenses has gone up, so that must be what the author calls a credit, but since expenses is a magic negative account the displayed value will go down. And then we must have a match debit (in the authors terms) which will make an account go down. And again, we can pick assets to go down (if I spent cash), except again assets is a magic flipped account so will make the displayed value of assets increase, or we could pick liabilities which is a normal account and thus the value will actually go down.
Technically, all this is interchangeable. However: The standard form (LHS = RHS, debits increase LHS and decrease RHS, credits increase RHS and decrease LHS, debits = credits) is universally used around the globe, and has been in active use since the middle ages. It's also, in my view, relatively intuitive once explained. The middle form (all accounts sum to zero) is unorthodox, but also fine. Both require to ...
Best of luck!
From my experience, if you're doing accounting beyond a hobby, you likely want to follow whatever GAAP (generally accepted accounting practices), and likely need to consult references for how specific cases are represented. If you then don't use the same language and conventions as everyone else, it's just even more of a pain than it is.
My experience here is that I was with a large audit company, albeit as an actuary rather than an accountant. I did have the opportunity to dig quite deep accounting records of insurance companies there. Now I own an incorporated company and do my own accounting and taxes (with GnuCash for accounting, even if I hand-rolled reporting for XBRL export and all).
But if you're writing a computer system that's simply duplicating one entry from a human in two places in data store, is that "double entry"? is it useful?
But the idea that you would want to reconcile one view with another independently reported one is super useful. (Almost every financial-oriented company builds a system like that, I would bet.)
A couple of months later I finally realized I opened new savings account to take advantage of a promotion and forgot about it. The opening deposit was deducted from my checking account. Since it's classified as a "Transfer" it doesn't show up in expenses. I linked the account, and now I am a few thousand dollars richer than I previously thought.
This kind of mistake will never happen in a double entry accounting system.
It was then I began migrating my personal accounting to a double entry system I developed myself. Hopefully I can make it available to the public soon :)
So when you start being your own enterprise, you have to unlearn the two most fundamental words you know.
Doesn't one normally handle depreciation by creating an expense account called "depreciation", and recording the depreciation as a debit in the asset account and a credit in the depreciation account?
And couldn't one just as easily word that as, "We track the depreciation by creating an account for it, and recording a flow of money into it from the asset's account?"
In which case the depreciation is cr. acc. depreciation and dr. depreciation expense.
That said, it was a ton of work to keep up to date given that I was trying to track money when I spent it vs when it cleared my bank account, and those two often varied by several days. Add on top of that three kids and various purchases my wife would make, and it just became too much of a hassle. But it also helped me understand where my money was going each month much better.
The whole double entry idea is basically that every time there is a flow of money, it is going from one place and to another.
So each transaction has two entries:
1. Where the money is going
2. Where the money came from.
That's really what it boils down to.
[1] https://www.ledger-cli.org/
If the reactions to TFA are any indication, compared to the amount of effort you have to go through to explain the credit/debit notation, account signs are fairly straightforward. Just start from the rule that assets are positive and you can derive the rest with some fairly basic examples.
For output? I guess you could apply some sign normalization so that Income or Accounts Payable would be positive, but if you understand where the signs come from I don't see the benefit in dropping them. The other thing to know is that Ledger itself isn't aware of what constitutes a debit vs. credit (or a "naturally positive" vs "naturally negative") account, so you'd have to tell it up-front which ones should be sign-normalized for display.
I’m glad more accounting software is out there but tbh as accountant I can’t see myself using this. The whole debit always decreases thing kills a core part of the mental framework I use to reason through more complicated scenarios. I guess that doesn’t particularly matter though for the target audience coming at it with no prior knowledge.
>accountants don’t like negative numbers.
That’s the first I hear of that
> That’s the first I hear of that
It might be more accurate to say that Western accounting evolved before the concept of negative numbers became widely accepted in the Western world. Negative numbers were invented (or "discovered", depending on your preferences in the philosophy of mathematics) in China, and from there spread to India, and from India to the Islamic world by the Middle Ages. But when Western mathematicians learnt about them from Arab/Islamic mathematics, there was a lot of philosophical pushback – at first, Westerners didn't think the idea was valid. The idea was rather alien to the Western philosophical tradition originating in Plato and Aristotle. It was only really in the 19th century that Western mathematicians overcame all their philosophical objections and embraced them wholeheartedly. And then it took even longer for the concept to spread from academic mathematics into other disciplines and general education. By then, a lot of the Western tradition of accounting and bookkeeping had already formed without any reliance on the concept of negative numbers. (The concept of "credit" and "debit" serves a somewhat similar function, but is not quite the same concept.)
And accountants do use negative numbers. But, maybe if modern Western accounting had developed in a culture that looked on negative numbers more positively (excuse the pun), they might use them much more than they do?
The division of accounts into credit- and debit-normal with a strong anti-negative-entry bias (to the point of contra sub-accounts for recurrent activities that go in the opposite direction of the parent account’s normal) seems to me like it provides an important QC feature, especially when books are kept or reviewed manually. It's a lot easier to see “this is not the kind of thing that belongs in this account” than “that is not the right sign for that activity”. And the resulting categorizations are useful in their own right, and it's important to remember that accounting is not just about adding numbers, but about categorizing the associated activities.
[0] https://martin.kleppmann.com/2011/03/07/accounting-for-compu...
It just clicked for me what to "open an account" acually means. Literally adding a node to the DAG, or in the old school accounting world, creating a new page in the entry book.
[1] https://martin.kleppmann.com/2011/03/07/accounting-for-compu...
[2] https://news.ycombinator.com/item?id=2298471
In contrast, the article in this post is terrible. Tons of footnotes referring to exceptions. I feel like the author is trying to summarize a subject he doesn't understand himself.
Some time ago (while I was bored in the accounting class), I invented "matrix accounting" (I was trying to invent something else, specifically, using complex numbers in accounting, which I concluded was impossible, but matrix math works). In this matrix accounting, "debits" and "credits" don't really exist and the presentations mentioned above are really just different eigenvectors. The accounting equation has this form:
(Note that all of the components here are real, and not complex; also note that financial vector space is a kind of projective space.)And then, you can have:
It is easy to see that this equation is valid.It has two interesting features:
1. Supports multiple currencies
2. Has a query language that lets you easily get various reports
I had a colleague who (over years of experience) got to be so good at teasing out requirements from the finance people that I called him "The Finance Whisperer". His skill at crossing the finance-software worlds was unparalleled, and he could command a large premium for this knowledge.
Real estate and tech. Rona is a full on once in a lifetime disaster for much of the industry. All of the financing models are going to collapse. But the buildings are still going to be there. And there is, finally, after 25 years, a full digital title workflow. So from the smallest details of managing them to the biggest deals in financing, selling, servicing, earning, and tokenizing- green field.
1. https://en.wikipedia.org/wiki/Mortgage_Electronic_Registrati... 2. https://www.theice.com/publicdocs/eNote_White_Paper.pdf 3. https://www.dlapiper.com/en/us/insights/publications/2020/04...
In my group, there were business analysts and developers. Guess who got more comp and recognition within the company? And there were a select few who could do both - they were intensely valued.
It's good career advice especially if you're working in a capacity where engineering is supporting a business, rather than the business itself.
Just sticking another "Business Analysis" person in the mix just means there are more hand-off points where things can slow down and get confused.
For a bigger company, the BA path (or SME - Subject Matter Expert, might be a better term) is like bringing in a expert in the team on finance. No different to bringing in a MongoDB tuning expert, or a React expert. Yes the developers need to learn some MongoDB/React/Finance etc, but the expert is worth having.
And having the expert reduces your need for unicorn people, the 10xers etc, and you can hire regular coders who are keen to learn a bit of subject matter (they should always be!) and the smart thing to do is send them on a course (rarely see this done in the real world - the normal approach is to let them introduce a bunch of bugs, get heat from QA and learn that way).
None the less, the result has been some software which seems to have worked well for those that have used it. I certainly haven't received any angry issues.
I'll link to this thread from that page.
I checked out the GitHub repo. I’m a CPA who’s getting into web development and has some Django experience. Would definitely be interested in contributing.
I think Hordak could really do with a version 2 anyway. There are a number of issues open which I think would make for a big improvement, but would also result in breaking changes. I'm not precious about the codebase either, it hasn't been a priority for me for a while and it would be great to see it given some love (especially from someone with a better knowledge of accounting than I!)
Definitely get in touch if you are interested in being involved. I'd be happy to add you as a maintainer after a pull request or two.
And sometimes when change happened I didn't want to loose that info so I used addition instead and put it in a "special" column.
If you agree with that assessment, it's interesting to think of blockchain as "triple entry accounting".
[0] https://www.bbc.co.uk/programmes/w3csv3gq
https://plaintextaccounting.org/ is a site listing all of these text based accounting tools out there.
Anyway, while it wasn't the best user experience, it was a pretty good introduction to double entry accounting: https://www.gnucash.org/docs/v4/C/gnucash-guide/basics-accou...
Balance Sheet (Assets = Liabilities + Equity)
Assets (debits increase, credits decrease) Liabilities (debits decrease, credits increase) Equity Accounts (debits decrease, credits increase)
Income Statement (Revenue - Expenses = Income)
Revenue Accounts (debits decrease, credits increase) Expenses (debits increase, credits decrease)
A few rules:
Balance Sheet Accounts carry over every year. Things like cash, accounts receivables and payables, loans and equity in the company carry over year after year.
Income Statement Accounts close out at the end of the year and close in to the equity and cash parts of the balance sheet (depending if a dividend was declared). The Income statement accounts are zero at the beginning of every fiscal year. The balance sheet accounts carried over from the previous year.
One example of the above to illustrate the mechanics of double entry accounting:
Lets say you bought a car for your business in cash. you would credit cash (to decrease your cash account) and debit an asset account (a balance sheet account) for the car. when you depreciate the car over time you would credit the car account at some interval for the depreciation amount thus reducing its value and debit the expense in the current period thus increasing expenses in the current period.
The reason I know this is because completed an undergrad at ASU in finance/accounting and then CS after that. It was waste of time.
[1] https://beancount.github.io/docs/the_double_entry_counting_m...
Personally, I combine beancount with fava and find it much better than e.g. GnuCash.
Here is the smart view:
1. The sum of all accounts is zero: that's the fundamental equation. Nothing about assets, liabilities or equity.
2. A transaction updates at least two accounts, by applying deltas to them. The sum of the deltas is a transaction zero. Because of that (1) continues to hold.
3. Accounts which represent outside interests in the business run negative: these include loans and owner's equity. For instance, if the business somehow makes $1000 out of thin air, its cash account goes up by $1000. At the same time, because the owner has interest in the business, the equity goes down by $1000. Equity is like a loan that the business owes to the owner. Or, if the business gets a loan for $1000, the cash goes up; but the loan account goes down by $1000. Other accounts are what the business has, and run positive, like expenses, cash and assets. E.g. if a routine $50 expense is covered, cash goes down by $50, expenses goes up by $50.
4. Expensese are periodically reconciled (e.g. end of year): they cancel out equity. If there is -$1500 equity, and $500 expenses: poof: expenses are blasted to zero, and equity goes to $-1000. (Of course, expenses are also, separately of this, used for claiming tax deductions and whatnot.)
That's it; no confusing debit/credit nonsense, with an increase in such and such account being a debit, but an increase in another kind being a credit. That system is deliberately twisted so that people of typical intelligence need to rely on expensive accountants.
#3 couple edits: Change "the equity goes down by $1000" to "either equity or liabilities will increase by $1000". Equity will either remain the same or increase when a business obtains $1000 out of thin air.
Change "the loan account goes down by $1000" to "the loan account goes UP by $1000". Obtaining a loan will increase cash/increase liability accounts.
#4 is correct.
> Equity will either remain the same or increase when a business obtains $1000 out of thin air.
By "out of thin air" I meant that the business doesn't owe the money other than to its owners as equity. Like say the business won that in a lottery or something.
> Obtaining a loan will increase cash/increase liability accounts
You don't get the system obviously; you're thinking in the broken credit/debit system.
This is the same as conservation laws in physics; e.g. integral over a closed path over a conservative field. Or the Kirchhoff voltage law (sum of voltages around an electric circuit is zero).
Debit/credit accounting is like designing a circuit in which for some silly reason we decided to mix conventional current and electron current! Oh, this is a liability resistor, so we use electron current, but this is an asset capacitor, so we use conventional current. The circuit law then doesn't add to zero, unless you remember which elements need to have their sign flipped, and you end up with strange rules like equity volages equal asset voltages minus liability voltages.
Can you imagine doing such a thing when designing a device with hundreds of parts? Yet, big ledgers can likewise have hundreds of accounts. Then a corporation needs a small army of accountants to keep a simple thing straight.
It's not just the adding to zero that is crystal clear, but the polarities of the accounts. When I see a negative balance account in the ledger, I have a good idea that it's an equity/liability account just from the balance alone. Minus means owing, plus means having: very clear.
At least you have the good taste of keeping assets positive, unlike other people. :-)
Under the sum-to-zero system, it's very simple. Negative-running accounts is what the system owes to the outside, including to its owners. Positive accounts are what it holds. It doesn't own anything: all of what it holds is either owed to its owners, or else to other creditors, so the sum is zero.
A transaction can update two or more accounts. The only rule is that all the deltas in the transaction add to zero.
That's as far as keeping balance is concerned: of course, the transaction has to reflect reality and accounting principles. For instance, if $1000 is injected into the business somehow (the company wins a lottery draw), that could be mistakenly applied as "+1000 cash, -1000 bank loan" which validates, due to summing to zero. But it looks like the company made a $1000 draft against the bank loan, which doesn't reflect what happened. The correct transaction is "+1000 cash, -1000 equity": the company is $1000 richer and so the owners have a greater interest: it "owes" more to the owners. (It's sort of as if the owners actually got the money, and loaned it to the business).
The debit/credit system's rule that a transaction must have a credit and debit of equal size also do not prevent bad transaction semantics: transaction from using the wrong asset or liability/equity account. It's just a gratuitous complication which provides exactly the same sanity check as summing to zero.
In my accounting system for self-employment, I have transactions that update four or five accounts. In double-entry, that would have to be done via an awkward series of binary debit/credit pairs. Moreover, I also have some "virtual" accounts: pairs of accounts that maintain precisely opposite balances that sum to zero. These accounts provide figures useful for reporting. For instance, suppose that transactions for receiving income are broken down: income doesn't go into a single lumped account, but some of it into "cash", some of it into "income tax withholding", and some into a third account like "health fund". But, for the sake of periodic income reporting, we need the whole lump together. For that, we can instantiate a virtual account pair "income" and "income-neg". In the same transaction, "income" receives the total, and "income-neg" the additive inverse of that to keep the ledger balanced. We can query the "income" account to see the lumped income, and not have to ferret that out of the income transactions.
In the end it will come to that (when the books are closed) but to be able to generate correct income statements you may need to create some kind of income account for that gain.
> (It's sort of as if the owners actually got the money, and loaned it to the business).
But it's not really the same thing.
Right; and that's exactly what I describe in the last paragraph.
intro to financial accounting
https://www.youtube.com/watch?v=ZkZ6Q67Q15E&list=PL259DBFA47...
intro to managerial accounting
https://www.youtube.com/watch?v=2cC9SZ3RC8Y&list=PLHhe-2tIHR...
We’ve used it successfully for the last years to do our companies bookkeeping.
https://github.com/200ok-ch/easy
The articles mentioned by dragonsh (Beancount documentation) and mtlynch (Martin Kleppmann's site) are great. But I feel unsatisfied by the way they discourage understanding of debits and credits, by just giving you something to memorize, e.g.
"Now, by convention, accountants flip the sign on all of the blue and pink nodes’ balances, which means that the two sums end up being equal. And that’s why it’s called a balance sheet."
You don't need to memorize which accounts are negative and which are positive. Just relate them to the English words 'debtor' (someone who owes money) and 'creditor' (some who is owed money), and you can work out the right entries for any transaction.
You credit (CR) an account when you're recording:
- an increase in the amount your company owes, or - (equivalent) a decrease in the amount some other entity owes your company
The other entity could be a supplier, a customer, or one of your own shareholders.
Examples of credits that can be identified by the above rule:
- A customer pays you some money they owed you: CR 'Assets - Accounts Receivable'
- A supplier sends you an invoice: CR 'Assets - Accounts Payable'
- You send an invoice to a customer: CR 'Revenue'
The last example might be confusing at first. Why is revenue like something you 'owe' someone? Because any profit the company you make does not really belong to the company, but to the shareholders.
If you can work out whether one side of a transaction is a debit or a credit, you know the other side is the opposite. So, for the above transactions:
CR 'Assets - Accounts Receivable' / DR 'Cash'
CR 'Assets - Accounts Payable' / DR 'Expenses'
CR 'Revenue' / DR 'Assets - Accounts Receivable'
Thus for an account debits means increases in the amount held by the account and credits mean decreases. Because it is Double Entry an increase somewhere is always a decrease somewhere else. When we deposit an amount to an account we must also credit another account which tracks where that amount came from.
I prefer to think of it as if every account had a person who is in charge of that account. If money comes out of the account we give "credit" to the person in charge of that account. And when we deposit to an account we debit it, in other words the person in charge of the account becomes "INDEBTED" by that amount.
It seems much easier to me to just record the transactions ($100 from bank account to shop on date). Then you can generate balanced account sheets from this automatically.
But you can go further and look at the actual cash flow. This is something you can't easily do with double entry: how much money did I have on day X? How much money will I have approximately on day Y? Will any asset fall below a certain value? And make nice graphs out of everything.
That's like saying that check digits in credit card numbers detect errors that only exist in the first place because we entered more digits. Or that checking the md5sum after downloading a binary file detects errors that only exist in the first place because we downloaded two files instead of one.
I'm just suggesting a different entry format where you enter the number once and the computer creates both bookkeeping entries. Yeah you have the chance to make a typo, but I guess preventing that kind of error is not what this is about, is it?
It's actually not like a checksum, but more like the DRY (don't repeat yourself) principle. Where one framework requires you to define a constant, say a SQL table name, in multiple places, and another lets you type it only once. Like handrolled SQL vs- an ORM. In this case, I think less typing is less error prone.
That's the kind of error it catches, where you entered one of the entries (say, the cash outflow) and not the other (say, the invoice you were paying) or they were not consistent.
Note it's not always as easy as "this number goes into two places". One entry in one account may correspond to multiple entries elsewhere (say, price plus tax). At least that's what I think, nobody told me not to do that or I don't remember...
And it's literaly a checksum.
https://en.wikipedia.org/wiki/Trial_balance
"The purpose of a trial balance is to prove that the value of all the debit value balances equals the total of all the credit value balances. If the total of the debit column does not equal the total value of the credit column then this would show that there is an error in the nominal ledger accounts."
So far as I know, most actual "double-entry" accounting software just stores each transaction once in a general ledger. The appearance of doubled entries is all in the UI where it processes the ledger to present a list of transactions from the perspective of a certain account. You still get the benefit that the system won't allow the balance of one account to be increased or decreased without an equal and opposite change in other account(s)—money cannot be created or destroyed[1], only moved around.
[1] Unless you're the Federal Reserve. They play by different rules.
However, I think the real value in double entry accounting is that it not only represent money you have but also things you own: If you buy a pen, you have less money, but you have an extra furniture pen and your accounting can reflect that. It can also reflect the loss of value of the pen over time.
It is also useful if you get in debt to buy something: you transfer money from a debt account to your current account, you buy the thing you wanted to buy and appropriatly report the value of what you own in accounting. You now have a thing, and a debt to be repaid in whatever term was agreed.
It's also very useful as a tool of control for state. All exchanges you have with other entities are recorded in a separate account. It's possible to take that account and check that the other entity accounting book match exchanges they have with you.
Instead, have a master list of transactions with money in/out in each transaction. As long as every transaction balances, you are golden.
Balances, history, cash flow, etc. can all be figured out from this one central location.
This is how ledger-cli works.
It gets a bit trickier when, for example, sales tax is involved where a simple example for a sale of $1.000 with 25% VAT would be: