Double Entry Accounting for Developers | Hacker News Reader

Double Entry Accounting for Developers

django-hordak.readthedocs.io

390 pointsadamcharnock233 comments

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.

[1] https://beancount.github.io/docs/the_double_entry_counting_m...

Thanks, this was very helpful.

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.

Beancount+Fava is awesome if you're a developer who understands double-entry accounting.

Accountancy is(was?) widely taught in South African high schools. It was certainly quite common in the 1990s.

I found it quite amusing when I realised that double-entry isn’t widely understood around the world, a realisation I came to after I first encountered one of many confusing “accounting for developers” posts on HN.

It was quite easy for us 13 year olds to grasp:

Assets=owners equity +liabilities (accounting equation) A=O+L

Rules: Left side of equation: Increase in an asset: debit. Decrease in an asset: credit.

Right side of equation: Increase in liabilities: credit Decrease in liabilities: debit

Increase in owners equity: credit Decrease in owners equity:debit

Expenses decrease equity, income increases equity. Capital increases equity. Drawings decrease equity.

For every debit, there must be a credit. Every transaction fits into this framework, and every transaction must balance the accounting equation.

Your bank statement appears to be reversed, because it’s written from the perspective of the bank: for them, a deposit by you increases their liability to you (a credit). Similarly when you owe them money, it’s an debit, since from the bank’s perspective, your debt is an asset to them. (Bank reconciliation is another thing we did in school.)

This really isn’t rocket science.

Also surprised by all these articles. But your point made me realise that most people didn't do accounting in high school like I did (also a South African). I wonder what some other uncommon high school curriculums from other parts of the world are.

In retrospect I wish what we learnt in High School was more focussed on personal finance than essentially constantly doing double entry data capture.

I suspect accounting is a topic common in commonwealth countries curriculum (heh no pun intended) - Australia included it as well.

But the UK doesn't! That probably tells you something about the UKs relationship with the commonwealth.

It's not compulsory, but it's available at GCSE and A Level; also in General Knowledge A Level I think.

Granted they have a bit of a reputation for being 'lesser' subjects. I don't really agree that everyone needs to be taught this though, most Britons don't have to 'do taxes', and aren't running companies. It should probably form a part of trades' apprenticeship training (and for all I know it does) due to the higher prevalence of self-employment (and thus running a business, and self-assessing tax even if not incorporated).

chicken and egg

India here (also commonwealth). Accounting wasn’t in high school curriculum but tax calculation was.

No accounting in the French general high school curriculum. And I can’t see it being introduced (it would be seen as an unacceptable intrusion of capitalism in education).

The stumbling block for me learning it was understanding how to record the simplest and most common transactions like buying a banana. Surprisingly many explanations only use examples like paying your home mortgage where the credit and debit side of things are clear. But then they never tell me about where on earth does my banana go as a credit since I'm not stockpiling bananas to later sell. Even though that use case is almost all of my transactions!

To an expense account.

If your banana is for consumption and you pay cash: Then debit Food Expenses (decrease equity) and credit Cash (decrease assets). Accounting equation is balanced.

If your banana is for resale and you pay cash: Credit Cash (decrease assets) and Debit Trading Stock (increase assets). Accounting equation is balanced.

If your banana is for consumption and you buy it on credit from your supplier: Credit Loan account (increase liabilities). Debit Food Expenses (decrease equity). Accounting equation is balanced.

If your banana is for resale and you buy it on credit: Debit Trading Stock (increase assets). Credit Loan account (increase liabilities). Accounting equation is balanced.

If your banana is for resale and it spoils before you sell it: Credit Trading Stock (decrease assets) and Debit Spoilage Expenses (decrease equity). Accounting equation is balanced.

If your banana is for resale and you sell it [this one I'm a bit rustier on, it's been 25 years, but I'm pretty sure it's correct]: Debit cash (increase assets). Credit Sales income (increase equity). ALSO Debit Cost of Sales (an expense, so decrease equity). Credit trading stock (decrease assets). Accounting equation is balanced. (Your Gross Profit is reflected in Sales minus Cost of Sales).

Granted, these are unsophisticated examples, and based solely on decades-old high school-level accountancy, but I think your banana example should be covered here.

It doesn’t quite. You’ll also need to consider allocations and accounting for tax (sales and income), depreciation, transaction fees, warehousing, shipping revenue and expenses, revenue and expense recognition, discounts, returns, overpayments, prepayments, futures, chargebacks, refunds, credit notes, invoicing, subscriptions, subsidies, tariffs, reconciliation, adjustments in the current financial year, adjustments for already reported periods, gains & losses on foreign exchange, and subledger roll-up for your parent fruit company’s GL.

You’ll need to maintain consistency and coherence in multiple combinations of the above, and when the auditors show up, be able to show unequivocally that you understood every edge case when recording and reporting transactions, especially the ones that crossed a financial year boundary.

Accounting software mechanises all this. It is not simple.

I specifically stated it was an unsophisticated example. GP wanted to know what happens with the "simplest transaction" when he buys a banana.

Yeah, exactly. The first or second example in any explanation should be buying a banana that you immediately eat. That way the reader sees that an "account" doesn't have to be a bank account nor even a collection of physical goods that exist, it's just a virtual bucket made to keep track of certain transactions. Until I figured that out, double-entry made no sense at all. This is all exacerbated by the common "Assets = Liabilities + Equity" equation which hides expenses entirely. All of this is, of course, a problem about pedagogy in the quick guides found all over the internet. (Including the one linked to here, though the second example is at least an expense but not in the way that would enlighten a beginner.)

That was the simplified version.

Apples and oranges. By way of analogy, the OP was talking about C while you are describing building a commercial Windows app. DE accounting is a simple tool that can be used in complex ways.

OP is neither, it is in Python, but this merely demonstrates that accounting can be incorrect in any language.

The problem isn't just terminology, but when people use the term double-entry accounting interchangeably with double-entry book-keeping, they reveal how little they know about the subject matter, and how unqualified they are to be implementing either.

I'm glad you guys understand it in South Africa, and if I ever wanna open an accounting start-up, I'll be sure to source talent from there, but you lost me:

> Then debit Food Expenses (decrease equity) and credit Cash (decrease assets)

Why are you decreasing the number in two columns?

I don't really need to know personally, but I hope this gives you an idea of what kind of things confuses people.

I don't think the basis of double accounting in the sense that "every thing in and out must end up equalling zero" is super sophisticated concept to grasp, at least superficially.

But once it is applied to situations where things intuitively are just going out of your budget (like buying and eating something: you're left with no money and no banana) and on top of that use counter-intuitive words, I hope you can appreciate that people get confused.

> Why are you decreasing the number in two columns?

It's not two columns, it's both sides of the equation:

Assets = Equity + Liabilities

So if you're decreasing equity, but not gaining any liability, then the only option is to decrease assets to be balanced.

Same here. Even a simple transaction such as recording my salary still leaves me confused.

The beauty of double entry is that if you have one entry you are sure of you can derive the rest. The way I think of it is that a cost is a debit. Everything else can be derived from this.

Buy an apple dr food expense cr bank. Buy an apple on credit dr food expense cr creditors. Pay that creditor dr creditors cr bank

What a good idea to teach it in school.

Disclosure: I'm a trained accountant, but this is just what works from me! Maybe because I started as a cost accountant. Lots of ledger clerks tell me that they start with the axiom that the bank is backwards, so you credit money out.

One other thing that helps some people is the convention of writing debits and credits in a single column, with credits as negative. Then the column must sum to zero. The balance on any account is just its sum. That might really help anyone thinking of storing transactions in a database... and you already know how to run a consistency check since the whole ledger always sums to zero.

It's also taught in quite a few CS/Software Engineering degrees there as well. Granted, not within the context of CS, but taught none the less.

True. Though accounting in general is rocket science. You just need to look at the thickness of the accounting standards book [1]. As soon as you are looking at a large group with several levels of consolidation spanning jurisdictions with different accounting standards and doing any operation that is non trivial, the accounting treatment becomes a minefield. Where I work we have a team dedicated at looking at thorny accounting issues. Outside of that team, I don’t think anyone in the organisation (including the financial reporting dept) can pretend to really understand everything.

[1] http://a1.amlimg.com/ODhlOTU0NjZkODUxYWU1OTAwOWUwYjg3YmM0OGV...

> Rules: Left side of equation: Increase in an asset: debit. Decrease in an asset: credit.

This is the non-intuitive part for me. Everything else seems logical. Why would you debit an asset when it increases?

Because an asset account carries a debit balance.

Debts aren’t good or bad.

Just remember: “debits come in, credits go out”.

From the site:

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

Even bullet 4 has assets and expenses multiplied by -1. Completely .... wrong.

Maybe this might work for a bank where assets and liabilities are sort of flipped from a non-bank business?

I agree. Except I think you're being generous :)

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.

That was the first thing I saw that was wrong.

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.

> I mean, this is just....wrong.

It's beyond wrong. The developer here is redefining established accounting terms because he doesn't like their inconsistencies.

> It's beyond wrong.

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.

Generally Accepted Accounting Principles

> What's wrong with fixing inconsistencies?

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.

Probably not prosecuted though. Probably.

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.

> What's wrong with fixing inconsistencies?

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.

> look at your books

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's a lot wrong with fixing consistencies.

> What's wrong with fixing inconsistencies?

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.

There are no inconsistencies here.

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

> Debits come in and credits go out.

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.

> Just remember that a “debit card” reflects the banks POV

Common usage has turned the terms into something confusing. It's not the accountants fault.

Your credit card is linked to an account in someone else's books. They opened that credit account for you.

If you want to track the bank account on your own books, what they call a debit, you call a credit. Ït’s a mirror image.

Debits come in to an entity, credits go out.

> > Debits come in and 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 checking account is a liability from the bank’s POV.

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.

>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)

Equity accounts are confusing.

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

I mean, it's not hard to remember. They're liability-like. It's just their uses in practice that're confusing.

BTW, nonprofits have Net Assets accounts instead of Equity accounts.

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):

  Assets/Cash $1000
  Assets/Pizza $20
  Liabilities/Accounts Payable $20

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:

  Assets/Cash $1000
  Assets/Pizza $0
  Depreciation/Eaten Pizzas $20
  Liabilities/Accounts Payable $20

(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):

  Assets/Cash $1000
  Assets/Widgets $450
  Assets/Accounts Receivable $50

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.

  Assets/Cash $1050
  Assets/Widgets $450
  Assets/Accounts Receivable $0

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.

  Assets/Cash $1030
  Assets/Pizza $0
  Assets/Widgets $450
  Assets/Accounts Receivable $0
  Depreciation/Eaten Pizzas $20
  Liabilities/Accounts Payable $0

Hope that makes sense. It gets more complicated in real life. Accounting is nontrivial. If there are any accountants in the thread, maybe they can correct any errors I've made.

One minor "error" - depreciation only happens on capital assets, that should be a Pizza Expense.

Yeah, I guess eating pizza usually counts as opex.

But looking down at the balance you may find some of it gets capitalized.

(for these who struggled like me: the weighting balance,not the account balance. Nice one once you get that :)

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:

  |tx id|      account      | debit|credit|
  |  123|Cash (bank 1)      |    25|     0|
  |  123|Cash (bank 2)      |    25|     0|
  |  123|Accounts Receivable|     0|    50|

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!".

It's actually less wrong, but still wrong, to say the exact opposite (i.e., "Debits always increase and Credits always decrease").

In my opinion the core idea is about the data model: Double entry accounting stores movements of money instead of accounts.

Everything else follows from that idea plus a bunch of terminology.

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.

Learning anatomy doesn’t qualify someone as a surgeon.

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.

It's not that hard to qualify, it's the equivalent of three years software engineering experience with some side study.

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 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 mean, this is just....wrong.

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:

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 to know an equality, and ensure that each transaction respects the equality.

The linked form is, in my view, by far the least intuitive, and also re-uses accounting terms with a different meaning. Not only does it not, in my view, help novices understand accounting, but I fear learning it makes it actively harder because you'll need to unlearn it first.

But it does, technically, work.

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.

Hey Snowing, would love to learn more about your experience -- I'm a fellow accountant (BS accounting) looking to move into development.

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.

Best of luck!

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

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.

[0] https://martin.kleppmann.com/2011/03/07/accounting-for-compu...

I had the same idea once, with the same sort of diagrams, except without the colours.

Oooohhhhhhhh.

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.

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.

Interesting. Are there any other fields which desperately need this cross culture?

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.

After 25 years? Was there a full digital title workflow in 1995 or are you referencing a wide adoption of the internet?

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

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

Aside from the obvious PayPal, SQ, and Stripe, would you (and other folks) please share some companies one should look into?

I would look at finance companies and banks directly.

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.

The aggregators. Yodlee, Plaid, MX, etc.

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.

We're hiring at Remitly :)

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.

That is great to hear! Would there be any particular tools or stacks to focus on? You mentioned tokenization -- is that related to blockchain?

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

I would love to make use of my strong cross-disciplinary skills like this, but I see no evidence that this is actually true.

The debit and credit statement is incorrect. It depends on if it's an Asset, Liability, Equity Revenue or Expense.

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.

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.

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

...but sometimes things aren't inflows or outflows. Depreciation is neither, yet it's (almost) fundamental to accounting.

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 rest my case.

You often end up with three accounts. Asset (balance sheet), accumulated depreciation (balance sheet), and the depreciation expense account (P&L).

In which case the depreciation is cr. acc. depreciation and dr. depreciation expense.

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.

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/

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.

Ledger is almost great software, except that it uses signed numbers. Why?!

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.

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

Can you elaborate more on your invention, and how matrix maths work with that equation?

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

And then, you can have:

  <BAL|T|FSV> = 0

It is easy to see that this equation is valid.

Do you have a more complete write up of matrix accounting anywhere?

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

Compare to https://arxiv.org/abs/1407.1898

I have not seen that; thank you for this information.

I couldn't understand double entry accounting until I found out about ledger-cli / hledger.

These awful arbitrary "left-side / right-side" and "debit / credit" just doesn't make any sense.

As opposed to that, no-magic approach from ledger-cli where every entry must balance is intuitive to learn and mathematically correct. And it allows to go a bit beyond the whole "assets / liabilities / expenses / income" if needed.

Ledger CLI is wonderful. I've been using it for over a year for budgeting (via envelope-style virtual accounts) and keeping track of my family expenses.

The biggest advantage is that it's just a plain text. I can read it, I can store it in git, I can backup it. If I make an error, it's easy to fix with text editor I'm familiar with. In the beginning I changed my accounts naming scheme several times and it was super quick and easy with simple sed. Previously I used GNU Cash, which is another double-entry accounting program, and doing any bulk edits was a serious pain.

The straightforward approach of ledger-cli also means you don't run into arbitrary limits any time soon.

I started using ledger-cli when I started a new business a decade ago, and it's still being used today with employees and representatives in a dozen countries and sales in several different currencies. The only problem is interacting with outside accountants who will never have heard of it.

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.

>accountants don’t like negative numbers.

That’s the first I hear of that

> >accountants don’t like negative numbers.

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

> 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) !

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:

CR 'Assets - Accounts Receivable' / DR 'Cash'

CR 'Assets - Accounts Payable' / DR 'Expenses'

CR 'Revenue' / DR 'Assets - Accounts Receivable'

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.

[1] https://martin.kleppmann.com/2011/03/07/accounting-for-compu...

[2] https://news.ycombinator.com/item?id=2298471

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.

Below are some really great free video courses to learn accounting fundamentals from Johnson County Community College.

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

That's the silly, confusing view of accounting.

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.

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

#4 is correct.

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.

If the only thing required to untwist the system is to switch the sign of everything on the liabilities side maybe it wasn’t so twisted after all.

At least you have the good taste of keeping assets positive, unlike other people. :-)

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

But it's not really the same thing.

> you may need to create some kind of income account for that gain

Right; and that's exactly what I describe in the last paragraph.

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.

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.

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

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

That sounds less hilarious, and more extremely useful free info and software.

Others has mentioned text based double entry accounting tools like ledger and hledger. There are other tools e.g. my favorite beancount.

https://plaintextaccounting.org/ is a site listing all of these text based accounting tools out there.

Modeling the problem for devs is actually not the hard part, the math is somewhat simple for the accounting part (time value of money gets more fun, but I digress). The hard part for me still is undoing years of language baggage associated with words like Debit and Credit, which Increase and Decrease things that are treated as negative or positive depending on pov. In almost every case, I interpret the meaning wrong, and have to reparse.

Look at this sentence from another comment: "If your banana is for consumption and you pay cash: Then debit Food Expenses (decrease equity) and credit Cash (decrease assets)."

It flies in the face of our habitual, naive, and common use: "I'm crediting cash? But I spent it! Shouldn't I debit cash, debit is lowering? No? But if I have credit, I have more! No? Is that Comparative Literature class still available to switch into? No?"

The categorization are not always based on logic that is commonplace, and has legacy trappings. The terminology is different from what a naive reader might expect.

To be fair, many sciences have evolved this way. But like the French phrase "false friends", words that sound like one thing in another language but have a total different meaning in their own tongue, I think the struggle is to adjust mindset to the new meanings of words we use frequently, more so than the concepts of balance and systems of equations.

There is a great podcast about how double entry accounting was a foundational invention of our modern society.[0]

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

Lately a lot of "Hello World"s has been replaced with "To Do List" examples.

Maybe we should start using "Debit/Credit Journal" instead.

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.

I'll link to this thread from that page.

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.

If anyone's interested, here's my (ledger-cli inspired) double entry accounting CLI application in C#: http://github.com/soheilpro/Ledger

It has two interesting features:

1. Supports multiple currencies

2. Has a query language that lets you easily get various reports

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

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

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.

This is how ledger-cli works.

I haven't used ledger, but it seems to be double entry accounting too. According to the example:

    2015/10/12 Exxon
        Expenses:Auto:Gas         $10.00
        Liabilities:MasterCard   $-10.00

whereas I would have something like:

    2015/10/12   Exxon  $10.00  MasterCard  ->  Gas

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:

  cr. revenues                $800
  cr. VAT patable             $200
  dr. accounts receivable    $1000

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.

Accountant here. This article is just wrong. You could memorize debit/credit rules but when dealing with non-finance persons, I avoid mentioning debit/credit as it gets confusing and generally its not needed anyway. Here's how I would explain basic accounting (income statement is ignored for simplicity).

Every transaction has two legs: what it is and whose it is. That is the basis of the accounting equation: assets (what) = equity (mine) + liabilities (someone else's). An increase in assets must be balanced with an increase in either equity or liabilities, and vice versa.

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.

https://github.com/200ok-ch/easy

Huh, you used `clojure.spec` but then used YAML. I get it for the UX reasons, but I would have guessed you'd be generating edn under the hood.

I suspect that some of the language of credit and debit is so old that it was created before postive and negative integers were widely accepted

I think the most important equation to understand about accounting is assets = liabilities + equity

ROA, ROE, etc come from the above formula.

more basic:

  Assets = Net Equities

In other words, "all the assets are claimed". Owners equity is the the balance of the assets once other claims are discharged.

Maybe you mean Equity = Net Assets ?

That would make some sense.

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.

IMH(and not accountancy)O

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!

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)

Equity is similar to a liability. Ít is owed to the owners of the entity.

Making assets positive in code is conventional.

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

Signed values are the way to go!

> 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!

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.

> Money in your bank account is _negative_.

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.

In a conventional double accounting system:

  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.

I have no problem with negative numbers.

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.

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!

Thanks for carrying on the chat.

> It stored debit as negative numbers.

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.

> Did it displayed assets

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?

For the record, this is what the consolidated balance sheet looks like: https://imgur.com/a/i8q0Fa2

Neat. Thank you. I get what you're saying now.

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.

Assets + Liabilities + Equity = 0 is incorrect.

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.

A=L+E

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.

Think of it this way: Assets - Liabilities = Equity

If we deduct everything that we owe (Liabilities) from everything that we own (Assets), whatever is left belongs to the shareholders (Equity).

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.

> assets + liabilities + equity = 0

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?

Transaction:

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.

I don't understand where the negative comes from. I just gained $200. Why would my bank balance go down by $200?!

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.

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

So I am not reinventing anything.

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.

Yeah I almost mentioned multiparty transactions too, but thought I'd keep it simple since I got the crux of it :) thanks!

That's easy. The $200 would be income (that had no associated expense!)

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

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.

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.

Reply on news.ycombinator.com