[Feature] Budget Categories distinct from Transaction Categories #1442

Closed
opened 2026-02-28 19:43:39 -06:00 by GiteaMirror · 4 comments
Owner

Originally created by @enewbury on GitHub (Sep 23, 2024).

Verified feature request does not already exist?

  • I have searched and found no existing issue

💻

  • Would you like to implement this feature?

Pitch: what problem are you trying to solve?

For me, there are two use cases for an app like this 1) analyzing past trends 2) budgeting for the current/future. The categories of things I spend money on tend to change year over year as my life circumstances change, or sometimes just short-term variations in spending, but I still want to maintain accurate categories for each transaction so that my first use case (historical analysis) gives me a detailed picture. Unfortunately, as these detailed categories start to build up, it means my monthly budget starts to get more and more messy as time goes on, listing categories that are irrelevant because they were from years past, or one-off expenses. This is an issue I had on YNAB as well, which eventually led me to leave the app. Ideally, for any given month I could configure the specific categories that are relevant for that month without a sprawling list of my entire history.

Describe your ideal solution to this problem

The simplest solution would be to simply allow choosing a subset of the existing categories for a specific month, or "all future months." This would work, but I also like the idea of fundamentally separating the idea of a category on a transaction from a category in a budget. For instance, I like to categorize my transactions in a very detailed way so that I have more data for my historical analysis, but that's not always the same thing I want to categorize by in my budgets.

For instance, I might want a budget category for "Fitness" but on my transactions I'd prefer to be able to see them in more detail as "yoga class" and "personal trainer".

The Budget Category "Fitness" could be represented as a set of rules that matches transactions. In this case it would simply be "transaction category in [yoga class, personal trainer] This functionality would also lend itself very well to the introduction of the concept of tags. Perhaps I want a tag for "ski trip" that includes transactions that have categories of gas, food, and trail passes. In that case you could have a Budget Category called Hobbies that includes the tag of "ski trip" as well as other tags or transaction categories. Budgeting "gas" for the month is both a fixed expense (commuting) and a variable expense (trips for hobbies like skiing/hiking), so budgeting based on these categories isn't that useful.

Transactions that don't match any Budget Category would get flagged as "non matching" the same way they do now when they are "uncategorized" and the user can address it to make it fit into one of the buckets, or perhaps get dropped into an "everything else" budget that matches all transactions. Budget Categories would have to apply in a specific order.

Obviously my ideas are a bit conflated with the introduction of tags as a feature, but I think the power of tags combined with a separate budget category engine/rules would be incredibly powerful.

Teaching and learning

This would require comprehensive explanation in the budgeting fundamentals section of the docs, and a UI in the category creation section of the budget that makes it clear you can select one or more transaction categories or tags. This would also require transaction categories to be able to be set independently, likely directly on the account transaction list.

Originally created by @enewbury on GitHub (Sep 23, 2024). ### Verified feature request does not already exist? - [X] I have searched and found no existing issue ### 💻 - [X] Would you like to implement this feature? ### Pitch: what problem are you trying to solve? For me, there are two use cases for an app like this 1) analyzing past trends 2) budgeting for the current/future. The categories of things I spend money on tend to change year over year as my life circumstances change, or sometimes just short-term variations in spending, but I still want to maintain accurate categories for each transaction so that my first use case (historical analysis) gives me a detailed picture. Unfortunately, as these detailed categories start to build up, it means my monthly budget starts to get more and more messy as time goes on, listing categories that are irrelevant because they were from years past, or one-off expenses. This is an issue I had on YNAB as well, which eventually led me to leave the app. Ideally, for any given month I could configure the specific categories that are relevant for that month without a sprawling list of my entire history. ### Describe your ideal solution to this problem The simplest solution would be to simply allow choosing a subset of the existing categories for a specific month, or "all future months." This would work, but I also like the idea of fundamentally separating the idea of a category on a transaction from a category in a budget. For instance, I like to categorize my transactions in a very detailed way so that I have more data for my historical analysis, but that's not always the same thing I want to categorize by in my budgets. For instance, I might want a budget category for "Fitness" but on my transactions I'd prefer to be able to see them in more detail as "yoga class" and "personal trainer". The Budget Category "Fitness" could be represented as a set of rules that matches transactions. In this case it would simply be "transaction category in [`yoga class`, `personal trainer`] This functionality would also lend itself very well to the [introduction of the concept of tags](https://github.com/actualbudget/actual/issues/1320). Perhaps I want a tag for "ski trip" that includes transactions that have categories of gas, food, and trail passes. In that case you could have a Budget Category called Hobbies that includes the tag of "ski trip" as well as other tags or transaction categories. Budgeting "gas" for the month is both a fixed expense (commuting) and a variable expense (trips for hobbies like skiing/hiking), so budgeting based on these categories isn't that useful. Transactions that don't match any Budget Category would get flagged as "non matching" the same way they do now when they are "uncategorized" and the user can address it to make it fit into one of the buckets, or perhaps get dropped into an "everything else" budget that matches all transactions. Budget Categories would have to apply in a specific order. Obviously my ideas are a bit conflated with the introduction of tags as a feature, but I think the power of tags combined with a separate budget category engine/rules would be incredibly powerful. ### Teaching and learning This would require comprehensive explanation in the budgeting fundamentals section of the docs, and a UI in the category creation section of the budget that makes it clear you can select one or more transaction categories or tags. This would also require transaction categories to be able to be set independently, likely [directly on the account transaction](https://github.com/actualbudget/actual/issues/2787) list.
GiteaMirror added the needs votesfeature labels 2026-02-28 19:43:39 -06:00
Author
Owner

@github-actions[bot] commented on GitHub (Sep 23, 2024):

Thanks for sharing your idea!

This repository uses lodash style issue management for enhancements. That means enhancement issues are automatically closed. This doesn’t mean we don’t accept feature requests, though! We will consider implementing ones that receive many upvotes, and we welcome contributions for any feature requests marked as needing votes (just post a comment first so we can help you make a successful contribution).

The enhancement backlog can be found here: https://github.com/actualbudget/actual/issues?q=label%3A%22needs+votes%22+sort%3Areactions-%2B1-desc+

Don’t forget to upvote the top comment with 👍!

@github-actions[bot] commented on GitHub (Sep 23, 2024): :sparkles: Thanks for sharing your idea! :sparkles: This repository uses lodash style issue management for enhancements. That means enhancement issues are automatically closed. This doesn’t mean we don’t accept feature requests, though! We will consider implementing ones that receive many upvotes, and we welcome contributions for any feature requests marked as needing votes (just post a comment first so we can help you make a successful contribution). The enhancement backlog can be found here: https://github.com/actualbudget/actual/issues?q=label%3A%22needs+votes%22+sort%3Areactions-%2B1-desc+ Don’t forget to upvote the top comment with 👍! <!-- feature-auto-close-comment -->
Author
Owner

@youngcw commented on GitHub (Sep 23, 2024):

Would hiding categories help in your use case?

@youngcw commented on GitHub (Sep 23, 2024): Would hiding categories help in your use case?
Author
Owner

@enewbury commented on GitHub (Sep 24, 2024):

Yes, as long as you could do it month by month and not globally. But for me this is similar to the first solution above, it's an MVP for the immediate need, but in my mind doesn't unlock the full potential of decoupling these two concepts.

@enewbury commented on GitHub (Sep 24, 2024): Yes, as long as you could do it month by month and not globally. But for me this is similar to the first solution above, it's an MVP for the immediate need, but in my mind doesn't unlock the full potential of decoupling these two concepts.
Author
Owner

@enewbury commented on GitHub (Sep 25, 2024):

Ah I see, hiding categories is already a feature. Yeah, this is certainly helpful. being able to set it month by month would be nice so that past months where I used the category it would still show up, but it's definitely not a big deal.

I also see that tags are kind of supported already.

@enewbury commented on GitHub (Sep 25, 2024): Ah I see, hiding categories is already a feature. Yeah, this is certainly helpful. being able to set it month by month would be nice so that past months where I used the category it would still show up, but it's definitely not a big deal. I also see that tags are kind of supported already.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/actual#1442