mirror of
https://github.com/actualbudget/actual.git
synced 2026-07-15 22:54:03 -05:00
[GH-ISSUE #6997] [Bug]: Linking or merging manual and scheduled transactions results in duplicates and incorrect “Due” status #52060
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/actual#52060
Reference in New Issue
Block a user
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?
Originally created by @jeremyj on GitHub (Feb 16, 2026).
Original GitHub issue: https://github.com/actualbudget/actual/issues/6997
What happened?
What happened?
I was trying to reconcile a manually added transaction with an automatically created scheduled transaction for the same payment.
Expected behavior:
Linking or merging the two should result in a single transaction associated with the schedule.
Actual behavior:
Two transactions remain:
If I link the manual transaction to the scheduled one → I end up with two transactions instead of one.
If I merge them → the automatically created scheduled transaction is marked as “Due”, and there are still two transactions present.
This makes it unclear which transaction is the correct one and breaks the expected reconciliation workflow.
How can we reproduce the issue?
How can we reproduce the issue?
Create a scheduled transaction that is automatically added to the ledger.
Manually add a transaction representing the same payment.
Attempt to reconcile them:
Option A: Link the manual transaction to the scheduled transaction.
Option B: Merge the two transactions.
Observe the results.
Expected:
A single transaction remains, correctly associated with the schedule and marked as Paid
.
Actual:
Two transactions remain. In the merge case, the scheduled one is also marked as Due.
Where are you hosting Actual?
Docker
What browsers are you seeing the problem on?
Chrome
Operating System
Linux
@RegalMonkey commented on GitHub (Mar 9, 2026):
I wonder if this is related to one I was just observing here, if you go to an upcoming transaction and use the 'Post transaction today' option it fails to remove the upcoming transaction from the schedule. Similarly if you post the transaction, then change the date to today, it'll actually put it back on the upcoming schedule.
In short, it seems the schedule matching is demanding the criteria be met exactly rather than accepting the scheduled item as complete once it's entered. So far I've just been telling it to skip the next scheduled date to bypass it, but for auto-matching perhaps it could be read the date as a by-or-before.
@Triscal commented on GitHub (Mar 11, 2026):
@RegalMonkey currently schedules only match a transaction if they are within 2 days of the scheduled transaction. For example if today is Tuesday and I have scheduled transaction for Friday, if I post it today, it will not match the schedule. Because it is too many days away. This is noted here: https://actualbudget.org/docs/schedules/#how-actual-finds-schedules
Is this what is you are running into?
To be clear as well, I'm stating the behaviour not defending it, I am not sure why it is exists and I'm hoping I can convince someone to change it in the future.
@Triscal commented on GitHub (Mar 11, 2026):
@jeremyj, I think I've been able to reproduce this. It seems to depend on which order you select the two transactions. If I select the already linked transaction first then merge it is unlinked but if I select the unlinked transaction first then merge it works. Can you confirm if this is what you are seeing?
If so I'll take a look at fixing this issue.
On other 'reconciliation step' it sounds like you are expecting
link scheduleto link and then merge the two transactions. If that is what you are expecting I think that is more of a feature request, because imagining a schedule that occurs every 3 days (or daily) and you manually need to link those transactions you would NOT want to lose the other transactions you would only want to associate them with the schedule. Or am I misunderstanding you?@Triscal commented on GitHub (Mar 11, 2026):
Forgot to attach the video of me reproducing (I think).
https://github.com/user-attachments/assets/6dc13556-e7f8-41b0-b400-991c3e0c470c
@RegalMonkey commented on GitHub (Mar 11, 2026):
That does seem to fit, just created a couple dummy schedules and while the 2 day out test cleared the schedule the 3 day out one didn't.
I would say that a solid bit of logic would be to match based on the time the user sets as the 'upcoming length'. I expect people generally use that as things they expect to pay this pay cycle so posting things within that window matching the schedule would makes sense to clear the event.
@Triscal commented on GitHub (Mar 12, 2026):
@RegalMonkey I agree. After taking a stab at solving this issue, I feel like my next goal will be: https://github.com/actualbudget/actual/issues/1957 which I see you commented on and is the "same" two day issue. I'm not sure if there is a secret reason why this hasn't been changed in the past or why it was noted in the docs that it is 2 days, but we will see what happens, when the time comes.
@Triscal commented on GitHub (Mar 21, 2026):
@matt-fidd feels like this issue should be closed now that #7177 is merged. It looks like it didn't auto-close because the commit mentioned this issue not the MR description.
@alecbakholdin commented on GitHub (Apr 24, 2026):
Confirmed this can be closed, video below shows linking the transaction to a schedule then merging it with another transaction. Schedule is properly merged.
https://github.com/user-attachments/assets/6bca06ce-908d-47dc-afaa-5ff98b0f3c54