One of the main reasons I stick with Gnucash is the monolithic file format. If one day I need an accountant to review my finances, or if I suffer an audit by the tax man, I can send on the single .gnucash file with all my data. While Gnucash's UI is not the greatest, an accountant/auditor can easily install Gnucash and generate reports with only basic knowledge.
Another nice feature is the file linkage features, where I can directly link my payslip pdf files to the gnucash entries. I have folder structure on my GDrive with all of my stored bills, payslips etc. If required, I can zip up my Gnucash file and corresponding documents folder and the reviewer can instantly access important financial documentation from within the Gnucash application. Gnucash uses relative file paths for sourcing linked documents - all a reviewer has to do is specify the head directory and all the linked documents will open as usual. Correct me if I'm wrong, but I dont think this is a feature in the text-only approaches.
> Correct me if I'm wrong, but I dont think this is a feature in the text-only approaches.
I unless I'm missing something, all those features are available to me now.
> If one day I need an accountant to review my finances, or if I suffer an audit by the tax man, I can send on the single .gnucash file with all my data.
I can do the same with a git repo, or a zipfile.
> an accountant/auditor can easily install Gnucash and generate reports with only basic knowledge.
I'm not sure I understand the advantage here. A professional could install beancount too, and run the same scripts I do. My real life experience is they don't actually want this level of depth.
> Another nice feature is the file linkage features, where I can directly link my payslip pdf files to the gnucash entries. I have folder structure on my GDrive with all of my stored bills, payslips etc.
You can link to external documents in Beancount and possibly the others and it's kept in the same archival system:
Maybe I can answer this a bit for you. I used GNUCash for a while and then switched over to hledger.
1. I personally prefer graphical tools, especially when looking at a sea of numbers. I gravitated to GNUCash because, even if the tool felt crufty, it was still a lot easier to read/get started with than hledger.
2. I used GNUCash for a long time. GNUCash has a very cool autocomplete feature that actually makes it quite easy to enter in recurring transactions. Things like regular bills, income debits, etc are all trivially autocompletable.
3. GNUCash makes it really easy to generate reports. While hledger certainly is infinitely scriptable/manipulable, GNUCash has a much easier out-of-the-box experience to use.
The main thing that made me switch to hledger was the ease of autogenerating transactions into a plain-text format. My partner and I split many expenses and we often travel with friends so I split many things many ways. I also fund my parents to some extent and so I buy gifts/split transactions with my parents. GNUCash made recurring transactions easy but made it a lot harder to generate split transactions according to fixed splits that I regularly engage with my friends/family in.
With hledger I have a system of taking CSVs, classifying transactions using a stack of Python scripts and using them to generate hledger importable files. I go by hand and annotate transactions that my scripts couldn't classify/split, and then I import it into my main hledger file. I store all my inputs and intermediate imports in a git repository along with my main ledger file for auditability and to look at annotations. The ease of automation just can't be beat with PTA but it's definitely harder to use if you don't have a preference for TUI work.
I have. All of the plain text accounting packages are optimizing to solve the exact wrong problem. The reality is that even if you are using a commercial package, it's generally not hard to get a CSV (or something like it) OUT of the software. What you actually need for a sufficiently complex financial life is input validation, and that's exactly the problem that plain text accounting software punts on.
Gnucash has a lot of cruft and definitely feels like it was written in 2003, but it does address this issue and provides the basic input validation you need to minimize errors.
The other issue with plain text accounting software is most of it only flags errors after you 'compile' your books (or, more properly, run them through some sort of command-line tool), which is far too late to make data entry convenient. (Some of them have web-based tools, like beancounts "fava" package, that act more like Gnucash...but at that point the term "plain text accounting" loses all meaning IMO, you're just using another client, so why not use a better one?
> What you actually need for a sufficiently complex financial life is input validation, and that's exactly the problem that plain text accounting software punts on.
Which input validation do you get in gnucash that you don't get in e.g. hledger? Asking as a hledger user. So far I mostly have assertions every month about account balances, and of course hledger checks itself that transactions are balanced. I avoid duplicating accounts (say expenses:something:stuff and expenses:other_thing:stuff) using autocompletion.
One of the main reasons I stick with Gnucash is the monolithic file format. If one day I need an accountant to review my finances, or if I suffer an audit by the tax man, I can send on the single .gnucash file with all my data. While Gnucash's UI is not the greatest, an accountant/auditor can easily install Gnucash and generate reports with only basic knowledge.
Another nice feature is the file linkage features, where I can directly link my payslip pdf files to the gnucash entries. I have folder structure on my GDrive with all of my stored bills, payslips etc. If required, I can zip up my Gnucash file and corresponding documents folder and the reviewer can instantly access important financial documentation from within the Gnucash application. Gnucash uses relative file paths for sourcing linked documents - all a reviewer has to do is specify the head directory and all the linked documents will open as usual. Correct me if I'm wrong, but I dont think this is a feature in the text-only approaches.