Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I spent some time thinking about this problem recently (after also discovering beancount) and kind of concluded that double-entry accounting doesn't really work so well - as commonly explained - for individuals.

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.



I hear you there, tools like Mint are more than sufficient for most people, however, it's not about how complicated are your finances (having multiple bank accounts, etc.), but whether you actually want to have a clear picture of your assets.

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.


> the actual "accounts" should represent places money can actually go to or did go to

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.


Agree, and if you don’t like the account naming changing it can be a simple cut-and-replace ^h operation. Beancount also supports hashtags on transactions if you need (e.g.for certain events like vacations)

(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've actually found double-entry bookkeeping really useful for personal finances. Let's say I transfer money from one financial institution to another (say, a bank to an investment firm). With double-entry, I can track and reconcile both sides ("legs") of that transfer: one positive, and one negative. And they have to match up for things to balance.


I think the point is that most people don't transfer money between accounts.


Real-world example from my Gnucash file: I buy a present for my friend Alice for say 50$. Another friend, Bob, wants to share half of the cost and promises to give me the money next week.

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.


This is still a very small percentage of expenses most people do, though.

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 credit cards are each an account that I transfer money to each month. Most of my purchases go on one of my cards and then get paid off each month. CC transactions match that CC account and a category like Expenses:Auto:Gas.

My checking account is pretty much just account "transfers" and an occasional transfer to my "Cash in Wallet" account for ATM withdrawals.


Hmm. Treating cards this way feels promising. Might even have the advantage of making you feel each purchase twice.


Have gone through a similar thought process- and don't disagree with the point that double entry specifically is not that helpful for individuals largely tracking cash-

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.


In businesses, accounts represent the what (sales, salaries, rent, hotels, etc). You’d use another dimension altogether for business units. But they all have same chart of accounts. This is so it can be viewed in a consolidated way.

Double entry is for audit ability and balancing the various financial statements. It ensures they stay in balance.


I have the exact opposite experience. Anything that doesn't do double-entry (at least under the hood) is -- eventually -- insufficient for recording the nuances of variation in personal financial needs.


What in the world are you talking about ?! Please consult a CPA and buy a financial accounting textbook. Like in physics every has an equal and opposite transaction.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: