
Double Entry Accounting for Developers - adamcharnock
https://django-hordak.readthedocs.io/en/latest/accounting-for-developers.html
======
dragonsh
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...](https://beancount.github.io/docs/the_double_entry_counting_method.html)

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

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

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

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

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

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

~~~
inopinatus
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_.

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

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

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

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

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

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

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

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

------
mtlynch
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...](https://martin.kleppmann.com/2011/03/07/accounting-for-computer-
scientists.html)

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

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

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

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

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

~~~
nsl73
I would look at finance companies and banks directly.

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

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

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

~~~
mumblemumble
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?"

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

~~~
mumblemumble
I rest my case.

------
war1025
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/](https://www.ledger-cli.org/)

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

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

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

~~~
juped
Compare to [https://arxiv.org/abs/1407.1898](https://arxiv.org/abs/1407.1898)

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

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

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

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

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

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

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

------
rahimnathwani
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'

------
tzs
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...](https://martin.kleppmann.com/2011/03/07/accounting-for-computer-
scientists.html)

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

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

------
ron22
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...](https://www.youtube.com/watch?v=ZkZ6Q67Q15E&list=PL259DBFA47F3B4761)

intro to managerial accounting

[https://www.youtube.com/watch?v=2cC9SZ3RC8Y&list=PLHhe-2tIHR...](https://www.youtube.com/watch?v=2cC9SZ3RC8Y&list=PLHhe-2tIHRqEw5JRX6trtsLLlwwbpdXJX)

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

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

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

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

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

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

------
CobrastanJorji
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...](https://www.gnucash.org/docs/v4/C/gnucash-guide/basics-
accounting1.html)

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

------
yegle
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/](https://plaintextaccounting.org/) is a site
listing all of these text based accounting tools out there.

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

------
jedberg
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](https://www.bbc.co.uk/programmes/w3csv3gq)

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

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

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

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

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

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

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

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

~~~
kgwgk
> 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](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."

------
soheilpro
If anyone's interested, here's my (ledger-cli inspired) double entry
accounting CLI application in C#:
[http://github.com/soheilpro/Ledger](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

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

------
preek
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](https://github.com/200ok-ch/easy)

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

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

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

ROA, ROE, etc come from the above formula.

~~~
sago
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

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

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

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

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

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

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

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

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

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

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

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

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

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

