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

[GH-ISSUE #6997] [Bug]: Linking or merging manual and scheduled transactions results in duplicates and incorrect “Due” status #9876

New Issue
Open
opened 2026-04-10 20:13:01 -05:00 by GiteaMirror · 7 comments
GiteaMirror commented 2026-04-10 20:13:01 -05:00
Owner
Copy Link

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

Image Image Image Image Image Image

.

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

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 <img width="1618" height="138" alt="Image" src="https://github.com/user-attachments/assets/c9b3fecd-4270-4d76-8167-a783402e6280" /> <img width="1624" height="143" alt="Image" src="https://github.com/user-attachments/assets/2447c755-0847-4e8c-9501-e2ecad5e86bb" /> <img width="827" height="241" alt="Image" src="https://github.com/user-attachments/assets/16402ca7-b639-4052-9bd9-5c9ba39b646e" /> <img width="1616" height="153" alt="Image" src="https://github.com/user-attachments/assets/8d99252c-e7aa-4319-8f68-f0480d7687aa" /> <img width="1612" height="262" alt="Image" src="https://github.com/user-attachments/assets/59c70cb1-fe0f-4789-9510-b64475841d85" /> <img width="1612" height="143" alt="Image" src="https://github.com/user-attachments/assets/45c2fe0f-9f1e-43a9-8363-273ed5f7095f" /> . 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
GiteaMirror added the bugtransactionsgood first issuehelp wanted labels 2026-04-10 20:13:01 -05:00
GiteaMirror commented 2026-04-10 20:13:02 -05:00
Author
Owner
Copy Link

@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.

<!-- gh-comment-id:4023247424 --> @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.
GiteaMirror commented 2026-04-10 20:13:03 -05:00
Author
Owner
Copy Link

@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.

<!-- gh-comment-id:4035887450 --> @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.
GiteaMirror commented 2026-04-10 20:13:04 -05:00
Author
Owner
Copy Link

@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 schedule to 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?

<!-- gh-comment-id:4035969486 --> @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 schedule` to 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?
GiteaMirror commented 2026-04-10 20:13:06 -05:00
Author
Owner
Copy Link

@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

<!-- gh-comment-id:4035971073 --> @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
GiteaMirror commented 2026-04-10 20:13:08 -05:00
Author
Owner
Copy Link

@RegalMonkey 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.

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.

<!-- gh-comment-id:4038495236 --> @RegalMonkey commented on GitHub (Mar 11, 2026): > [@RegalMonkey](https://github.com/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. 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.
GiteaMirror commented 2026-04-10 20:13:10 -05:00
Author
Owner
Copy Link

@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.

<!-- gh-comment-id:4043427791 --> @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.
GiteaMirror commented 2026-04-10 20:13:13 -05:00
Author
Owner
Copy Link

@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.

<!-- gh-comment-id:4103780180 --> @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.
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 good first issue help wanted 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#9876
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?