I think the most important equation to understand about accounting is assets = liabilities + equity
ROA, ROE, etc come from the above formula.
ROA, ROE, etc come from the above formula.
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)
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
Deposit
Asset>Cash in Hand $1m
Asset>Bank: $-1m
House purchase
Asset>Cash in Hand $1m
Asset>Property: $-1m
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.
ASSETS
======
$1mn Cash (in the bank)
$1mn House
----
$2mn
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
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.
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
$ 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
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.
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.
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.
Assets = Net Equities
That would make some sense.