Using Tags in hledger.journal

Hey all,

I am thinking about tagging my transactions.

Accoriding to the manual, a tag is

[...] usually a word or hyphenated word, immediately followed by a full colon, written within the comment of a transaction [...]

This seems very liberal. As I put the description of my CSV-Import as a comment, printing all my tags for my 2024.journal with hledger tags gives me lots of unintendet tags such as IBANs or Billing IDs.

My plan for next year is to tag some transactions. For example, a tag "vacation:night train journey 2025", which covers a "expenses:mobility:trains" as well as some, "expenses:supermarket:earplugs", ... accounts provides the total amount of how much I spent for the trip across multiple accounts.

I am wondering how you are dealing with it? Do you use tags in a similar way?

Do you leave the tag list as untidy as it is (as it doesn't do any harm)? Or do you remove all colons before importing the data into the ledger? Is there a "strict" mode that only accecpts a prespecified list of tags?

Looking forward to your comments! :slight_smile:

Yes there is: hledger check tags (https://hledger.org/1.41/hledger.html#other-checks).

However I don’t use it because as you say tag syntax is very liberal and so I have a ton of accidentally created tags. It’s a bit of a problem.

But, not really causing trouble; so I have ignored it.

I use a trip: YEAR:PLACE tag for trip-related txns.. Also a general purpose id: tag for storing that kind of thing (instead of the layout-disrupting code field)..

Also acquire: and dispose: tags to mark capital gains-related events.

clopen: NEWYEAR to mark the closing balance txns of OLDYEAR and opening balance txns of NEWYEAR, helping to exclude those from reports.

assert: to mark my roughly biweekly balance assertions txns made to satisfy check recentassertions.

TODO: for things needing follow-up.

t:TYPECHAR in my timedot file to add another dimension of categorisation, though that one is added automatically by using timedot letters. Occasionally p:PROJECT NAME to add some more detail to time categories without cluttering the main categories.

Most of these are just markers for reliable querying, eg when I don’t trust myself to keep consistently matchable descriptions/accounts over the long term. trip:, t: and p: are the main ones with values, which I show with --pivot now and then.

1 Like

I just had a look at all the checks... another can of worms soon to be opened. :smiley:

(Might be worth another thread, but I just tried to include the .rules file with strict checks. I thought, "Hey, there are already most of my accounts specified", but I get the following error hledger: Error: sorry, rules files can't be included...)

Back to the topic:

The check for tags does not really help here, because it throws an error for each unintended tag. I would need a function to ignore these tags and only accept prespecified ones. The check makes it actully worse... so I think I'll follow your suggestion (what was already my gut feeling) and ignore all the noise in the tag list. :slight_smile:

Correct, CSV files neither (doc). I'd welcome a PR implementing that.

1 Like

I use tags for vacation trips as well.
My format is like this: location_seasonyear - reno_winter2024 .

Then I tag all the transactions pertaining to the trip like this, include airfare, food purchases, room rentals, etc. That way I can figure out the total amount I spent for that trip.

I don't make new accounts for trips, since tags work quite well for my use case.

Also, i don't use csv imports - i add my transactions in manually.

1 Like

There are many reasons to use tags. I like the fact that it's been kept open ended and sort of a "free to define your own meaning". I use tags when I need multiple sub-categorizations under accounts.

With one sub-categorization, I would need just one tag. In this case, the account graph ends up flattening itself enough for the tag to be unnecessary.

2022-01-01 * Auto
  model: bentley
  expenses:car:maintenance  45 USD
  assets:cash

would normally look like this

β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”     β”Œβ”€β”€β”€β”€β”€β”     β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
β”‚ expenses β”‚ ──> β”‚ car β”‚ ──> β”‚ maintenance β”‚
β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜     β””β”€β”€β”€β”€β”€β”˜     β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜

with some metadata about the model. But this can easily be flattened to

β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”     β”Œβ”€β”€β”€β”€β”€β”     β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”     β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
β”‚ expenses β”‚ ──> β”‚ car β”‚ ──> β”‚ {model} β”‚ ──> β”‚ maintenance β”‚
β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜     β””β”€β”€β”€β”€β”€β”˜     β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜     β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜

When this is multiple, then tags become interesting to consider

2022-01-01 * Auto
  model: bentley
  dealer: The Dealing Company
  owner: John Doe
  expenses:car:maintenance  45 USD
  assets:cash
β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”     β”Œβ”€β”€β”€β”€β”€β”          β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”           β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
β”‚ expenses β”‚ ──> β”‚ car β”‚ ─┬─────> β”‚ {dealer} β”‚ ──────┬─> β”‚ maintenance β”‚
β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜     β””β”€β”€β”€β”€β”€β”˜  β”‚       β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜       β”‚   β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜
                          β”‚                          β”‚
                          β”‚                          β”‚
                          β”‚                          β”‚
                          β”‚       β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”       β”‚
                          β”œβ”€β”€β”€β”€β”€> β”‚ {model}  β”‚ ───────
                          β”‚       β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜       β”‚
                          β”‚                          β”‚
                          β”‚                          β”‚
                          β”‚                          β”‚
                          β”‚       β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”       β”‚
                          └─────> β”‚ {owner}  β”‚ β”€β”€β”€β”€β”€β”€β”˜
                                  β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜

There's probably some way to further simplify this. But this has been my experience with using tags. I'm curious, have you stumbled on any use case for tags which isn't satisfiable with accounts?

I'm also curious to learn how everyone else uses tags

2 Likes

I should cc this related answer here, also:
https://plaintextaccounting.org/FAQ#should-i-categorise-with-account-payee-description-tags...

1 Like

My system uses tags extensively. It's different from hledger, though. I am trying to migrate to [h]ledger, but haven't figured out exactly how to do the tags, yet. I didn't even know you could have them outside of comments.

Apparently, some tags can be added to a posting, rather than the whole transaction, which I may like to do with metadata about a particular account, like FITIDs and check numbers. My format could support that, but I used other methods instead of implementing it that way.

Documentation ids are the main tags for the transaction, and there may be multiple of those. Otherwise, I mainly use accounts for categorization. I sometimes use tags temporarily while trying out different possible organizations, though.