[GH-ISSUE #669] [Feature] Merge unmatched transactions #49395

New Issue

Closed

opened 2026-04-30 10:45:57 -05:00 by GiteaMirror · 20 comments

GiteaMirror commented 2026-04-30 10:45:57 -05:00

Owner

Copy Link

Originally created by @lanmaster53 on GitHub (Feb 19, 2023).
Original GitHub issue: https://github.com/actualbudget/actual/issues/669

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?

When Actual fails to recognize a transaction as a match, it doesn't provide a way to gracefully merge the transactions. This is a workflow that I encounter very often and is a show-stopper for me as someone that wants to transition to Actual on a permanent basis.

Describe your ideal solution to this problem

When 2 transactions are selected, there should be an option in the actions menu to merge the transactions so that the manual entry is updated with the date from the imported version. Manually updating one of the entries and deleting the other is an unnecessary and cumbersome process for something so simple. All other budgeting software I've used have had this feature.

Teaching and learning

It was intuitive for me to look for that functionality in the actions menu when I had 2 transactions selected. I was quite surprised that the feature didn't exists because it is such a common workflow. Other than add a blurb in the importing section about merging, I don't think much else would be needed. It's an intuitive feature.

Originally created by @lanmaster53 on GitHub (Feb 19, 2023). Original GitHub issue: https://github.com/actualbudget/actual/issues/669 ### Verified feature request does not already exist? - [X] I have searched and found no existing issue ### 💻 - [ ] Would you like to implement this feature? ### Pitch: what problem are you trying to solve? When Actual fails to recognize a transaction as a match, it doesn't provide a way to gracefully merge the transactions. This is a workflow that I encounter very often and is a show-stopper for me as someone that wants to transition to Actual on a permanent basis. ### Describe your ideal solution to this problem When 2 transactions are selected, there should be an option in the actions menu to merge the transactions so that the manual entry is updated with the date from the imported version. Manually updating one of the entries and deleting the other is an unnecessary and cumbersome process for something so simple. All other budgeting software I've used have had this feature. ### Teaching and learning It was intuitive for me to look for that functionality in the actions menu when I had 2 transactions selected. I was quite surprised that the feature didn't exists because it is such a common workflow. Other than add a blurb in the importing section about merging, I don't think much else would be needed. It's an intuitive feature.

GiteaMirror added the feature label 2026-04-30 10:45:57 -05:00

GiteaMirror closed this issue 2026-04-30 10:45:57 -05:00

GiteaMirror commented 2026-04-30 10:45:58 -05:00

Author

Owner

Copy Link

@j-f1 commented on GitHub (Feb 19, 2023):

The logic for matching an existing transaction with an updated one is here:

cb0ae2d39a/packages/loot-core/src/server/accounts/sync.js (L236-L331)

It currently looks 1 day after the imported transaction date and 4 days before. Then, it merges any matched transactions using this logic. (existing is the existing transaction, trans is the proposed imported transaction)

cb0ae2d39a/packages/loot-core/src/server/accounts/sync.js (L344-L352)

While it definitely makes sense to allow running this logic directly somehow, I worry about the way the merge action as currently implemented is non-symmetric and there currently isn’t a concept of “selection order” in Actual as far as I know. Maybe we could interpret the newer one as the freshly imported one? Or only enable the action when you select one “new” (bolded) transaction and one non-“new” transaction? I want to make sure that when we implement this feature it doesn’t end up being confusing.

<!-- gh-comment-id:1436112157 --> @j-f1 commented on GitHub (Feb 19, 2023): The logic for matching an existing transaction with an updated one is here: https://github.com/actualbudget/actual/blob/cb0ae2d39afc8cc91ec5dfe700bbb11c372a7bff/packages/loot-core/src/server/accounts/sync.js#L236-L331 It currently looks 1 day after the imported transaction date and 4 days before. Then, it merges any matched transactions using this logic. (`existing` is the existing transaction, `trans` is the proposed imported transaction) https://github.com/actualbudget/actual/blob/cb0ae2d39afc8cc91ec5dfe700bbb11c372a7bff/packages/loot-core/src/server/accounts/sync.js#L344-L352 While it definitely makes sense to allow running this logic directly somehow, I worry about the way the merge action as currently implemented is non-symmetric and there currently isn’t a concept of “selection order” in Actual as far as I know. Maybe we could interpret the newer one as the freshly imported one? Or only enable the action when you select one “new” (bolded) transaction and one non-“new” transaction? I want to make sure that when we implement this feature it doesn’t end up being confusing.

GiteaMirror commented 2026-04-30 10:45:59 -05:00

Author

Owner

Copy Link

@lanmaster53 commented on GitHub (Feb 20, 2023):

A couple thoughts.

I don't think I would only show the option based on the condition of "new" and "old". There are too many scenarios where both transactions could end up being seen as "old", and tying functionality to an unstable condition like that seems fragile. The option should show up ANY time amounts match. It's not like enabling the option forces people to use it. It's okay if it's in the menu even when the user doesn't intend to use it for the selection. Restricting it too much will likely just result in someone with an edge case asking you to change it later. It's better to put the power in the users' hands.

I do think the current match window is too small, especially when dealing with checks. It's not unreasonable for someone to wait until they "get around to it" to go to the bank. Plus, mail is unpredictable, etc. Expanding that helps a little, but doesn't solve the problem.

Existing transactions should be the source of truth for metadata because they are most likely manual entry. Imports should be the source of truth for the date because it is actual from the financial institution. This is how YNAB and others do it. If that doesn't provide the desired effect, then it is very easy to undo and manually edit, but I believe this will handle the vast majority of use cases.

<!-- gh-comment-id:1437233462 --> @lanmaster53 commented on GitHub (Feb 20, 2023): A couple thoughts. I don't think I would only show the option based on the condition of "new" and "old". There are too many scenarios where both transactions could end up being seen as "old", and tying functionality to an unstable condition like that seems fragile. The option should show up ANY time amounts match. It's not like enabling the option forces people to use it. It's okay if it's in the menu even when the user doesn't intend to use it for the selection. Restricting it too much will likely just result in someone with an edge case asking you to change it later. It's better to put the power in the users' hands. I do think the current match window is too small, especially when dealing with checks. It's not unreasonable for someone to wait until they "get around to it" to go to the bank. Plus, mail is unpredictable, etc. Expanding that helps a little, but doesn't solve the problem. Existing transactions should be the source of truth for metadata because they are most likely manual entry. Imports should be the source of truth for the date because it is actual from the financial institution. This is how YNAB and others do it. If that doesn't provide the desired effect, then it is very easy to undo and manually edit, but I believe this will handle the vast majority of use cases.

GiteaMirror commented 2026-04-30 10:45:59 -05:00

Author

Owner

Copy Link

@j-f1 commented on GitHub (Feb 20, 2023):

It's okay if it's in the menu even when the user doesn't intend to use it for the selection. Restricting it too much will likely just result in someone with an edge case asking you to change it later. It's better to put the power in the users' hands.

Agreed, that makes sense! I do think we should limit to when exactly 2 transactions are selected though.

Existing transactions should be the source of truth for metadata because they are most likely manual entry. Imports should be the source of truth for the date because it is actual from the financial institution.

I agree! and this is the question: how do you know which transaction is the one that was imported? One way would be checking if one transaction has an imported payee name and the other doesn’t but how could handle cases where both or neither have an imported payee name?

I do think the current match window is too small, especially when dealing with checks. It's not unreasonable for someone to wait until they "get around to it" to go to the bank. Plus, mail is unpredictable, etc. Expanding that helps a little, but doesn't solve the problem.

I wonder if we could continentally expand the match window, since the current matching uses 3 different algorithms, with the final one being just “does the amount and account match?” Maybe we could expand the window for amount+account+payee matches but keep the others as-is? I am worried that if someone has e.g. a weekly subscription, we could accidentally merge separate transactions, though.

<!-- gh-comment-id:1437271043 --> @j-f1 commented on GitHub (Feb 20, 2023): > It's okay if it's in the menu even when the user doesn't intend to use it for the selection. Restricting it too much will likely just result in someone with an edge case asking you to change it later. It's better to put the power in the users' hands. Agreed, that makes sense! I do think we should limit to when exactly 2 transactions are selected though. > Existing transactions should be the source of truth for metadata because they are most likely manual entry. Imports should be the source of truth for the date because it is actual from the financial institution. I agree! and this is the question: how do you know which transaction is the one that was imported? One way would be checking if one transaction has an imported payee name and the other doesn’t but how could handle cases where both or neither have an imported payee name? > I do think the current match window is too small, especially when dealing with checks. It's not unreasonable for someone to wait until they "get around to it" to go to the bank. Plus, mail is unpredictable, etc. Expanding that helps a little, but doesn't solve the problem. I wonder if we could continentally expand the match window, since the current matching uses 3 different algorithms, with the final one being just “does the amount and account match?” Maybe we could expand the window for amount+account+payee matches but keep the others as-is? I am worried that if someone has e.g. a weekly subscription, we could accidentally merge separate transactions, though.

GiteaMirror commented 2026-04-30 10:46:00 -05:00

Author

Owner

Copy Link

@lanmaster53 commented on GitHub (Feb 20, 2023):

I agree! and this is the question: how do you know which transaction is the one that was imported? One way would be checking if one transaction has an imported payee name and the other doesn’t but how could handle cases where both or neither have an imported payee name?

Why not do it by date? Won't the oldest transaction always be the manual entry, and the newest always be the import? I can't think of a reason that I would manually enter a transaction after it had already been imported and then merge them. If I wanted to update a transaction that had already been imported, then I would just edit the existing imported record. No need for a merge. Therefore, logically, the imported transaction should always be the more recent, unless I'm missing a use case.

I wonder if we could continentally expand the match window, since the current matching uses 3 different algorithms, with the final one being just “does the amount and account match?” Maybe we could expand the window for amount+account+payee matches but keep the others as-is? I am worried that if someone has e.g. a weekly subscription, we could accidentally merge separate transactions, though.

I think what I've seen elsewhere is that the time window is much larger, and rather than auto-merge, the interface shows a potential match and the user determines whether or not to merge them or leave them separate.

<!-- gh-comment-id:1437299767 --> @lanmaster53 commented on GitHub (Feb 20, 2023): > I agree! and this is the question: how do you know which transaction is the one that was imported? One way would be checking if one transaction has an imported payee name and the other doesn’t but how could handle cases where both or neither have an imported payee name? Why not do it by date? Won't the oldest transaction always be the manual entry, and the newest always be the import? I can't think of a reason that I would manually enter a transaction after it had already been imported and then merge them. If I wanted to update a transaction that had already been imported, then I would just edit the existing imported record. No need for a merge. Therefore, logically, the imported transaction should always be the more recent, unless I'm missing a use case. > I wonder if we could continentally expand the match window, since the current matching uses 3 different algorithms, with the final one being just “does the amount and account match?” Maybe we could expand the window for amount+account+payee matches but keep the others as-is? I am worried that if someone has e.g. a weekly subscription, we could accidentally merge separate transactions, though. I think what I've seen elsewhere is that the time window is much larger, and rather than auto-merge, the interface shows a potential match and the user determines whether or not to merge them or leave them separate.

GiteaMirror commented 2026-04-30 10:46:01 -05:00

Author

Owner

Copy Link

@j-f1 commented on GitHub (Feb 20, 2023):

Therefore, logically, the imported transaction should always be the more recent, unless I'm missing a use case.

One case where this would not be true is if you manually add a transaction on eg Feb 10th, but the bank records it on Feb 9th. If you import on Feb 20th, you would want to merge the newer transaction into the older one, I think.

That said, we could do a 2-step algorithm: if one transaction was just imported and the other one wasn’t, then update the transaction that was just imported. Otherwise, update the newest transaction. People can always undo the change and manually perform the merge if it doesn’t work correctly.

<!-- gh-comment-id:1437313532 --> @j-f1 commented on GitHub (Feb 20, 2023): > Therefore, logically, the imported transaction should always be the more recent, unless I'm missing a use case. One case where this would not be true is if you manually add a transaction on eg Feb 10th, but the bank records it on Feb 9th. If you import on Feb 20th, you would want to merge the newer transaction into the older one, I think. That said, we could do a 2-step algorithm: if one transaction was just imported and the other one wasn’t, then update the transaction that was just imported. Otherwise, update the newest transaction. People can always undo the change and manually perform the merge if it doesn’t work correctly.

GiteaMirror commented 2026-04-30 10:46:02 -05:00

Author

Owner

Copy Link

@j-f1 commented on GitHub (Feb 20, 2023):

I think what I've seen elsewhere is that the time window is much larger, and rather than auto-merge, the interface shows a potential match and the user determines whether or not to merge them or leave them separate.

At least in my use case, I generally get a file with the 50 most recent transactions, which tends to have considerable overlap with the transactions already in my account, so manually approving merges would not be a good experience (although maybe we could only prompt for lower-confidence matches?). That would still introduce another interstitial modal which I’m not a huge fan of, though.

<!-- gh-comment-id:1437316472 --> @j-f1 commented on GitHub (Feb 20, 2023): > I think what I've seen elsewhere is that the time window is much larger, and rather than auto-merge, the interface shows a potential match and the user determines whether or not to merge them or leave them separate. At least in my use case, I generally get a file with the 50 most recent transactions, which tends to have considerable overlap with the transactions already in my account, so manually approving merges would not be a good experience (although maybe we could only prompt for lower-confidence matches?). That would still introduce another interstitial modal which I’m not a huge fan of, though.

GiteaMirror commented 2026-04-30 10:46:04 -05:00

Author

Owner

Copy Link

@CHAMLEX commented on GitHub (Feb 20, 2023):

I think what I've seen elsewhere is that the time window is much larger, and rather than auto-merge, the interface shows a potential match and the user determines whether or not to merge them or leave them separate.

At least in my use case, I generally get a file with the 50 most recent transactions, which tends to have considerable overlap with the transactions already in my account, so manually approving merges would not be a good experience (although maybe we could only prompt for lower-confidence matches?). That would still introduce another interstitial modal which I’m not a huge fan of, though.

Maybe having an option to either auto match or manually match? I do agree the last two things keeping me from using this full time is mobile entry (which is being worked on now) and a way to merge transactions when I import my bank statements so they don't get imported again.

<!-- gh-comment-id:1437323356 --> @CHAMLEX commented on GitHub (Feb 20, 2023): > > I think what I've seen elsewhere is that the time window is much larger, and rather than auto-merge, the interface shows a potential match and the user determines whether or not to merge them or leave them separate. > > > > At least in my use case, I generally get a file with the 50 most recent transactions, which tends to have considerable overlap with the transactions already in my account, so manually approving merges would not be a good experience (although maybe we could only prompt for lower-confidence matches?). That would still introduce another interstitial modal which I’m not a huge fan of, though. Maybe having an option to either auto match or manually match? I do agree the last two things keeping me from using this full time is mobile entry (which is being worked on now) and a way to merge transactions when I import my bank statements so they don't get imported again.

GiteaMirror commented 2026-04-30 10:46:05 -05:00

Author

Owner

Copy Link

@lanmaster53 commented on GitHub (Feb 20, 2023):

I think what I've seen elsewhere is that the time window is much larger, and rather than auto-merge, the interface shows a potential match and the user determines whether or not to merge them or leave them separate.

At least in my use case, I generally get a file with the 50 most recent transactions, which tends to have considerable overlap with the transactions already in my account, so manually approving merges would not be a good experience (although maybe we could only prompt for lower-confidence matches?). That would still introduce another interstitial modal which I’m not a huge fan of, though.

Very true. Any matches that include a transaction that is already reconciled should be merged without prompt. Does that make sense?

<!-- gh-comment-id:1437332298 --> @lanmaster53 commented on GitHub (Feb 20, 2023): > > I think what I've seen elsewhere is that the time window is much larger, and rather than auto-merge, the interface shows a potential match and the user determines whether or not to merge them or leave them separate. > > At least in my use case, I generally get a file with the 50 most recent transactions, which tends to have considerable overlap with the transactions already in my account, so manually approving merges would not be a good experience (although maybe we could only prompt for lower-confidence matches?). That would still introduce another interstitial modal which I’m not a huge fan of, though. Very true. Any matches that include a transaction that is already reconciled should be merged without prompt. Does that make sense?

GiteaMirror commented 2026-04-30 10:46:06 -05:00

Author

Owner

Copy Link

@github-actions[bot] commented on GitHub (May 1, 2023):

✨ Thanks for sharing your idea! ✨

This repository is now using lodash style issue management for enhancements. This means enhancement issues will now be closed instead of leaving them open. 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=is%3Aissue+label%3A%22needs+votes%22+sort%3Areactions-%2B1-desc

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

<!-- gh-comment-id:1530115811 --> @github-actions[bot] commented on GitHub (May 1, 2023): :sparkles: Thanks for sharing your idea! :sparkles: This repository is now using lodash style issue management for enhancements. This means enhancement issues will now be closed instead of leaving them open. 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=is%3Aissue+label%3A%22needs+votes%22+sort%3Areactions-%2B1-desc Don’t forget to upvote the top comment with 👍!

GiteaMirror commented 2026-04-30 10:46:07 -05:00

Author

Owner

Copy Link

@yoyotogblo commented on GitHub (Dec 29, 2023):

Therefore, logically, the imported transaction should always be the more recent, unless I'm missing a use case.

One case where this would not be true is if you manually add a transaction on eg Feb 10th, but the bank records it on Feb 9th. If you import on Feb 20th, you would want to merge the newer transaction into the older one, I think.

That said, we could do a 2-step algorithm: if one transaction was just imported and the other one wasn’t, then update the transaction that was just imported. Otherwise, update the newest transaction. People can always undo the change and manually perform the merge if it doesn’t work correctly.

@j-f1 Just weighing in on this...

YNAB explains what they do for the most part here:
https://support.ynab.com/en_us/approving-and-matching-transactions-a-guide-ByYNZaQ1i#:~:text=When%20you%20enter%20a%20transaction,10%20days%20of%20each%20other.

YNAB 4 and 5 use a 10 day window before and 10 day window after the imported transaction date to find potential matches. They both use the manually entered transaction as the truth for date, payee and category (same behavior as in YNAB 4). Also, both YNAB 4 and YNAB 5 use the imported transaction as the truth for amount if manually matching.

When 2 transactions are matched, YNAB4 (and YNAB5) requires the user to either approve the match, delete both transactions, or unmatch the 2 transactions. So action is always needed on the user's side. It's worth noting that newly importing previous transactions don't require matching since those have already been confirmed (so if the import ID matches, no need to approve or disapprove the match).

Screenshot of matched transactions:

Here's a screenshot of how the approval of a match looks:

On a sidenote, in YNAB 4, all newly imported transactions (OFX, CSV etc) need to be approved. I much prefer this to Actual just importing and categorizing and losing visibility and control of what was imported.

Transfers and matches:

• If an account A has a manually entered transfer to account B already in YNAB 4, and then transactions are imported into account A, it works the exact same as above. The manually entered transaction is the source of truth and a match dialog is presented to approve, disapprove or delete both transactions.

• If an account A has an imported transfer to account B already in YNAB 4, and then transactions are imported into account B, the earlier imported transfer into account B (from account A) is used as the source of truth.
  

Manual matches:

• When manually matching, similar to auto matching, YNAB always use the manually entered transaction as the source of truth for the date, payees and category. This is still the case even if the manually entered transaction was entered into YNAB after the imported transaction. However, it uses the imported transaction as the source of truth for the amount (if manually matching 2 transactions with different amounts). To do this, YNAB keeps track of which transactions were imported or manually entered. I imagine Actual can do this with import IDs.

• Even manually matched orders still require approval. Same dialog box as before.

• If manually matching 2 manually entered transactions, I believe YNAB uses the most recently entered transaction as the source of truth for the date, payee and category and uses the older transaction as the source of truth for the amount. The transaction still needs to be approved as usual. However, I'd say using the most recently entered transaction as the source of truth for everything (including the amount) probably makes more sense here.

2 transactions entered

Transaction entered 2nd is always the source of truth for date, payees and categories regardless of transaction date

• Also, there's no window to manually match 2 transactions (so they could be a year apart) if you want.

Hope knowing how YNAB behaves helps. I personally think they have the correct logic figured out and if we can replicate it in Actual, that'd be awesome!

<!-- gh-comment-id:1872021828 --> @yoyotogblo commented on GitHub (Dec 29, 2023): > > Therefore, logically, the imported transaction should always be the more recent, unless I'm missing a use case. > > One case where this would not be true is if you manually add a transaction on eg Feb 10th, but the bank records it on Feb 9th. If you import on Feb 20th, you would want to merge the newer transaction into the older one, I think. > > That said, we could do a 2-step algorithm: if one transaction was just imported and the other one wasn’t, then update the transaction that was just imported. Otherwise, update the newest transaction. People can always undo the change and manually perform the merge if it doesn’t work correctly. @j-f1 Just weighing in on this... YNAB explains what they do for the most part here: https://support.ynab.com/en_us/approving-and-matching-transactions-a-guide-ByYNZaQ1i#:~:text=When%20you%20enter%20a%20transaction,10%20days%20of%20each%20other. YNAB 4 and 5 use a 10 day window before and 10 day window after the imported transaction date to find potential matches. They both use the manually entered transaction as the truth for date, payee and category (same behavior as in YNAB 4). Also, both YNAB 4 and YNAB 5 use the imported transaction as the truth for amount if manually matching. When 2 transactions are matched, YNAB4 (and YNAB5) requires the user to either approve the match, delete both transactions, or unmatch the 2 transactions. So action is always needed on the user's side. It's worth noting that newly importing previous transactions don't require matching since those have already been confirmed (so if the import ID matches, no need to approve or disapprove the match). Screenshot of matched transactions:  Here's a screenshot of how the approval of a match looks:  On a sidenote, in YNAB 4, all newly imported transactions (OFX, CSV etc) need to be approved. I much prefer this to Actual just importing and categorizing and losing visibility and control of what was imported.  Transfers and matches: - If an account A has a manually entered transfer to account B already in YNAB 4, and then transactions are imported into account A, it works the exact same as above. The manually entered transaction is the source of truth and a match dialog is presented to approve, disapprove or delete both transactions. - If an account A has an imported transfer to account B already in YNAB 4, and then transactions are imported into account B, the earlier imported transfer into account B (from account A) is used as the source of truth.  Manual matches: - When manually matching, similar to auto matching, YNAB always use the manually entered transaction as the source of truth for the date, payees and category. This is still the case even if the manually entered transaction was entered into YNAB after the imported transaction. However, it uses the imported transaction as the source of truth for the amount (if manually matching 2 transactions with different amounts). To do this, YNAB keeps track of which transactions were imported or manually entered. I imagine Actual can do this with import IDs. - Even manually matched orders still require approval. Same dialog box as before. - If manually matching 2 manually entered transactions, I believe YNAB uses the most recently entered transaction as the source of truth for the date, payee and category and uses the older transaction as the source of truth for the amount. The transaction still needs to be approved as usual. However, I'd say using the most recently entered transaction as the source of truth for everything (including the amount) probably makes more sense here. 2 transactions entered   Transaction entered 2nd is always the source of truth for date, payees and categories regardless of transaction date   - Also, there's no window to manually match 2 transactions (so they could be a year apart) if you want. Hope knowing how YNAB behaves helps. I personally think they have the correct logic figured out and if we can replicate it in Actual, that'd be awesome!

GiteaMirror commented 2026-04-30 10:46:07 -05:00

Author

Owner

Copy Link

@yoyotogblo commented on GitHub (May 8, 2024):

I was getting excited that someone might have completed this only to come here and see the completely different issue this was closed for. Please reopen this. I use the transfers and it's solves none of the issues listed in this feature request

<!-- gh-comment-id:2101497159 --> @yoyotogblo commented on GitHub (May 8, 2024): I was getting excited that someone might have completed this only to come here and see the completely different issue this was closed for. Please reopen this. I use the transfers and it's solves none of the issues listed in this feature request

GiteaMirror commented 2026-04-30 10:46:08 -05:00

Author

Owner

Copy Link

@lanmaster53 commented on GitHub (May 8, 2024):

Why was my comment deleted? As the OP, I was seeking clarification for why the issue was closed.

<!-- gh-comment-id:2101505296 --> @lanmaster53 commented on GitHub (May 8, 2024): Why was my comment deleted? As the OP, I was seeking clarification for why the issue was closed.

GiteaMirror commented 2026-04-30 10:46:09 -05:00

Author

Owner

Copy Link

@youngcw commented on GitHub (May 8, 2024):

Seems like it was a misunderstanding of the request. To be fair I also misunderstood the request originally too and thought that it was exactly what that PR did. Upon better reading, you are correct that this is a different feature than that PR adds. The feature is open again

<!-- gh-comment-id:2101508665 --> @youngcw commented on GitHub (May 8, 2024): Seems like it was a misunderstanding of the request. To be fair I also misunderstood the request originally too and thought that it was exactly what that PR did. Upon better reading, you are correct that this is a different feature than that PR adds. The feature is open again

GiteaMirror commented 2026-04-30 10:46:10 -05:00

Author

Owner

Copy Link

@carkom commented on GitHub (May 8, 2024):

Why was my comment deleted? As the OP, I was seeking clarification for why the issue was closed.

Thanks @youngcw. Yes I misunderstood the PR. I thought by reseting my mistake and re-opening the issue it would be understood that I incorrectly marked the request. @lanmaster53, I hope you now have the clarification you so desire. My apologies for the mistake.

<!-- gh-comment-id:2101598967 --> @carkom commented on GitHub (May 8, 2024): > Why was my comment deleted? As the OP, I was seeking clarification for why the issue was closed. Thanks @youngcw. Yes I misunderstood the PR. I thought by reseting my mistake and re-opening the issue it would be understood that I incorrectly marked the request. @lanmaster53, I hope you now have the clarification you so desire. My apologies for the mistake.

GiteaMirror commented 2026-04-30 10:46:11 -05:00

Author

Owner

Copy Link

@lanmaster53 commented on GitHub (May 9, 2024):

Why was my comment deleted? As the OP, I was seeking clarification for why the issue was closed.

Thanks @youngcw. Yes I misunderstood the PR. I thought by reseting my mistake and re-opening the issue it would be understood that I incorrectly marked the request. @lanmaster53, I hope you now have the clarification you so desire. My apologies for the mistake.

It is still showing as closed for me.

<!-- gh-comment-id:2101936943 --> @lanmaster53 commented on GitHub (May 9, 2024): > > Why was my comment deleted? As the OP, I was seeking clarification for why the issue was closed. > > Thanks @youngcw. Yes I misunderstood the PR. I thought by reseting my mistake and re-opening the issue it would be understood that I incorrectly marked the request. @lanmaster53, I hope you now have the clarification you so desire. My apologies for the mistake. It is still showing as closed for me.

GiteaMirror commented 2026-04-30 10:46:11 -05:00

Author

Owner

Copy Link

@carkom commented on GitHub (May 9, 2024):

Why was my comment deleted? As the OP, I was seeking clarification for why the issue was closed.

Thanks @youngcw. Yes I misunderstood the PR. I thought by reseting my mistake and re-opening the issue it would be understood that I incorrectly marked the request. @lanmaster53, I hope you now have the clarification you so desire. My apologies for the mistake.

It is still showing as closed for me.

Yes, it's been closed for months. If you look at the history you'll see I didn't change the open status. All feature requests are kept as closed in this repo. We use labels to mark them as complete or not.

<!-- gh-comment-id:2102007839 --> @carkom commented on GitHub (May 9, 2024): > > > Why was my comment deleted? As the OP, I was seeking clarification for why the issue was closed. > > > > Thanks @youngcw. Yes I misunderstood the PR. I thought by reseting my mistake and re-opening the issue it would be understood that I incorrectly marked the request. @lanmaster53, I hope you now have the clarification you so desire. My apologies for the mistake. > > It is still showing as closed for me. Yes, it's been closed for months. If you look at the history you'll see I didn't change the open status. All feature requests are kept as closed in this repo. We use labels to mark them as complete or not.

GiteaMirror commented 2026-04-30 10:46:12 -05:00

Author

Owner

Copy Link

@alex-t-grey commented on GitHub (Aug 1, 2024):

Just want to add another voice for this request. I just had multiple imported transactions fail to match existing scheduled transactions. In one case, all fields were identical except the amount was off by $0.01! In the other, it was a couple days and $10 difference. However, even after manually adjusting the scheduled transaction to perfectly match, there was no way to trigger a merge or force Actual to recognize them. The only workaround I could find was to delete the imported transactions, then run bank sync again.

While I would love the ability to select the two transactions and force a match, even the ability to just tigger "search for duplicates" across the board would be an improvement.

I also think the fuzzy logic for matching could use improvement. It should not fail due to a 1 penny difference in amount!

<!-- gh-comment-id:2263300633 --> @alex-t-grey commented on GitHub (Aug 1, 2024): Just want to add another voice for this request. I just had multiple imported transactions fail to match existing scheduled transactions. In one case, all fields were identical except the amount was off by $0.01! In the other, it was a couple days and $10 difference. However, even after manually adjusting the scheduled transaction to perfectly match, there was no way to trigger a merge or force Actual to recognize them. The only workaround I could find was to delete the imported transactions, then run bank sync again.  While I would love the ability to select the two transactions and force a match, even the ability to just tigger "search for duplicates" across the board would be an improvement. I also think the fuzzy logic for matching could use improvement. It should not fail due to a 1 penny difference in amount!

GiteaMirror commented 2026-04-30 10:46:12 -05:00

Author

Owner

Copy Link

@peterjcarroll commented on GitHub (Oct 18, 2024):

Just want to add another voice for this request. I just had multiple imported transactions fail to match existing scheduled transactions. In one case, all fields were identical except the amount was off by $0.01! In the other, it was a couple days and $10 difference. However, even after manually adjusting the scheduled transaction to perfectly match, there was no way to trigger a merge or force Actual to recognize them. The only workaround I could find was to delete the imported transactions, then run bank sync again.

While I would love the ability to select the two transactions and force a match, even the ability to just tigger "search for duplicates" across the board would be an improvement.

I also think the fuzzy logic for matching could use improvement. It should not fail due to a 1 penny difference in amount!

+1. Being able to manually merge two transactions into a single transactions is a big part of how I reconciled accounts in YNAB4 and is the only thing I feel is missing in ActualBudget. Especially when recurring transactions amounts can vary.

<!-- gh-comment-id:2422766973 --> @peterjcarroll commented on GitHub (Oct 18, 2024): > Just want to add another voice for this request. I just had multiple imported transactions fail to match existing scheduled transactions. In one case, all fields were identical except the amount was off by $0.01! In the other, it was a couple days and $10 difference. However, even after manually adjusting the scheduled transaction to perfectly match, there was no way to trigger a merge or force Actual to recognize them. The only workaround I could find was to delete the imported transactions, then run bank sync again. > >  > > While I would love the ability to select the two transactions and force a match, even the ability to just tigger "search for duplicates" across the board would be an improvement. > > I also think the fuzzy logic for matching could use improvement. It should not fail due to a 1 penny difference in amount! +1. Being able to manually merge two transactions into a single transactions is a big part of how I reconciled accounts in YNAB4 and is the only thing I feel is missing in ActualBudget. Especially when recurring transactions amounts can vary.

GiteaMirror commented 2026-04-30 10:46:13 -05:00

Author

Owner

Copy Link

@dasm commented on GitHub (Dec 12, 2024):

I'd also like to have a way to manually merge transactions.
Oftentimes, I submit my spending on the date I purchased something, but I might be charged few days (or even weeks) after the date.
I can change dates on initial purchase, but it can affect my entire budget.

<!-- gh-comment-id:2539528670 --> @dasm commented on GitHub (Dec 12, 2024): I'd also like to have a way to manually merge transactions. Oftentimes, I submit my spending on the date I purchased something, but I might be charged few days (or even weeks) after the date. I can change dates on initial purchase, but it can affect my entire budget.

GiteaMirror commented 2026-04-30 10:46:14 -05:00

Author

Owner

Copy Link

@github-actions[bot] commented on GitHub (Apr 17, 2025):

🎉 This feature has been implemented in #4739 and will be released in the next version. Thanks for sharing your idea! 🎉

<!-- gh-comment-id:2811617572 --> @github-actions[bot] commented on GitHub (Apr 17, 2025): :tada: This feature has been implemented in #4739 and will be released in the next version. Thanks for sharing your idea! :tada: <!-- feature-implemented-comment -->

Sign in to join this conversation.

No Branch/Tag Specified

Branches Tags

master

claude/hide-default-categories-1cwBZ

matiss/crdt-source-loading

matiss/crdt-protobuf

release/26.5.0

claude/update-issue-template-ykMNn

claude/fix-issue-7667-DPXi3

cursor/formula-feedback-improvements-4223

cursor/resolve-pr-7449-ee11

claude/fix-typescript-build-error-JPtZ5

jfdoming/api-tokens-part-3

jfdoming/api-tokens-part-2

jfdoming/api-tokens-part-1

claude/speed-up-vrt-workflow-ZAyI5

claude/crdt-version-auto-publish-Ph1BH

copilot/add-repository-configs-to-packages

worktree-compressed-drifting-ritchie

worktree-mellow-strolling-dawn

matiss/browser-api

claude/api-consumer-verification-kfz1K

feature/enable-banking

cursor/transaction-table-rewrite-f077

pr-7454

claude/fix-issue-7410-LLLQ4

release/v100.0.0

revert-7350-trim-deps

revert-7220-sankey-report

revert-7242-fix/split-parent-update-corruption

revert-7281-generate-icons

claude/electron-to-tauri-migration-LjBN8

worktree-remotion

release/vv26.4.0-pre

claude/browser-compatible-api-QbhHh

claude/improve-cli-transactions-waTUY

claude/publish-react-native-ios-j8qoT

js-proxy

claude/fix-flaky-ci-job-5gDdz

react-query-rules

react-query-useSchedules

claude/nightly-theme-validation-scan-DzOGD

claude/debug-simplefin-error-ZuKzB

matiss/desktop-client-subpath-imports

claude/fix-simplefin-ssrf-T31gX

claude/release-notes-validation-X7rvR

add-claude-github-actions-1772738270730

cursor/sync-performance-notification-9899

react-query-prefs

matiss/chunked-sync-and-progress-ux

v26.2.1

copilot/sub-pr-6880

fix-react-query-clear-on-close-budget

copilot/sub-pr-6140

feat/auto-note

feat/scoped-bank-sync

cursor/desktop-transactions-react-table-1d0c

fix-exhaustive-deps-App

copilot/fix-find-replace-bug

release/v26.2.0-pre

matiss/browser-tests

mobile-fix-drag-and-drop-across-groups

budget-table-v2

PayeeAutocomplete2

pglite

bugfix/plugins/fix-plugins-sw

feat/plugins/plugins-core-package

prerelease

matiss/unicode-minus-fix

cursor/fix-actual-github-issue-6206-gemini-3-pro-preview-9c37

TransactionFormPage

cursor/implement-mortgage-and-loan-account-type-78ca

tests-update-fill-with-pressSequentially

mobile/link-modal

deps/25.11

cursor/fix-update-vrt-apply-ci-job-dispatch-b324

sync-server-plugins

cursor/propose-patch-for-github-issue-5680-2a18

fix/compiler-preserve-inner-dollar-escapes

cursor/analyze-actual-budget-issue-and-propose-fix-5b70

coderabbitai/docstrings/0c070e5

cursor/add-wip-prefix-and-comment-to-prs-d78d

jfdoming/08-21-auto-focus-on-navigate-in-all-browsers

show-totals-on-mobile-budget-banners

allow-child-transactions-make-transfer

mobile-calculator-keyboard

payee-geolocation

enhance/restore_scroll_position

dm-fix-second-click-on-mobile-new-transaction-2

scrollToLocationBudget

alert-autofix-38

tsconfig-composite

mobile-fix-uncategorized-transactions-on-tracking-budgets

server-budget-handlers

fix-sql-injection-in-cleanup-template

non-chrome-draggable-workaround

mobile-budget-page-swipe-navigation

ts-db-all

stable

dark-theme-with-brand-colors

fix-mobile-delete-group

ts-db-select

UnderKoen/reconcile-context-menu

master-before-server-merge

v25.2.1

ts-runQuery

rename-redux-hooks

UnderKoen/3557-persist-state-in-history

remove-redux-CLOSE_BUDGET

fix-exhaustive-deps-errors-FinancesApp

redux-toolkit-createSlice-backup

accounts-function-component

ts-useSplitsExpanded

loot-core-server-package

useTransactios-in-TransactionEdit

react-aria-input

move-redux-to-desktop-client

QueryState-type

fix-themes-applied-late

mobile-vrts

revert-3295-spendingCardFix

react-aria-button-4

split-payee-on-mobile

twk3/pin-apis-crdt

notes-tag-autocomplete

ts-LoadBackup

dnd-kit

package-upgrades

v26.5.0

v26.4.0

v26.3.0

v26.2.1

v26.2.0

v26.1.0

v25.12.0

v25.11.0

v25.10.0

v25.9.0

v25.8.0

v25.7.1

v25.7.0

v25.6.1

v25.6.0

v25.5.0

v25.4.0

v25.3.1

v25.3.0

v25.2.1

v25.2.0

v25.1.0

v24.12.0

v24.11.0

v24.10.1

v24.10.0

v24.9.0

v24.8.0

v24.7.0

v24.6.0

v24.5.0

v24.4.0

v24.3.0

v24.2.0

v24.1.0

v23.12.0

v23.11.0

v23.10.0

v23.9.0

v23.8.1

v23.8.0

v23.7.2

v23.7.1

v23.7.0

v23.6.0

v23.5.0

v23.4.2

v23.4.1

v23.4.0

v23.3.2

v23.3.0

v23.2.9

v23.2.5

v23.1.12

v22.12.9

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 feature

Milestone

No items

No Milestone

Projects

Clear projects

No project

Assignees

Clear assignees

GiteaMirror ninjasurge

No Assignees

1 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/actual#49395