[BUG] Auto categorization rule not created on new transaction or update of transaction #124

New Issue

GiteaMirror · 2026-02-28T18:49:24-06:00

GiteaMirror commented

2026-02-28 18:49:24 -06:00

Originally created by @winklevos on GitHub (Aug 21, 2022).

When creating a new transaction and a new payee, adding a category does not auto-create a related rule

The same occurs when updating an existing transaction from uncategorised

Browser: Firefox and Chrome
Version: https://hub.docker.com/r/kippenhof/actual-server latest
Confirmed the same behaviour locally building from master

Originally created by @winklevos on GitHub (Aug 21, 2022). When creating a new transaction and a new payee, adding a category does not auto-create a related rule The same occurs when updating an existing transaction from uncategorised Browser: Firefox and Chrome Version: https://hub.docker.com/r/kippenhof/actual-server latest Confirmed the same behaviour locally building from master ![image](https://user-images.githubusercontent.com/30995408/185774427-265e0640-9c92-4dff-87b1-123d8af30420.png)

GiteaMirror closed this issue

2026-02-28 18:49:25 -06:00

GiteaMirror commented

2026-02-28 18:49:25 -06:00

@rich-howell commented on GitHub (Aug 21, 2022):

Hey @winklevos

This looks to be by design, if you take a look at the documentation https://actualbudget.com/docs/other/rules/ it states the following;

Here's the best part: you might never need to touch rules. Actual will automatically create rules for you based on your behavior. >As you rename payees or categorize transactions, it will use rules as a mechanism for writing down what you've done so it will >automatically happen later. For example, if you categorize the payee "Kroger" as "Food" a couple times, it will create a rule to >automatically apply that category on import. As you use Actual more, your data will automatically get cleaned up for you based >on your previous behavior.

Actual will create a rule based on how you use it.

Hope this helps, if you need anything more please do reach out or @ me in discord and I will re-open this issue.

@rich-howell commented on GitHub (Aug 21, 2022): Hey @winklevos This looks to be by design, if you take a look at the documentation https://actualbudget.com/docs/other/rules/ it states the following; >Here's the best part: you might never need to touch rules. Actual will automatically create rules for you based on your behavior. >As you rename payees or categorize transactions, it will use rules as a mechanism for writing down what you've done so it will >automatically happen later. For example, if you categorize the payee "Kroger" as "Food" a couple times, it will create a rule to >automatically apply that category on import. As you use Actual more, your data will automatically get cleaned up for you based >on your previous behavior. Actual will create a rule based on how you use it. Hope this helps, if you need anything more please do reach out or @ me in discord and I will re-open this issue.

GiteaMirror commented

2026-02-28 18:49:26 -06:00

@winklevos commented on GitHub (Aug 21, 2022):

@rich-howell this bug is saying it isn't creating as per this documentation.

When categorising transactions rules are not created automatically.

I have a working fix in progress that adds the behaviour I expect

@winklevos commented on GitHub (Aug 21, 2022): @rich-howell this bug is saying it isn't creating as per this documentation. When categorising transactions rules are not created automatically. I have a working fix in progress that adds the behaviour I expect

GiteaMirror commented

2026-02-28 18:49:27 -06:00

@rich-howell commented on GitHub (Aug 22, 2022):

I am happy to re-open this for you, however this isn't a bug.

The rules engine will decide when a rule needs to be created based on the factors used within the transaction. If you just create one transaction for say Grocery and select the merchant and value a rule won't be created because you would end up with rules for every single thing.

I am not sure if you will get your PR merged into main if it create a rule for every single transaction added, but I will leave this open for James to review when the time comes.

@rich-howell commented on GitHub (Aug 22, 2022): I am happy to re-open this for you, however this isn't a bug. The rules engine will decide when a rule needs to be created based on the factors used within the transaction. If you just create one transaction for say Grocery and select the merchant and value a rule won't be created because you would end up with rules for every single thing. I am not sure if you will get your PR merged into main if it create a rule for every single transaction added, but I will leave this open for James to review when the time comes.

GiteaMirror commented

2026-02-28 18:49:27 -06:00

@winklevos commented on GitHub (Aug 22, 2022):

would end up with rules for every single thing.

This is the exact user experience I expect and is standard in budgeting apps. Ultimately a user should not have to manually categorise as much as possible.

If creating a rule for each payee is going to be a problem we might need to change some things.

I see the functionality like so

Categorising a transaction should then categorise any future transactions with a matching payee
You can optionally choose to only apply it to the single transaction
You can apply it historically to all transactions, and future transactions.

I've imported 10,000 transactions into actual, the user experience currently will result in me not being able to use it.

I hope this feature can be considered beneficial for actual

@winklevos commented on GitHub (Aug 22, 2022): > would end up with rules for every single thing. This is the exact user experience I expect and is standard in budgeting apps. Ultimately a user should not have to manually categorise as much as possible. If creating a rule for each payee is going to be a problem we might need to change some things. I see the functionality like so 1. Categorising a transaction should then categorise any future transactions with a matching payee 2. You can optionally choose to only apply it to the single transaction 3. You can apply it historically to all transactions, and future transactions. I've imported 10,000 transactions into actual, the user experience currently will result in me not being able to use it. I hope this feature can be considered beneficial for actual

GiteaMirror commented

2026-02-28 18:49:27 -06:00

@winklevos commented on GitHub (Aug 23, 2022):

For note, the current logic is in https://github.com/winklevos/actual/blob/categorise-rules/packages/loot-core/src/server/accounts/transaction-rules.js#L614

Goes as follows

When the category is changed actual will look back 6 months, and forward 180 days. And get all related transactions for that payee.

It will only continue if you modified the latest transactions.

It will then count the number of occurrences of that category for the payee.

It selects the category with the majority (max). And only updates if it has > 3 occurrences.

Think

SELECT category, count(*) 
FROM transactions 
WHERE payee = 1 
GROUP BY 
category 
HAVING count(*) > 3 
ORDER BY count(*) desc 
LIMIT 1

This to me is a bit overbuilt, see my previous three points for UX

@winklevos commented on GitHub (Aug 23, 2022): For note, the current logic is in https://github.com/winklevos/actual/blob/categorise-rules/packages/loot-core/src/server/accounts/transaction-rules.js#L614 Goes as follows When the category is changed actual will look back 6 months, and forward 180 days. And get all related transactions for that payee. It will only continue if you modified the latest transactions. It will then count the number of occurrences of that category for the payee. It selects the category with the majority (max). And only updates if it has > 3 occurrences. Think ``` SELECT category, count(*) FROM transactions WHERE payee = 1 GROUP BY category HAVING count(*) > 3 ORDER BY count(*) desc LIMIT 1 ``` This to me is a bit overbuilt, see my previous three points for UX

GiteaMirror commented

2026-02-28 18:49:28 -06:00

@rich-howell commented on GitHub (Sep 7, 2022):

As this isn't a bug I am going to move it over to ideas for further discussion.

@rich-howell commented on GitHub (Sep 7, 2022): As this isn't a bug I am going to move it over to ideas for further discussion.