Transactions: Types, Categories, Tags

[flacnut]

I notice when creating a transaction I can choose between Income, Expense, and Transfer. I can the set a category, which on Expense may be Income.

I really like the power of categories, but I feel like something else is missing, and the additional layer of a transaction type (selected on creation) seems unnecessary.

Proposal:

Introduce Tags, Remove the "type" selector on the new-transaction modal, and keep categories as they are.

I currently do this on my own "self-host" finance app I've been building, "Collateral". I plan to deprecate my app in preference of contributing to and using Maybe.

Category

All transactions have a single category, it can be Transfer (then ignored from +/- net worth calculations), Expense, Income, or anything else the user defines. Can be toggled to "Include or exclude" from Net Worth calculations, so things like Transportation can count as an expense, but Transfer may not.

Tags

All transactions may have any number of tags. For example, income could be a dividend, capital from asset sale, a tax refund, salary, bonus, commission, etc. Having separate Categories for all these quickly won't scale.

Here's an example, in this case I care about recurring expenses because they are "fixed", so I have a category for it:

I have (in my app) implemented tags as a many-to-many between transactions and tags, but I regret this decision as it makes for more completed SQL in my ORM when trying to query / filter transactions by tags (has-any, has-all etc). It would be far simpler I think to have a Tag table, and then the transaction object has an Array column which stores the IDs of tag table rows. Postgres supports Array type columns and operations, but SQLite which I used in the past does not.

I plan to take a swing at this, let me know what you think.

[jakubkottnauer]

Hello! You beat me to it, I was about to create a similar discussion. I would also like to see tags being added as it enables a lot of additional flexibility 👍 For example, tracking how much I have spent on food during this year's trip to Japan would be a matter of filtering on expenses in 2024 in the food category with the tag japan.

But as for the second part of your proposal (removing transaction types), I much prefer Maybe's clear distinction between Income/Expense/Transfer. For example, transfers are going to have some special UI elements attached to them (an icon in the transaction list, probably some UI to link transactions together, ...). If everything was a category instead, it would mean that just the Transfer category would have to be treated in a special way, which I think would introduce a lot of complexity and confusion.

Granted, whether a transaction is an expense or transfer can be derived from sign of the amount + account type but I still feel like choosing the type explicitly even for this results in better UX as opposed to forcing the users to fiddle with + and - signs.

[flacnut]

Here's a draft of what it might look like, I added some demo_data:

Thoughts on displaying:

• Tags should be rendered based on frequency of use (from more to less frequent), so this would show something like:
  • [Transportation, Flights, Japan-Trip]
  • [Transportation, Flights, London-Trip]
  • [Transportation, Petrol]

Tags should probably all have the same color, or inherit a color from a category if we deem them "special", but tbh I think this really hurts readability.

How do you want to edit transactions?

• v1: Probably editing transactions in the side-view with an autocomplete text input tokenizer.
  • Keeping this consistent between transactions (ie, "What tags did I use last time for this?") will be hard.
• v2: Suggest tags based on similar transactions already tagged in side-panel edit.
  • Prepopulate the field so you just hit "save", or you can edit and save.
• v3: Allow bulk-selecting transactions to apply tags
  • Works really well with filtering the transaction list view.
  • Can include a filter for 'untagged' transactions.

[flacnut]

See: #714

[zachgoll]

@flacnut thanks for this detailed proposal, I've left some responses below:

Introducing Tags

I 100% agree with you and @jakubkottnauer that we should add tags to the system. @jakubkottnauer's example of the "Japan Trip" is a perfect use case for this and adds a ton of flexibility to the system.

Removing Types

I do not think that we should ever depend on a Category or Tag to determine the nature of a Transaction.

Categories and tags are editable by the user, and therefore, should only be used for things like searching, filtering, and organizing data within the UI.

A "type" would represent a more stable attribute on a Transaction that we could use to link transfers, payments, display trade info (brokerage), and more specific behavior that only that "type" has.

Let me preface this by saying that the below is NOT FINAL, but here's a "types" hierarchy I was brainstorming. We've got quite a bit of work to do before all of this is supported, but I see these as the types that code can depend on for enabling certain UIs and syncing behaviors:

[flacnut]

Thanks for the detailed response and sharing some of the roadmap!

I'm happy to do the BE and then FE work on this once the designs are up, and I think keeping transaction-type makes sense given what you shared above.

I have about 10,000 transactions already tagged in my existing system, so once Maybe supports tags I'll be able to migrate it over.

[zachgoll]

Awesome, we've got some design work kicked off for the tags, so once that's all done I'll convert everything into a GH issue!

[zachgoll]

Closing this out as I think we've got a solid path forward for this implementation and it will be on the roadmap shortly.