[GlibMonkeyDeath]

I looked carefully at GnuCash before settling on Beancount (or plain-text accounting in general) for personal finance software.

The deal breaker for me was the underlying XML or SQLite formats of GnuCash. These are not terribly amenable to scripting, either for ingesting raw data or reporting. Whereas this is basically the point of plain-text tools like Beancount or HLedger. GnuCash feels too much like a walled-garden compared to plain-text tools.

The plain-text format requires more work at first, but after you get the hang of it (and provided you have some background in scripting software) it is awesome.

[massysett]

To each their own I guess: my experience is the exact opposite. Plain text looks simple to human eyes but parsing it in a structured way is a nightmare and scripting edits to plain text is a mess.

Databases on the other hand are built for this. After years of dissatisfaction with plain text accounting and many hours spent trying to improve it, I now use SQLite and it has been an enormous improvement.

[GlibMonkeyDeath]

I agree with using the tool that works best for your purpose.

For me, I found that the SQLite models of GnuCash aren't straightforward to query. That's why Beancount created its own query language. Martin Blais has a good discussion of why a traditional database doesn't quite fit for many accounting purposes https://beancount.github.io/docs/beancount_query_language.ht...

[ryansouza]

Part of the reason I settled on beancount over h/ledger was the ease of writing python plugins to handle mutations and rules, and reuse the official parse/output as a library.

Plaintext is nice for git but I only feel that when fixup-ing a single or small number of transactions. It does feel nice to be have all the details of a transaction in one place in a visually useful way. For one-off hacking and such it definitely feels easier to write O(n^4) python looping over trying to describe things with SQL and working at a scale where it doesn’t matter.

Plaintext as a UI into a SQL store seems an interesting project. I would love a git integration for committing changes after diff review and being able to stage individual txns or parts. Many years ago I was frustrated with ledger’s more loosey goosey syntax and trying these things and eventually gave up whatever the idea was at the time. I like the idea of a constant bidrectional sql<->plaintext that provides a requirement for reproducible parsing and serializing

[simonmic]

Not to go off topic - this story did inspire me to install gnucash again and enjoy the GUI -

> parsing it in a structured way is a nightmare

Ah, well that’s the job of the PTA app - converting “just text” to something very structured and validated. Which can then be moved into SQLite, if one likes.

> and scripting edits to plain text is a mess.

I suppose it depends. There are a lot of very powerful and quick tools and techniques for automated or assisted text munging.

[FredPret]

I build my transaction list in Excel and then export that to .beancount with a very simple script. You could do the same with sql except even easier.

That gives me the benefits of Fava and all the other PTA tools as well.

[BeetleB]

As long as the XML/DB schema is documented (no idea if it is), it's actually better and more robust than Beancount/Ledger's plain text format. In fact, I use KMyMoney (XML backend), and have a script to convert the data to Ledger format. The script was easy to write precisely because it's not free flowing text.

[euroderf]

Beancount + Fava looks like a pretty slick combo. Can anyone describe experience with it ?

[seltzered_]

It's a decent experience for personal accounting if you follow the advice from the beancount cookbook/manual for organizing things. I wish there was a bit more integration between the experience of editing and reviewing accounts, and started https://github.com/seltzered/beancolage as an initial attempt.

[jldugger]

>The deal breaker for me was the underlying XML or SQLite formats of GnuCash

... if SQLite isn't sufficient it also supports SQL backends? I've been running it that way for like a decade.