Tags/Categories Use Best Practice?

I was able to get transaction tagging working along with the [Tags Report sheet] (Docs: Tags Report for Transaction Tagging). It works great so far, but it got me thinking about how to best structure my categories and tags going forward to make best use of this reporting.

I can now tag both transactions and categories. Add to that the actual value of the category itself. I’m thinking something like broad categories then add the details with the transaction tags. Or perhaps rather capture the lowest level, most detail with the category, then add additional metadata with tags.

Anyone have any systems that works for them? I don’t have a great need for identification of things like tax-deductible items, but I recognize that would be another dimension well-suited for tagging.

1 Like

Here is my approach. I do not get much value out of tagging. I too set up a Tags tab and experimented with it to learn how it works. Tiller touts it for gathering tax information to itemize deductions. I think you get more benefit from designing your categories like you would have done had there been no ability to tag. Some advocate for fewer categories rather than more categories. I like more categories versus less. Currently, I have 326 categories spread over 27 groups. Call me crazy but that is what I want and what works for me. I think determining your category methodology is the most important thing to get right when you are first setting up your Tiller sheet. So, you are wise to think this through so you get the level of detail that you want. I believe Tiller has told me that they only support 150 categories but I am able to use more by making certain modifications elsewhere in the sheet. Please let me know what you think.

326 is too many categories for me to manage. Rather than a flat categorical system spread out enough to cover all me needs, I prefer a hierarchical system leveraging categories and groups plus tags.
My need for tags stems from the need to annotate transactions with more than one piece of metadata. A single category simply cannot mark my lunch expense as both a business expense and as a food expense.

1 Like

Sounds good. You need to do what meets your needs. Regarding your lunch example, that is a perfect use of a tag. Another way to handle that lunch example is to use two categories: Lunch - Business, Lunch - Non-Business. Sounds like you have thought through this which is what is important. Good luck! :+1:

I suppose it all depends on what you want from your tags. I made my own two types of Tags before I realized that Tiller Labs has a that built in (for one tag, at least).

I try to keep smaller amounts of broader categories. I have used Tags in Mint for reimbursable expenses. I use my two types of tags in Tiller mostly for keeping transactions and balances straight because my wife and I have some shared and some personal expenses and I track, for example, whether it is Shopping - Personal or Shopping - Shared. I added a drop-down to the Monthly Budget sheet where I can choose to view either the Personal or Shared budgeted and actual costs but that’s probably overkill for most people’s use cases.

@hmtinney
FYI the Tags column supports multiple tags using CSV (comma-separated-values) format.
However, when using multiple tags, there is a risk of double-counting in sum or totals calculations since values might be counted for multiple tags in 1 cell.

@Blake would you be open to sharing your list of categories and types (groups)? I currently have about 80 categories and considering restructuring them. Could use some inspiration! Thanks

I have a lot of Categories too.
I use Groups with specific Categories in them.
Each transaction can have only one Category and only 1 Group.
However, Tags are different.
Just like their use in photos each transaction can be associated with multiple tags.
I have a tag for each vehicle and for each vacation. So fuel on vacation has at least 2 tags on it.
Then I know how much I’m spending on that vehicle.
And I also know how much I spent on that vacation.