back
101 comments
I’ve read that the development of double entry book keeping was very important, enabling less error in accounting, then driving significant gains in commerce. But reading this didn’t explain exactly why. Is it just the simple sum rule that ensured errors in transcription would (usually) quickly be caught? I’d guess automated accounting services today would be less prone to such errors — does that mean double entry is no longer as important as it once was?
In addition to error checking, the process of double-entry bookkeeping also provides a way to get different views into the state of a business: balance sheets, P&L statements, transaction histories, and so on. A lot of the mechanics of doing it manually—journals, ledgers, day books, trial balances, etc.—are less important now that computers can slice-and-dice at the push of a button, but the fundamental idea of a business transaction as a set of balanced money movements between different accounts is still a useful way to structure financial data.

(“Double entry” is also something of a misnomer; it’s really “N-entry” accounting, where all N entries that make up a transaction have to balance out to make sure you know where the money came from and where it went to. It’s just that for simple transactions the minimum number of entries that makes sense is 2.)

> “N-entry” accounting

it's called double entry bookkeeping because each value (each number) gets entered in two places, once as a debit, and once as a credit.

This is indeed the right answer. I sometimes try to use simpler accounting mechanics than double entry (usually because the person I'm doing it for requests it) but it doesn't take long until I want to run a query against the data that becomes complicated under simpler systems but just falls out of the data under double entry.
Yes! I was both tech lead and EM on a multi billion dollar double entry accounting system for years. It was completely unnecessary and overall a drag to keep the double entry system. You end up inventing a ton of random accounting procedure to account for the “other side” of transactions that just don’t need another side. You invent accounts that do nothing and mean nothing just for scorekeeping. If you trust computers to do basic arithmetic and if you trust ACID databases, double entry accounting is outdated and unnecessary.
I'm not an accounting expert by any means but I've been around long enough to see far too many examples of single entry accounting systems that have gone completely off the rails and nobody knows why because meaningful data (i.e. "$M moved from X to Y on date Z by process P") is not captured and difficult or impossible to recreate.

Sure, computers can do basic math and ACID usually works out but that doesn't account for human-level errors. Subtle things like getting an idempotence check wrong can lead to cascading errors that are really hard to see and fix when you just have one view into the numbers.

Double entry forces you to account for both sides of the transaction. Where did the money for groceries come from? Checking account. What the hell is this $200k spend? Office equipment. That money from Bob, was that a gift (income) or a loan (liability)?

So why not model exactly those account transfers? Because it's not always that simple. How do you translate this?

    CREDIT $ 1.10 Expenses: Coffee
    CREDIT $8.80 Assets: Gift Card
    DEBIT $10.00 Assets: Checking
You could say Checking -> Gift Card -> Coffee, or Checking -> {Gift Card, Coffee}. Does it actually matter? Probably not, so that's a pointless choice leading to false precision. If you did need to specify which one it was you'd put them in separate transactions (and you'd probably structure the actual spends from the assets accordingly).

Maybe contra accounts are an outdated concept. Ok, don't use them and directly reduce the balance of the account. You also don't need a separate account for every little thing, we certainly had misc accounts in every day of books I've seen. But you at least have to be able to say whether something is income, expense, asset, liability.

Can you tell me an example of an "other side" that isn't useful for any reason?

Edit: I'm an accountant and I can't think of an "other side" that isn't useful, hence my question

Double entry accounting as a representation is a domain specific language for the people working in the field and as such is very useful.

However, you might ask, is it also the right primitives to express accounting IT systems or could we think of a better domain model, and then derive the double entry ledgers from that?

This is an important and profound question.

If you would like to dive in, I suggest looking at the REA (resources, events, agents) model, a set of abstractions and patterns for expressing accounting in business systems.

The Model-Driven Design Using Business Patterns book by Hruby et al. is a great starting point. [1][2]

Also, the POETS (Process-Oriented Event-driven Transaction System) research from DIKU (Copenhagen University) is super interesting, offering some ideas for next-generation ERP systems.[3]

[1] https://link.springer.com/book/10.1007/3-540-30327-2

[2] http://phruby.com/book/index.html

[3] Fritz Henglein, Ken Friis Larsen, Jakob Grue Simonsen, Christian Stefansen. POETS: Process-Oriented Event-driven Transaction System. Journal of Logic and Algebraic Programming (JLAP), Invited submission to special Issue on Contract-Oriented Software, 78(5):381-401, 2009.

Jesper Andersen, Ebbe Elsborg, Fritz Henglein, Jakob Grue Simonsen, Christian Stefansen. Compositional specification of commercial contracts. International Journal on Software Tools for Technology Transfer (STTT), 8(6):485-516, November 2006.

There are more papers from DIKU on this, see e.g. prof. Henglein’s publication list :

http://hjemmesider.diku.dk/~henglein/bib/author/Fritz.Hengle...

I don't understand why a 'tech lead' would have to invent an accounting procedure. Accounting procedures are the responsibility of accountants, not of engineers who lack basic training in accounting.
What's a good daily accounting system then?

Would just a excel spreadsheet be good enough or a legit accounting software?

You end up inventing a ton of random accounting procedure to account for the “other side” of transactions that just don’t need another side

If you aren’t talking about turnover-only sub accounts, I’d like to learn some good examples of it.

Can you be more specific? I'v been working with accounting systems for some time also and there are no transactions in double entry accounting which "just don't need the other side".
You could also have a db view that returns a virtual double entry version, as a test that it passes muster with that. This checks for programmatic errors causing money to appear or disappear.
"does that mean double entry is no longer as important as it once was?"

What are the alternatives? Sure, you could do single entry accounting (making an entry corresponding to each cash movement, but then you'd need a separate system to keep track of

- money the business owes

- money the business is owed

- inventory

- other assets

I don't know much of the history, but I can say:

- I've found it helpful to compare to look at the income statement alongside the opening and closing balance sheets. I've even found errors this way.

- AFAIK all business accounting systems are based on double-entry accounting, so the existence of these systems can't obviate the need for double-entry accounting.

If you have a cash business where you hold almost no inventory, e.g. if you're a baker who buys flour at the beginning of each day, and close your shop when you've sold out of bread, you might not care about tracking assets, accounts payable etc.

I think the biggest and also least attributable benefit of it was it enabled the Venicians of Venice (iirc?) to create money, outside of what hard currency allowed at a time and with it opened the world of financing.

By create money I mean the same way your bank today creates money anytime it finds a willing and credit worthy borrower.

Double entry book keeping basically invented the concept of ledger money which is pretty much the “money” we use today. It enabled elasticity of the money supply where elasticity was lacking.

The importance is in the "accountability" of accounting. By forcing each entry to cross accounts, you make each account reconcilable with the others. "Books" are no longer independent because they can be cross-checked. Where books are departments that makes departments responsible for justifying each entry in a way that is visible across accounts, to the cent. It's a validation layer. With double entry you can't cook just one book, you have to cook all the books.
you get different amounts of money coming in at different times (investors, loans, revenue from sales) and you have different amounts of money flowing out at different times (paying workers, paying for supplies, equipment...)

double entry bookkeeping not only "checksums" these quantities for errors, but also gives you different snapshots of your business, how much money do you owe in the short term, how much in the long term, on average what's the profit margin, how much tax do you owe this year.

other people can also look at your accounts and check up on random sample pieces of information to ensure it's not all made up.

It creates a clear picture where the raw data is somewhat murky, which enhances trust on many levels.

I think there is more to it than meets the eye perhaps.

It is the way to understand human activity as a set of transfers beween accounts. All the money must go somewhere, perhaps spent perhaps saved in a different currency. All these different types of transactions including startup of the business that occur within can all be modeled with the "simple" concept of 2-entry system. It is a general way to track human co-operation numerically.

The kind of errors that double-entry accounting prevents aren't just arithmetic errors, but also conceptual errors. Double-entry accounting ensures that the accounting identity, which states that Assets = Liabilities + Equity, is true at all times, and it does that by requiring that all individual transactions are balanced.
It allowed people to be quantified with a single number, 'he owes X amount of dollars', 'he has X amount of dollars'.

During the dark ages, and early middle ages, people didn't have much money. Instead there were complex relationships based on obligations 'loans', IOUs, real estate transactions to hide usury, dozens of different currencies with different exchange rates. Determining wealth was a complex affair.

On a completely different tangent, Leonardo da Vinci probably illustrated the first book about double entry book keeping. He was interested in math and knew the author, most likely traded his artistic skills for math lessons.

In terms of error detection, one of the principal tools in double entry is the Trial Balance. A trial balance lists all of your accounts in your ledger, with debits and credits in opposing columns, sums them all, and the two columns totals should match. If they do then all entries are at least complete. If they don't then you have lost records along the way. By correctly assigning debit or credit normal to each account type you ensure there is always a credit for every debit and vice versa.
I wrote a simple double entry bookkeeping program for myself, and I wanted to use as accurate terminology as possible. My native language is Swedish, and we have a word for the task of categorizing statements into accounts. Basically, when you look at a recipt and tell "this is for inventory, then I will use account X." In the past, you then wrote that down with a pen in a kind of inverted-T table that you had stamped on the receipt. The Swedish word for that activity is "kontera", loosely translated to "accounting". But in English that is the word for the entire activity of keeping books up to date. Is there a word for the specialized task of identifying the accounts?

Edit: Wikipedia has articles for this word in Swedish, Danish and German. But no other languages. Puzzling.

Can sometimes be "post" transaction, and sometimes "book".

It's kontieren in German, and probably from latin "conto".

Classify I think
Doible entry system is useful and reliable when you mainatain system for large business. If you have 100s of vendors and need to track balance between these vendors, then double entry system helps you to keep your account in check. The basic rule of having sum of different amounts in a transaction should be zero is simple and powerful in resolving conflicts.
It's also useful in the smallest of businesses. It allows for a more mature thinking about your finances and how to leverage them beyond cash=profit. It's very difficult to scale beyond a micro entity with single entry bookkeeping, for example you cannot produce a balance sheet with single entry.
Double entry accounting is useful any time you have limited amounts of a resource and want insight into how it is used. You don't need to apply it as strictly as accountants do -- very general categories and a random sample of transactions is fine for most types of analysis.

The important part is that every unit of resource comes from somewhere and goes to somewhere. As long as you fulfill that property, you get powerful querying capabilities.

Most recently I've used it to compare various means of acquiring more RAM for an operation (cloud offerings, incremental purchase, leasing large amounts, etc). One of the other benefits is that I can mix both "terabytes of memory" and "thousands of euros" in the same book, and exchange rates between the two also fall out of the equations.

I want to love the plain text accounting tools. I used them for over a year on all my finances. They’re incredibly expressive and exact, and they play well with vim and git.

The trouble is ingesting transactions. You do your best—save receipts, try to note things in your phone. Then some auto-pay thing blindsides you. Or, that separate tip charge from Uber Eats. Yes, you can capture all of these things, but it will require hours of weekly time investment to counteract financial entropy.

I ended up just buying Banktivity. I do miss the perfection offered by plain text accounting. I miss nothing now because they’ve contracted with teams that write scrapers and API clients for banks I would have otherwise had to write myself. Reconciliation is now the work of minutes. It’s not perfect, but everything is a tradeoff.

I find there's a balance to be struck between convenience and granularity. If I insisted on categorising every transaction into very specific categories it would be far too much of a pain for me. So, for example, I have a big expense account called "Eating and Drinking Out". Ideally it would be great if I knew specifically what I was spending on coffee, on lunch, on beer, etc, but it would just be too much work. Likewise, I don't track my cash - I just have an expense account called "Cash Withdrawals" (unless I am withdrawing a large amount of money for a specific purpose, which I usually remember so am able to allocate it to a more specific account).

In the normal course I try to update my GnuCash once a week, which takes about half an hour on a Sunday. However I've been quite bad lately and today I'll be trying to input over a month of transactions which I'm not looking forward to...

I feel this pain every time I go to reconcile transactions for the week/month. At the same time, I'm not ready to trade the exposure I get to every penny of my income/expenses that manually typing entries gives me. It's just not the same as reviewing a ledger - the act of typing, reviewing, and reconciling has really boosted my confidence in how I currently manage my finances.
I used ledger for 2019–2020 and by the end of it I had scripts to pull just about everything automatically, whether via OFX, Plaid, CSV, or PDF. It became a drag when I realized that I’m starting a new job, I’m opening new accounts, &c., and all my tooling would have to be constantly changing.

Now two years later I’m porting my details into Beancount (the tool whose documentation is linked), and I’ve changed my approach to one that seems much more sustainable: once a month, download statements and enter them in with some templates to assist. Maybe I use a CSV parser for credit cards and other high-frequency accounts, but for what I want out of plaintext accounting, I don’t need hours of weekly time to keep decent finances, but perhaps an evening a month.

If you don’t mind me asking, what’s your use case or motivation for having sub-weekly updates to your financial picture?

Developers understanding double entry well is critical to avoid what I call "programmers reinvent accounting principles". I stumble across this all the time as a major blocker trying to tightly integrate modern SaaS in to enterprise IT stacks.
> Moreover, posting a positive amount on an account is called “crediting” and removing from an account is called “debiting.”

I think they confused debit/credit here.

Ledgers are typically debit-normal from the perspective of the asset-holder. As a bank, your asset is my liability and vice versa, i.e. your mortgage (liability) is my asset (receivable), so it can make sense to model movement of funds as credit-normal to ease the construction of financial statements from the perspective of the bank.

By convention:

- Asset & Equity accounts are increased by Debits, decreased by Credits.

- Liabilities, Expenses & Income are increased by Credits, decreased by Debits.

Whichever convention you choose, consider that an Asset account like cash (Current Account) has to be funded from somewhere: either from a Owner Equity (investment in the business) or a Liability like a loan, so funds will flow from Equity -> Cash, i.e. credit Equity & debit Cash. To repay the loan, the flow is reversed: Cash -> Loan, i.e. credit Cash & debit Loan.

Thus holds the accounting equation that:

    Assets = Liabilities + Equity
(I build double-entry accounting ledgers for a living.)
They haven't; you have.
One interesting challenge I've been hearing a lot lately in accounting tech is that some accounts become a hotspot and slow down overall transactions. For example, you might take a commission on all transactions and you track that commission in a company-related account.

I'm curious how folks using a generic SQL or document database solve this.

In your example, setup a per-department commission account for general use then move those balances to the company wide account periodically.
Sharting.

edit: Wrong thread, sharding.

What's the best tool to get started keeping track of our finances using double entry accounting?

Ideally, I'd love a tool that lets me import data from my credit card and/or bank accounts through something like Plaid rather than having to manually enter every transaction I make.

Beancount, software written by the author of the parent piece, is a terrific "plain text" double entry accounting system. I've used it for more than a decade on both personal finances and non-profit treasury projects. It was many tools in its ecosystem for reformatting (single entry) transactions into double entry.
GnuCash is a decent tool. I use it for my simple personal finances and it's good enough. I don't know if its import/export will suit your needs, but I think it's worth a try.
Xero is pretty widely recognised as the simplest gateway for small businesses to double entry bookkeeping these days.
Quickbooks does this. But I Hate quickbooks, I just don't know anything better.
since computers are reliable, isnt a modern accountant just a tax code knower?
I'm an accountant, I run a finance team at an sme. I don't know much about tax at all. I certainly don't know 'tax code(s)' My accounts are fairly large, span 4 companies and several companies. My primary role is to keep the company solvant, and score keep for the shareholders and management team. My tax reporting is infrequent, outsourced to specialists, and not my primary concern. I look at the cash flow forecast every day. I look at tax once a year.
This massively diminishes the value of the decision making process of the accountant and bookkeeper.

I'm not aware of any SMB finance software that will, for example:

- Know whether to post a transaction as COGS, OpEx, or CapEx.

- Be able to decide if a transaction should be journals across a 24 month period or taken in a single hit.

- Judge the length of depreciation for a particular piece of plant

- Attribute unclear bank receipts to due invoices for reconciliation.

That's just a handful of examples. The software ENABLES the finance team to make their decisions and provides them intelligence, but they still do a huge amount of the decision making. The decisions bookkeepers and accountants are taken are largely individual business specific, and based on the accounting principles of that business.

Frankly if the decisions are taken well and the software is good, then the tax element can become one of the easiest components where the computer CAN just get on with it, along with the tax specialists

I think there’s some truth to this but there’s also the need to set up books well and to implement important practices like reconciliation. For example the way accounts are grouped together can be important, eg to be able to see COGS and EBITDA.

Mostly what I see is that an in house accountant does the books and an external accountant does the tax. But that might not be the case in all jurisdictions.

All of that said, I’ve seen a lot of P&Ls and balance sheets over the years and most of them are so overcomplicated that it’s difficult to understand the business fundamentals. I’m not sure if that’s because accountants make things complicated, but I suspect it’s because accountants aren’t asked to be involved when they should be.

Its all about the ying-yang