The Double Entry Counting Method (2016)
beancount.github.io
beancount.github.io
Electronic books that don’t balance to the cent are defective.
I’ve certainly seen lax accounting and reconciliation practices in businesses such as those you describe but it’s absolutely not been the norm in my experience.
Individual books, yes (though I am still very dubious of the value in doing this given the guarantees that modern computers/databases offer). I'm talking specifically about cross-department reconciliation where different departments are keeping their own books and have their own data pipelines/etc. They absolutely still have to be reconciled, but there is no expectation of an exact match from the SEC or internal/external auditors.
I have a remote shop that takes cash and credit card payments. If i just ran a cash book like some on here are suggesting how would I know my sales for a day? I could wait until the money hits my bank account and categorise it, but then how much of that money is sales tax not sales? How much did the goods they sold cost me? Did they put all of the cash in the bank or did they steal some. Did the credit card merchant pay me everything due?
Imagine the customers have credit terms with you? Now when do you know your sales, when they pay? What if they don't pay?
Double entry has answers to all of those questions.
(“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.)
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.
1. Credit $1000 Cash account,
2. Debit $600 Personal Rent account and
3. Debit £400 Office Rent account, considered a tax-deductible Expense account.
Sum of credits = Sum of debits, but now you can account for different tax treatments.
The fact that you have an equal amounts of entries in debit and credit accounts is literally the point of double entry bookkeeping. If you could use consolidated entry, it would be a nightmare to cross check when you are looking for errors. If you were using a ledger rather than a piece of software, it would be so much more obvious.
In the example of $1000 paid in rent, the technically correct method is actually worse for usability. If $1000 left the bank account and two transactions totalling $1000 were recording, how can you match the ledger to the bank account? Or if there are bank charges paid on a transaction (Paid $1000 with $5 in bank charges).
The ledger already matches the bank account. You have 1000$ leaving it in two lines. Charges will likely be accounted separately anyway if they exist.
You probably mean the bank statement. If that’s the case, the answer is you do what is called reconciliation and sum the accounting entries. Reconciliation will be more complicated anyway because you will have entries in your accounting for a month which might be on a different bank statement entirely due to outstanding checks and deposits and bank processing delays.
I'm aware of how reconciliation works. I'm actually an accountant by trade. $1000 is a trivial transaction of course, but reconciliation becomes challenging when its thousands of transactions per month of differing amounts. If anything, transactions not matching the bank statement is a good way of increasing your audit fees as the auditor struggles to make sense of what your accounting system has recorded.
here's a simple case you may have encountered yourself: you order a shopping cart of a fair amount of stuff (not even that much) from Amazon, and click purchase. Later you're wondering about an Amazon charge on your credit card so you look in your emails from Amazon and you log into your account on Amazon, and you can't match the charges on your card with any of your shopping transactions with Amazon, the numbers bear no resemblance to one another. Amazon is not bookkeeping in a way that's at all useful to you. Since you are the consumer of the data, they're not fulfilling their accounting obligation which is clear presentation of the record.
I have no doubt that their calculations are correct, but just as computers can free us from the burden of adding up numbers correctly, computers can also do other tasks we find burdensome, like double entry bookkeeping. When as a programmer I used to resist writing code that seemed inelegant, my old boss used to remind me that the computer was the drudge, a mere servant to the whims of the various humans using it. If Amazon wants to rejigger your shopping carts with respect to backorders and shipping, they could easily do it in a way that allowed you to reconcile your statements simply.
Example: I buy something with my salary. Two real transactions. However, on the books it goes in as income, it is moved to the household income, it goes into the cash reserve, then moves through the appropriate budget category before the actual expenditure is recorded as it happens.
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.
That is not really what the accounting standards are for. The people that need to be kept happy are the users of the accounts. The standards are there to stop me misleading, or defrauding them.
Here is a list of some users of my accounts:
Managers: need to know how their business unit is performing so they can take action
Shareholders: need to know how the directors are managing their money
Banks: I borrow money from them, and they want to see that I can pay it back
Tax authorities: I collect sales tax for them. I collect payroll taxes for them. I have to pay taxes on my profit
Creditors: I need suppliers to advance me credit. They need to work out the risk of giving it to me.
Employees: before I joined the company I wanted to know it was solvent
Imagine how I could manipulate them if there wasn't a standard way of communicating the accounts.
Simple example
I need to know my profit this month. I have added up my cashbook for the month and it contains an entry for 3 months of rent in advance for my office. It is September and that is the rent for October, November, December. How do I get it out of my profit calculation for September and split into the correct months? This is important, my bonus is based on profit. My bank loan covenants are based on profit. My equity split with my investors is too, as is my tax payable. In double entry I would move this into my prepayments account and move it back in 3 tranches.
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.
Would just a excel spreadsheet be good enough or a legit accounting software?
I couldn't fit all of the transactions in a given month into Excel for my business. There are more than 1m rows. We are only an SME.
In many EU countries, if your turnover (total amount of money flowing through your business) is over a certain amount, or if you are incorporated (rather than sole proprietor) you have a legal requirement for double-entry accounting, and in some places a legal requirement to have an external firm do your accounting.
Excel and single-entry in general allows one to ignore questions about their financial structure, make decisions that lead to massive analytic information losses and bury a relatively good business in a deep grave of multiple “idk” levels of knowledge. They only become aware of it when it stops scaling (but competition does, for some reason) or a market goes down for a while (but competition doesn’t care, for some reason). Digging them out is a hard and tearful task.
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.
Edit: I'm an accountant and I can't think of an "other side" that isn't useful, hence my question
I'm considering "external entities" here to mean accounts that aren't yours. A bank account or a credit card or a mortgage are yours, in the sense that it matters to you in some way what their balances are. Most expenses (by number of transactions, maybe not by total amount) are not that.
To offer a concrete example, I pay my ISP about $80 per month for an internet connection. Double entry accounting would have me move money into an "account" representing my ISP, so I can answer the question of how much money I've paid them over the whole time I've used them. That isn't a question I have ever needed to ask, nor do I expect to, but if I do, it would be answerable with a single query over a single-entry transaction list. Until then, the extra effort spent on double-entry accounting would be entirely wasted.
edit: I missed the context that the person you replied to was working on a very business-sounding accounting thing. I'll leave this here in case it inspires more relevant examples.
However, I have often found that when I do that, inevitably someone asks, "so how much of our expenditures this year were for the internet connection?" and then it would have been really useful to have that ISP account.
But if you don't need it, don't have it.
You get to keep track of what matters to you and what doesn't, you can dump into Expenses:Misc
[1] others would, and so would have separate accounts for specific restaurants
How would you pick out just the transactions that were to your ISP? Unless you want to manually review the transaction log, you need something consistent you can refer to in your query: like an account name (or a transaction description, but that feels easier to accidentally be inconsistent with).
My ISP has a consistent name over time, and my bank already stores and displays that on each transaction with no effort on my part.
Well, no, unless you account your ISP as some important contractor or a cofounder and have interest rates etc with them.
If it is just a simple expense, you do the following:
debit: expenses / basic needs
credit: bank / account
sum: $80
debit: My stuff / tv
credit: Bank / account
sum: $1000
debit: Expenses / Breakage
credit: My stuff / tv
sum: <a remaining cost of
tv, depending on
amortization scheme>
edit: I read what you're describing here as a single entry system if you just read "expense account" as "expense type"; double entry would be if you physically recorded each of those in two places. It's entirely possible we're arguing about semantics.
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
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.
for the readers, contra accounts keep track of expected adjustments, particularly "opposites", So when you sell items you also expect a percentage to be returned later by dissatisfied customers. If you book all sales revenues as they occur, that will show an "untrue" number, so you book expected returns into a contra account so you can see what your actual revenues are expected to be. Then later when you have accurate information on returns you use those values to unwind the expected values you put in.
Accounting is all about providing accurate information to various "stakeholders" who might be looking at the books.
These are also examples of cash basis accounting which is much simpler. When you get into accrual basis and revenue recognition especially is where the double entry stuff (IMO) just starts to break down. Meaningless accounts get invented just for the sake of having something to balance against, and your entries are no longer tied to actual money changing hands.
If you aren’t talking about turnover-only sub accounts, I’d like to learn some good examples of it.
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...
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.
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.
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.
Edit: Wikipedia has articles for this word in Swedish, Danish and German. But no other languages. Puzzling.
Yes, "book" is the right translation. Though "book" can mean many other things in English.
To book a transaction means "to enter the transaction in the bookkeeping system", hopefully in the right account.
It's kontieren in German, and probably from latin "conto".
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.
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.
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...
(Though it's important that it's either a systematic sample (every n days) or a random one (throw a dice each day, if it's 5 or higher, record that day). The days you pick have to be uncorrelated with the types of expenses those days, or your results will be biased.)
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?
I think they confused debit/credit here.
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
Assets:Cash -1 USD Expenses:Food
For example, if you are a bank and I am your customer, then when I spend some of my money to buy your products, my Expense is your Income. My cash asset is your liability.
At scale, it can be convenient to construct statements for both parties by regarding the same entries as credit-normal. Alternatively you have to mirror all entries in a 99%-similar ledger, but reversed.
Does it matter who holds an asset when determining whether to debit or credit an expense? I would think the question is who is making the expense, not who holds an asset, which may or may not be used to pay the expense.
In any case, unless you are talking from multiple perspectives, which would be unnecessarily confusing, expenses and income have opposite signs.
I'm curious how folks using a generic SQL or document database solve this.
edit: Wrong thread, sharding.
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.
I've been using QB both personally and professionally for over 15 years, it has just about every feature a small to medium sized business could want, and it's a default in the sense that you can go to just about any tax professional who prepares business tax returns and they will have no problem using your QB data, often by working with a copy of your actual company file, and providing year-end journal entries for you to reflect various tax adjustments.
The current problem is that Intuit is forcing everyone to subscription-only, even for the desktop product, and they've nearly doubled the annual license fee, mostly to try to force people to QB Online.
I do think Xero tends to overprioritize acquisition at the expense of providing a complete product to its users. Too many times, I have found some quirk or half-assed feature that Xero refuses to fix. That said, I have no doubt Intuit is worse at this.
If Your needs are simple, Xero works. But the moment you reach even slightly less than simple, you're going to need to work around quirks very quickly.
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.
That sounds unusual to me but I’m European. My parents own a moderately sized SME which involves multiple branches and a holding. While monitoring cash flow and dealing with invoices and payables take the lion share of their accounting, taxes related activities still take a significant amount of times.
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