Comment by balves | Hacker News Reader

Comment by balves | Hacker News Reader

Parent Full thread

I switched to beancount after trying several other things (mint, spreadsheets, gnucash), and I like it quite a bit. It's choice to be very strict about things held at cost (like units of stock) is a great differentiation.

It's VERY hard to accidentally miss capital gains, or get cost basis wrong on something, or have something not balance. Much harder than even ledger-cli, let alone the other alternatives. It feels at times like working with a static type system versus a dynamic type system.

And the burden associated with this is not anything more than other tools. Importers have been great. I have 68 asset subaccounts between my spouse and I (if you do double-entry accounting you'll know this isn't actually that many), and I spend about 1-2 hours a month balancing the books, doing reporting, etc.

Finally, it's quite easy to get your transactions into a pandas datatable or similar, allowing you to utilize your programming/datascience skills to do things that just aren't available in other tools. Mint offers nothing here, spreadsheets can do some of it (but the downsides of accuracy), and gnucash requires learning some niche scheme stuff; it feels very "tacked on".

> gnucash requires learning some niche scheme stuff; it feels very "tacked on".

There is also piecash, which gives a nice Pythonic interface to the SQL files generated by GnuCash: https://pypi.org/project/piecash/

Bear in mind that using SQL in GnuCash may result in data loss:

> Note this feature is considered experimental. It works for most of the common use cases but some corner cases have been reported to result in data loss. [1]

[1] https://gnucash.org/features.phtml

> Importers have been great.

What importers do you mean? Are these importers you've written yourself, or existing importers you were able to reuse? What format are these importers pulling from (PDF statements, CSV, OFX, etc)?

https://github.com/redstreet/beancount_reds_importers/tree/m...

https://github.com/jbms/beancount-import

https://beancount.github.io/docs/importing_external_data.htm...

Support for OFX is generally great, CSV is also great. There are some proof of concept things floating around too for PDF.

Do you find that all of your financial institutions offer reliable OFX/CSV feeds?

I'm asking because I've generally come to the conclusion that PDF is the only universal data format that every institution will offer.

All of my high-volume (in terms of number of transactions) accounts are easily importable. There are a few that don't have great import functionality, but I only have 1-2 transactions on them a month so haven't felt the toil pain to better automate them. 1-2 hours a month of balancing is not worth optimizing down to 0.5-1 hour to me.

OFX is the closest to being universal, although often it is well hidden.

CSV feeds are often surprisingly useless for programmatic / feed use, they're often littered with stupid textual headers and footers and lack important columns - they're designed to be opened in excel and looked at by a human, not parsed and ingested.

There's also the heterogeneity of transactions. Looking at the csv export I've got from my bank, there are three "reference" columns and they play different roles depending on how I'm paying:

    - debit card: merchant name + date, card number, blank
    - alternative card-based payment system: constant (account number?), merchant, constant
    - alternative app-based payment system: constant, merchant, user custom reference

And a data sanitation issue: one of the merchant names has a comma in it, and it's not escaped or quoted in the csv so that record is corrupted.

Not GP, but in my experience they offer CSV with the most helpful columns for programmatic use omitted; present only in the PDF.

Of course I've submitted requests pointing it out/requesting it, but to be honest I can only assume it's deliberate.

I've been using beancount for 3+ years and totally agree, the flexibility of it is the real USP.

I've never used any import tools though, I just enter the transactions manually maybe once or twice a week. It's been fine - especially using beancount-mode for emacs, although admittedly it's just my accounts, it might not scale so well for a family.

There's an upcoming UI to input stock transactions and will explicitly request capital gains, so, there will be fewer opportunities for error.

https://github.com/Gnucash/gnucash/pull/818

For GnuCash it’s easy to parse it’s XML files or Sqllite database, so you don’t have to mess with scheme.

Reply on news.ycombinator.com