> My major gripe with hledger and other plaintext accounting systems: setting up the correct rules (regex for your expenses) takes too much time as it involves:
> a) defining the regexes/categories) for dozens to hundreds of expense descriptions (e.g. walmart, gas station xyz)
We don't usually do it all up front; it's easier to build up your rules over time, improving them a little each time you download.
> b) "recompiling" your hledger journals after every rule change
It's not required (see my other comment).
> c) checking for negative and positive errors (expense description was not matched OR too many different expenses were matched)
For the not matched case: hledger's fallback category is "expenses:unknown" (and inflows are "income:unknown").
I usually watch for those, with something like
and tweak rules until there are no unknowns, before importing.
For the other - I guess I have a similar answer - if you're not certain of your rules, preview the conversion and tweak them, before finalising it.
> This process is much faster in a spreadsheet application. IMHO the journal format of hledger and other plaintext accounts apps is too verbose.
You can keep your data in CSV/TSV instead of journal. This could be better for spreadsheet interop.
I think a more compact, but still readable journal format would be interesting (something between CSV and current journal format).
I agree some things are much easier in a spreadsheet (and also, vice versa).
> it would be a great relief if someone started a Github repository with expense texts used when you e.g. pay at Carrefour in Italy or Walmart in the USA with your debit card. People could submit those descriptions from the CSV exports of their bank accounts.
Please do, I would love to see it! However, wouldn't it be a really huge list of text patterns/regexps, with 0.1% of them useful to any one person ? Perhaps region-specific collections could work.
> Another annoyance in Europe is that there is no API connection for open source apps to bank account statements, you always rely on manual CSV exports.
Ha! It's not better in the US at least (except, by giving up your bank credentials to third parties). We are usually envying your APIs over there.
We don't usually do it all up front; it's easier to build up your rules over time, improving them a little each time you download.
> b) "recompiling" your hledger journals after every rule change
It's not required (see my other comment).
> c) checking for negative and positive errors (expense description was not matched OR too many different expenses were matched)
For the not matched case: hledger's fallback category is "expenses:unknown" (and inflows are "income:unknown"). I usually watch for those, with something like
and tweak rules until there are no unknowns, before importing.For the other - I guess I have a similar answer - if you're not certain of your rules, preview the conversion and tweak them, before finalising it.
> This process is much faster in a spreadsheet application. IMHO the journal format of hledger and other plaintext accounts apps is too verbose.
You can keep your data in CSV/TSV instead of journal. This could be better for spreadsheet interop.
I think a more compact, but still readable journal format would be interesting (something between CSV and current journal format).
I agree some things are much easier in a spreadsheet (and also, vice versa).
> it would be a great relief if someone started a Github repository with expense texts used when you e.g. pay at Carrefour in Italy or Walmart in the USA with your debit card. People could submit those descriptions from the CSV exports of their bank accounts.
Please do, I would love to see it! However, wouldn't it be a really huge list of text patterns/regexps, with 0.1% of them useful to any one person ? Perhaps region-specific collections could work.
https://github.com/simonmichael/hledger/tree/master/examples... is hledger's collection of CSV rules; these cover the basics of CSV conversion, but not the expense categorising.
> Another annoyance in Europe is that there is no API connection for open source apps to bank account statements, you always rely on manual CSV exports.
Ha! It's not better in the US at least (except, by giving up your bank credentials to third parties). We are usually envying your APIs over there.