(Seriously!) Why would you use something like this over say a spreadsheet? Is it really much easier than opening a browser and running Google Docs???
Because doing double entry accounting with the kind of reporting, balance checking, automatic addition of balancing entries, etc., that ledger-cli provides is difficult.
And because its plain text, it works quite well with the same kind of version control, diffing, etc., tools used for code.
> Is it really much easier than opening a browser and running Google Docs???
* It is plain text, so you can keep your data in version control.
* It has awesome reporting capabilities. These are builtin, so you don't have to create them from scratch.
Spreadsheets are nice and simple, but once you do anything moderately complex you are asking for bugs under all of your hidden formulas.
In a way, it's exactly what you are thinking would be superior: why not use some general purpose tool for data entry and then write some macros for generating reports? It's just using a text editor rather than a spreadsheet.
The text editor is actually quite a bit better suited to this kind of entry than a spreadsheet. Have a look at the examples at the website. Since the journal is also just a text file, you can easily use a version control systems on the data -- this has saved me more times than I care to mention.
So, yes, it really is easier than just about everything else you could imagine. If you are interested in double entry accounting, I highly recommend it.
Over the many good GUI dual-entry accounting programs, I'm not so sure.
The simplicity of simple text files means you don't have to worry about your files not being readable by a future you. Which is not the case of every 'gui' dual-entry accounting system to date. Seriously, pick any system you could have used in 2000 and figure out if you can read its files now.
I won't touch anything from Intuit.
> Seriously, pick any system you could have used in
> 2000 and figure out if you can read its files now
As for the GUI, still needs to be built on top of something, why not this.
This actually looks really cool and I'm interested in checking it out. I've often thought about how cool it would be to have double entry accounting for every day life.
> you might want a computer to do all of the work
I'm a programmer, and I love programming, but not everything needs my time and attention to program. I also (no longer) run my own mail server, just because I can.
How is double entry beneficial once all transactions are documented digitally? Could you give a somewhat concrete example? (Contrived or otherwise)?
In Japan, the government actually gives me concessions for submitting my documents for income tax as double entry accounting. This is because it saves them huge amounts of money. So, if I document an expense that I want to get a deduction for, they can easily check that there is a corresponding withdrawal from the bank account to pay that expense. Especially for complicated areas, like my payroll, where I have up to 5 bank accounts in play (some of them off shore), it's absolutely the only way they can go back and understand what the heck is going on.
Similarly, for me, I have sometimes gone back and discovered that I got an exchange rate wrong. Fixing that mistake is a nightmare (especially if you have to pay capital gains tax in a LIFO or FIFO manner -- you have to record the capital gains or losses for each "lot" of currency that you purchased). Double entry accounting will totally save your butt as you ripple through all your transactions changing the exchange rate for the foreign currency. If you get it wrong (i.e. over or underspend a particular "lot"), the numbers won't balance at the end.
Is it necessary for your average person? Obviously not. As your finances become more complicated it kind of goes like this: intellectually interesting -> super cool -> crap, how did I get by without this? -> there is absolutely no other way to do it and not get arrested for tax evasion.
When you think about it, all transactions have naturally (at least) a from and a to account. In the simplest example, I move $100 from one checking account to another. This is a pain to model in a spreadsheet, where I literally create two entries, but very easy to model in an electronic dual-entry system where I create a single transaction with a from and a to end point, and an amount.
Consider if I decide to buy a stock from my checking account. The from is my checking account, and then there are two "to" accounts - an account which models the value of the stock, and an account for the vendor's charges for the purchase. I might decide to aggregate all such bank charges to a single virtual account for this purpose. In this case, that virtual account would be the same as a "category" in a spreadsheet based model.
It can also make budgeting and cash-flow visualization easier. I have a virtual account called "Holiday Budget", which makes a transaction to another virtual account called "Spent on Holidays" of $x every month. Whenever I spend money on a holiday item from my checking account, the "from" is my checking account, and the "to" is my "Holiday Budget". This keeps my net-worth and budgeting reports very simple - they say I spend the same $x on holidays every month - while accounting for some very lumpy spending. I can easily see if I'm over or under budget by looking at the value of the virtual account "Holiday Budget" at any point.
It makes recording the value of unconventional assets easier. When I buy a laptop, I create a new account for the laptop, and transfer the money from my checking account to the virtual account that represents the value of the laptop. Every month, I draw down money from the laptop account in to an account called "depreciation". This helps me keep my budget reports insulated from lumpy spending too.
A big use-case as well for me is the purchase of expensive refundable plane tickets - essentially, I buy personal futures in plane tickets when I see a good price. The virtual accounts that dual-entry allows means that when I buy a refundable ticket, I treat it as an asset in a virtual account until it's used. Again, this helps me track my spending and budgetting more effectively.
I would like to hear more about this. Do you have alerts set up? Does this end up saving you money? Do you get to re-schedule the flight an unlimited number of times (pushing the future out) or do you have to cancel and rebuy periodically? Can you use exercise the option early?
Hm. I guess I didn't know there was such a thing as single-entry :-)
Thank you for clarifying, that makes sense. We actually had a (little too much, or too little) about this in high-school. But it looked a lot more like: https://en.wikipedia.org/wiki/Double-entry_bookkeeping_syste... (debit and credit "accounts").
It struck me as odd to keep the term when handling it somewhat differently (although also somewhat similarly).
I suppose the term is old enough that it covers both "double meta-data" and "double(redundant/check-summed) storage".
Why not move $x from checking to Holiday Budget every month, and then track holiday spending by moving money from Holiday Budget to Spent on Holidays?
Guess it throws off net worth calculations a bit, as you'd have to include the Holiday Budget as well in there. Are there other reasons?
Stuff like this (and the next section) is easily doable: http://ledger-cli.org/3.0/doc/ledger3.html#Dealing-with-Pett...
A lot of the things you'll think to do in an electronic system, with tags and tables and so on, can ultimately be modeled by accounts in a double entry system, and probably just as powerfully once you add things like "virtual accounts" and the like.
At some point, it's sort of like greenspun's 10th rule - any sufficiently advanced money tracking system will implement a version of double entry accounting in it.
> MoneyDance doesn't appear to be a double entry system
To those who don't "get" the CLI madness, I can see why you're drawn to the Windows ecosystem.
Bash, to Vim, to Python. It was glorious.
That said, if that works for you, then that's exactly what you should do.
Experts prefer plain-text formats and command-line tools because with a little bit of elbow grease you can always do things the program creator never thought of or chose not to support.
> Experts prefer plain-text formats and command-line tools
You'd be surprised. There's a list of writers who use Emacs floating somewhere around the interwebz, Vernor Vinge being a notable example. I can't find it right now, but few of those authors are mentioned here: http://irreal.org/blog/?p=4651.
"The command line" isn't really involved here - they're arguably GUIs rendered in the terminal. Another term is "Captive User Interface", although a text editor is one of the few places I don't mind it.