github-starred/actual
2
0
Fork 0
mirror of https://github.com/actualbudget/actual.git synced 2026-03-09 03:32:54 -05:00
Code Issues 250 Packages Projects Releases 53 Wiki Activity

[Bug]: Can't merge duplicate transactions when one is a transfer, and/or doesn't automatically match up transfers made from rules #2079

New Issue
Closed
opened 2026-02-28 20:02:48 -06:00 by GiteaMirror · 7 comments
GiteaMirror commented 2026-02-28 20:02:48 -06:00
Owner
Copy Link

Originally created by @Sarke on GitHub (Apr 30, 2025).

Verified issue does not already exist?

  • I have searched and found no existing issue

What happened?

Image

I set up a rule in one account to mark certain transactions as transfers to another account. This created a corresponding transaction in the other account, even though there was already a matching transaction in that account with the same amount and date.

How can we reproduce the issue?

  1. Import transactions in both accounts.
  2. Set up rule to mark certain transactions as transfers to second account.
  3. Profit?

Where are you hosting Actual?

Docker

What browsers are you seeing the problem on?

Firefox

Operating System

Linux

Originally created by @Sarke on GitHub (Apr 30, 2025). ### Verified issue does not already exist? - [x] I have searched and found no existing issue ### What happened? ![Image](https://github.com/user-attachments/assets/966f08db-de8f-471b-b324-c7021e7970c5) I set up a rule in one account to mark certain transactions as transfers to another account. This created a corresponding transaction in the other account, even though there was already a matching transaction in that account with the same amount and date. ### How can we reproduce the issue? 1. Import transactions in both accounts. 2. Set up rule to mark certain transactions as transfers to second account. 3. Profit? ### Where are you hosting Actual? Docker ### What browsers are you seeing the problem on? Firefox ### Operating System Linux
GiteaMirror added the transactionsbug labels 2026-02-28 20:02:48 -06:00
GiteaMirror commented 2026-02-28 20:02:49 -06:00
Author
Owner
Copy Link

@Sarke commented on GitHub (Apr 30, 2025):

Well, the real issue is that when I create a rule like this, it doesn't match up the transactions as a transfer. It just creates a duplicate transactions in the receiving account.

Image

@Sarke commented on GitHub (Apr 30, 2025): Well, the _real_ issue is that when I create a rule like this, it doesn't match up the transactions as a transfer. It just creates a duplicate transactions in the receiving account. ![Image](https://github.com/user-attachments/assets/44cce6c1-7ee7-4892-a84d-00aaff5e1067)
GiteaMirror commented 2026-02-28 20:02:49 -06:00
Author
Owner
Copy Link

@youngcw commented on GitHub (Apr 30, 2025):

Do you have a rule for each account? The transfer needs created on both sides or the two transactions look different to Actual and they won't be deduplicated.

@youngcw commented on GitHub (Apr 30, 2025): Do you have a rule for each account? The transfer needs created on both sides or the two transactions look different to Actual and they won't be deduplicated.
GiteaMirror commented 2026-02-28 20:02:50 -06:00
Author
Owner
Copy Link

@Sarke commented on GitHub (May 1, 2025):

No, I only have a rule in the sending account. A rule for the receiving account would be too ambiguous.

@Sarke commented on GitHub (May 1, 2025): No, I only have a rule in the sending account. A rule for the receiving account would be too ambiguous.
GiteaMirror commented 2026-02-28 20:02:50 -06:00
Author
Owner
Copy Link

@alecbakholdin commented on GitHub (May 3, 2025):

@Sarke I think what you're asking for goes against the fundamental principle behind rules. At least the way I see it, they are a pure function without side effects. You put a transaction in, you get the same transaction or that transaction plus its newly spawned children. Adding this functionality introduces side effects, which is

  1. not a trivial change
  2. a slippery slope. Side effects are difficult and once we add one it introduces more and more complexity.

I hate to ask this, but I would really advise going down the route @youngcw proposed and making another rule, or make use of the new "merge" manual action.

I would say, this is more of a feature request and not a bug report.

@alecbakholdin commented on GitHub (May 3, 2025): @Sarke I think what you're asking for goes against the fundamental principle behind rules. At least the way I see it, they are a pure function without side effects. You put a transaction in, you get the same transaction or that transaction plus its newly spawned children. Adding this functionality introduces side effects, which is 1. not a trivial change 2. a slippery slope. Side effects are difficult and once we add one it introduces more and more complexity. I hate to ask this, but I would really advise going down the route @youngcw proposed and making another rule, or make use of the new "merge" manual action. I would say, this is more of a feature request and not a bug report.
GiteaMirror commented 2026-02-28 20:02:50 -06:00
Author
Owner
Copy Link

@cesjn commented on GitHub (May 15, 2025):

I have been an Actual user for several months now and was really excited for the new Merge feature that came out in the latest release. In theory it should address this problem, but the current implementation seems to fall short. I have a similar situation where a transfer is made between two accounts but the transaction is duplicated in the receiving account. So I end up with the following three transactions:

  1. Account A, $20 Payment, categorized as Transfer, matched to SimpleLink Import and marked as cleared
  2. Account B, $20 Credit, categorized as Transfer, unmatched and not cleared (appears to result from a rule that Actual automatically created for me)
  3. Account B, $20 Credit, Not Categorized, matched to import and marked as cleared

Before the merge function was introduced I would change the category of transaction #1 to something else, delete transaction #2 and then use the "make transfer" function to link #1 and #3 together, thus categorizing them both as a transfer (Actual then wants me to make a rule for this, which I try to always decline in order to avoid the same situation the next month when these transactions occur again).

With the merge function I had the expectation that I should simply be able to "Merge" transactions #2 and #3 and we should be good to go. Unfortunately, when I do so, the resulting transaction is NOT categorized as a transfer, but #1 stays as a transfer. This results in me being unable to link #1 and the #2/3 merge.

So, I would propose that there is a Bug here, specifically in the new merge feature. I.e. that if you merge a "transfer" transaction with another transaction, that the resulting merged transaction should maintain the "transfer" category. The alternative would be to unlink the transaction linked to the transfer transaction (set it back to uncategorized) so that you can re-link the resulting transaction, but that seems far more complicated.

@cesjn commented on GitHub (May 15, 2025): I have been an Actual user for several months now and was really excited for the new Merge feature that came out in the latest release. In theory it should address this problem, but the current implementation seems to fall short. I have a similar situation where a transfer is made between two accounts but the transaction is duplicated in the receiving account. So I end up with the following three transactions: 1. Account A, $20 Payment, categorized as Transfer, matched to SimpleLink Import and marked as cleared 2. Account B, $20 Credit, categorized as Transfer, unmatched and not cleared (appears to result from a rule that Actual automatically created for me) 3. Account B, $20 Credit, Not Categorized, matched to import and marked as cleared Before the merge function was introduced I would change the category of transaction #1 to something else, delete transaction #2 and then use the "make transfer" function to link #1 and #3 together, thus categorizing them both as a transfer (Actual then wants me to make a rule for this, which I try to always decline in order to avoid the same situation the next month when these transactions occur again). With the merge function I had the expectation that I should simply be able to "Merge" transactions #2 and #3 and we should be good to go. Unfortunately, when I do so, the resulting transaction is NOT categorized as a transfer, but #1 stays as a transfer. This results in me being unable to link #1 and the #2/3 merge. So, I would propose that there is a Bug here, specifically in the new merge feature. I.e. that if you merge a "transfer" transaction with another transaction, that the resulting merged transaction should maintain the "transfer" category. The alternative would be to unlink the transaction linked to the transfer transaction (set it back to uncategorized) so that you can re-link the resulting transaction, but that seems far more complicated.
GiteaMirror commented 2026-02-28 20:02:50 -06:00
Author
Owner
Copy Link

@alecbakholdin commented on GitHub (May 15, 2025):

@cesjn you're correct I completely forgot about transfers during merge implementation. I'll fix that.

@alecbakholdin commented on GitHub (May 15, 2025): @cesjn you're correct I completely forgot about transfers during merge implementation. I'll fix that.
GiteaMirror commented 2026-02-28 20:02:51 -06:00
Author
Owner
Copy Link

@youngcw commented on GitHub (Jun 7, 2025):

since #5000 is a more thorough right up of the issue, Ill close this one as a duplicate now.

@youngcw commented on GitHub (Jun 7, 2025): since #5000 is a more thorough right up of the issue, Ill close this one as a duplicate now.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
AI generated
API
bank sync
budgeting
bug
can’t replicate
dependencies
docker
documentation
electron
experimental feature
feature
feedback
goal templates
good first issue
help wanted
importers
maintenance
needs info
needs testing
needs triage
needs votes
openid
payees
pull-request
Mirrored from GitHub Pull Request
 regression
reports
responsive
rules
schedules
server
✨ merged
split transactions
tech debt
theme
transaction import
transaction reconciliation
transactions
translations
upstream
user interface
✅ approved
wontfix
No Label bug transactions
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/actual#2079
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?