If you were a business for example, then your "expenses" would actually represent things like business units and other managers and stuff - other people handling money - which is basically what double-entry was invented to manage. But there isn't a "Coffee" business unit for you - it's just a nominal category and really more of a tag explaining why you were paying "Joe's Coffee Cart Holding Inc." $3
My conclusion on this then is that what I really need is an extensive tagging system to associate with transactions, because the actual "accounts" should represent places money can actually go to or did go to - since in the event of unexplained balances and the like, that's the type of thing I can actually track down.
If you borrow your friend money, the fact that someone owes you that money is an asset. If you split rent with someone, and you don't settle it all immediately, that's also an asset or liability. If you do any independent work, double entry lets you realize that when you do the work, and then it's waiting in your receivables until you get paid. Someone pointed out that you don't usually have multiple accounts, but it doesn't have to be just bank accounts - we're talking broker accounts, retirement accounts, savings, credit cards, etc., transfers to these things should not show as expenses. Additionally, you can get smarter and (just like a business) remove money from your available pool, and budget for future.
To be fair, some single-entry bookkeeping tools probably implement some of these features, but in that case they really are just trying to simulate double entry bookkeeping.
On a higher level, I suspect that double entry for individuals would be more popular among HN crowd that in outside world; software is area that slightly selects for people being a little anal about code quality, getting all cases / code paths covered etc., and that is similar quality to wanting to make sure your accounts are in order.
I'm not an accountant but I don't believe this is true. You can use accounts for anything you like. I implement a simple tagging system on top of beancount using accounts like Expenses:Food and it works just fine.
(Plug: I helped add “extension reports” to Fava recently, so you can now also make your own Jinja templates for your bespoke financial goals if querying+custom links isn’t enough)
I can easily [1] represent this as a split transaction where 50$ go out of my wallet's account. Half goes into Expenses:Gifts:Alice, half goes into AccountsReceivable:Bob. Once Bob pays me back, I transfer the money from AccountsReceivable:Bob back into Wallet.
[1] I guess I have different standards of "easy" than most of the population.
Not that it can't be used. I would be happy if this was taught in grade school more. But, I admit it is a rarely needed skill for most.
My checking account is pretty much just account "transfers" and an occasional transfer to my "Cash in Wallet" account for ATM withdrawals.
HOWEVER-
Let me share that beancount actually has the most extensive and flexible tagging and metadata system of any accounting software I've used.
In addition to the conventional hierarchical accounts/categories, with beancount one can attach to transactions- and query with beancount's sql- both:
* arbitrary single value labels, like tags
* arbitrary name-value pairs, like metadata
The flexibility is truly a game changer.
Double entry is for audit ability and balancing the various financial statements. It ensures they stay in balance.
If anybody is interested, the code is open source:
Backend: https://github.com/0x20/backtab
Frontend: https://github.com/0x20/tab-ui
I'm not going to explicitly link to the data but it shouldn't be hard to find if you want to see it
For categorizing new transactions I found that regex matching and doing the rest manually works for me (takes me around 20 minutes every month)
Not necessarily a good idea in every case, but if it's "just data" in the Python config file, you could make the Python config instead slurp in an actual data file of your desired format (YAML, TOML, whatever), and then transform it into Python data structures as needed.
I'm also maintaining an "awesome" resources list for Beancount here - https://awesome-beancount.com/ , in case it's helpful for others.
Fail
~95% of the reason is the fantastic web interface Fava: https://beancount.github.io/fava/
It's a bit annoying that you have to configure it with Python code but once you set it up it's pleasant to use.
The pain point for me right now is figuring out the counterparty for transactions (e.g. I can see that money went out of my bank account to pay the grocery store but I need to map that to the "Expenses:Groceries" category). It seems I need to use some kind of smart importer or something.
One application I thought got that part quite right was Buchhaltung (which works with Ledger/hledger rather than Beancount): https://github.com/johannesgerer/buchhaltung. It's matching system made that dead easy. Buchhaltung also comes with an AqBanking integration if you live in a country where banks actually provide useful APIs.