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?
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.
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.
None of this is mutually exclusive to a single entry system. Tracking where money is coming and going can be done any number of ways that is not double entry bookkeeping.
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.
I would argue that, categorically, tracking the balances of external entities isn't useful or meaningful, at least for personal finance. (I don't know enough about business finance to form an opinion.)
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.
Double entry accounting doesn't require you to track expenses related to your ISP. All it requires is an expense account. Whether you decide to open sub-accounts in order to track some expenses specifically, it's entirely up to you.
This way you can see your expenses on an “expenses” account regardless of where they came from. No need to scan for multiple sources, because they all end up on a single account. This is a beauty of accounting, you define not how, but what. You bought a tv?
debit: My stuff / tv
credit: Bank / account
sum: $1000
Your tv broke?
debit: Expenses / Breakage
credit: My stuff / tv
sum: <a remaining cost of
tv, depending on
amortization scheme>
With single entry you either cannot do that, or have to scan all tables and invent a special field that represents type of an operation, in this case isExpense or shard tables by that criterion.
This requires you to know up front which expenses you want to track, though. If you don't, and you change your mind later, you get to do that table scan anyway, so you may as well actually record the metadata that makes it possible.
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.
I don't care how much I'm spending at a particular restaurant[1], but I do care about how much I'm spending on food I cook myself vs eating out/ordering in so I've got Expenses:Groceries and Expenses:Eating Out. And sometimes batteries make it into my grocery bill because I was there and you know what, it's really not an issue for me.
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
> 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.
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).
Technically you could bunch up all payments to service providers under a "services" account, or just a "household expenses" account, or even a general "money gone" account.
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.
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]
[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 :
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.
It also rings strange to me. Either this project had an accounting clusterfuck, or a company outsourced this to gp team which has not developed an intuition for how to make those loose ends tight.
I'm a CPA and I recommend my extremely small businesses clients use a single entry excel system. If they use debit for everything they can download the bank transactions in csv. Then use a deep downlist to categorize the transactions. Then a pivot table to display the year end or quarterly income statement. I usually send them the Excel with the pivot table and dropdown list.
Ahhhh, right, my best-loved “we are drowning and have no idea why, can you look at our 40 xls and few html tables” type of client.
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.
the problem with being a larger entity is there may be legal requirements around your accounting system.
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.
Yes, but once you are using Power BI you have lost the friendly interface the op described for categorising transactions, ie it is not a simple spreadseet any more.
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.
