I really don't know for whom this is for. For Normal People: Double Entry even though may sound simple, it is quite a difficult concept to grasp. For the sake of double entry we use counter entries that take months to grasp. For example - Amortization, Allowance etc. More over double entry method strives for standardization of entries. Having a plaintext non-autocompleting solution without accounting for only handful…
- For example, instead of someone needing to remember passwords to five different current accounts and credit card sites, there are ruby scripts that download the data, convert them into journal entries and get committed to git. (Commercial packages can read your credit card data too, but there will always be a data source you need that they don't support)
- The scripts get committed and version controlled, but the ledger files themselves go into git as well. So you can bi-sect, revert, merge. All the tools git gives you that are an order more powerful than what an accounting package will have.
- As an organisation grows it will run into weird business specific processes, e.g. some tax or reporting requirement that your off-the-shelf package cannot do. If it's all just plain text files and code then the reporting requirement is one more ruby script away. (I've been a consultant in a previous life and you wouldn't believe the man hours that get lost in accounting departments with people doing these manual chores)
- Filling out quarterly tax statement is again just a single script. Took a bit of time to get it to work but now saves a lot of man hours each time.
There is a disadvantage: your average accountant won't know what ledger is or how to use it. But we have yet another little script that converts the ledger output to Excel for use in audits, etc.