github-starred/actual
2
0
Fork 0
mirror of https://github.com/actualbudget/actual.git synced 2026-05-06 07:01:45 -05:00
Code Issues 1.5k Packages Projects Releases 54 Wiki Activity

[GH-ISSUE #338] Can't manually match an imported transaction with a previously entered (or scheduled) transaction #41675

New Issue
Closed
opened 2026-04-26 01:05:01 -05:00 by GiteaMirror · 5 comments
GiteaMirror commented 2026-04-26 01:05:01 -05:00
Owner
Copy Link

Originally created by @bpaulien on GitHub (Nov 19, 2021).
Original GitHub issue: https://github.com/actualbudget/actual/issues/338

I have a scheduled transaction that was in the register, and then manually imported a transaction from the bank. I don't see a way to tell the software that these 2 are a "match" and really the same transaction. I guess I can delete the one that I imported, but it would be nice if they could be matched so I don't have to delete.

Originally created by @bpaulien on GitHub (Nov 19, 2021). Original GitHub issue: https://github.com/actualbudget/actual/issues/338 I have a scheduled transaction that was in the register, and then manually imported a transaction from the bank. I don't see a way to tell the software that these 2 are a "match" and really the same transaction. I guess I can delete the one that I imported, but it would be nice if they could be matched so I don't have to delete.
GiteaMirror added the feature label 2026-04-26 01:05:01 -05:00
GiteaMirror commented 2026-04-26 01:05:02 -05:00
Author
Owner
Copy Link

@bpaulien commented on GitHub (Nov 19, 2021):

I guess the main reason I want to be able to match them instead of deleting the imported one is because the imported one is now marked as "cleared" because it came from the bank. But the "real" one (that has the correct payee and notes) is not marked as cleared. So now I have to delete the one with the funny payee and "External Deposit" in Notes, and then go and mark the scheduled one as cleared.

So I guess we need to come up with some rules for what happens when 2 transactions are matched. I guess you would want the Payee and the Notes to be taken from the scheduled, or manually entered one, because those have the correct information (presumably, since you did it by hand) But the "cleared" status of the imported one. I guess the amounts should typically be the same? But if not, take the value of the imported one because that came from the bank, so is official. In case you "fat fingered" the amount when manually entering it (or forgot to add tip to restaurant meal) the amount from bank would be right.

What do you think about date? Take date from manual entry, or from import?

<!-- gh-comment-id:1280038879 --> @bpaulien commented on GitHub (Nov 19, 2021): I guess the main reason I want to be able to match them instead of deleting the imported one is because the imported one is now marked as "cleared" because it came from the bank. But the "real" one (that has the correct payee and notes) is not marked as cleared. So now I have to delete the one with the funny payee and "External Deposit" in Notes, and then go and mark the scheduled one as cleared. So I guess we need to come up with some rules for what happens when 2 transactions are matched. I guess you would want the Payee and the Notes to be taken from the scheduled, or manually entered one, because those have the correct information (presumably, since you did it by hand) But the "cleared" status of the imported one. I guess the amounts should typically be the same? But if not, take the value of the imported one because that came from the bank, so is official. In case you "fat fingered" the amount when manually entering it (or forgot to add tip to restaurant meal) the amount from bank would be right. What do you think about date? Take date from manual entry, or from import?
GiteaMirror commented 2026-04-26 01:05:03 -05:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Jan 15, 2023):

🚧🚨 This issue is being marked as stale due to 90 days of inactivity. 🚧🚨

<!-- gh-comment-id:1383022902 --> @github-actions[bot] commented on GitHub (Jan 15, 2023): 🚧🚨 This issue is being marked as stale due to 90 days of inactivity. 🚧🚨
GiteaMirror commented 2026-04-26 01:05:05 -05:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (May 2, 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=label%3A%22needs+votes%22+sort%3Areactions-%2B1-desc+

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

<!-- gh-comment-id:1531911309 --> @github-actions[bot] commented on GitHub (May 2, 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=label%3A%22needs+votes%22+sort%3Areactions-%2B1-desc+ Don’t forget to upvote the top comment with 👍!
GiteaMirror commented 2026-04-26 01:05:05 -05:00
Author
Owner
Copy Link

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

You can link a transaction to a schedule manually by selecting the transaction and using the "Link Schedule" option in the menu.

<!-- gh-comment-id:1934369894 --> @youngcw commented on GitHub (Feb 8, 2024): You can link a transaction to a schedule manually by selecting the transaction and using the "Link Schedule" option in the menu.
GiteaMirror commented 2026-04-26 01:05:05 -05:00
Author
Owner
Copy Link

@mosteo commented on GitHub (Aug 5, 2025):

The shortcoming of manually linking is that if the schedule applies rules on automatic matching, those are not applied.

You have to enter the "edit as rule" secondary dialog /before linking the transaction/ and then adjust the fields to make it match. Then you can "apply" the rule.

As a further nuisance of my bank, it posts several transactions from unrelated payees under the same fake payee (just a code, don't know why). Something similar happens with transactions that arrive through Paypal. They're difficult to match to a schedule because the payee will always be wrong, and you can't rename the payee, as it's shared by several real payees. If you don't enter a payee in the schedule to allow it to match on e.g. the notes, the upcoming transaction will show blank fields.

Unless I'm missing the proper workflow here, this translates into lots of manual cumbersome editing to apply the rules of a schedule to the manually linked transaction. It would be ideal to be able to select the scheduled transaction and the real one, and have something like "link & apply rules" in the context menu. Or at least that "link schedule" had a straightforward way of force-applying rules bypassing the matching.

<!-- gh-comment-id:3156226179 --> @mosteo commented on GitHub (Aug 5, 2025): The shortcoming of manually linking is that if the schedule applies rules on automatic matching, those are not applied. You have to enter the "edit as rule" secondary dialog /before linking the transaction/ and then adjust the fields to make it match. Then you can "apply" the rule. As a further nuisance of my bank, it posts several transactions from unrelated payees under the same fake payee (just a code, don't know why). Something similar happens with transactions that arrive through Paypal. They're difficult to match to a schedule because the payee will always be wrong, and you can't rename the payee, as it's shared by several real payees. If you don't enter a payee in the schedule to allow it to match on e.g. the notes, the upcoming transaction will show blank fields. Unless I'm missing the proper workflow here, this translates into lots of manual cumbersome editing to apply the rules of a schedule to the manually linked transaction. It would be ideal to be able to select the scheduled transaction and the real one, and have something like "link & apply rules" in the context menu. Or at least that "link schedule" had a straightforward way of force-applying rules bypassing the matching.
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 feature
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#41675
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?