[GH-ISSUE #6002] [Bug]: Scheduled transfer not matching when file import on payee account happens first #51688

Closed
opened 2026-04-30 18:56:38 -05:00 by GiteaMirror · 7 comments
Owner

Originally created by @kenyarnall on GitHub (Oct 26, 2025).
Original GitHub issue: https://github.com/actualbudget/actual/issues/6002

Verified issue does not already exist?

  • I have searched and found no existing issue

What happened?

I have a scheduled payment from my checking account to my credit card (both on budget). I set up the schedule as follows:

  • Payee: Credit Card
  • Account: Checking Account
  • Amount: is approx xxxx.xx (note: is the exact amount of forthcoming payment)
  • Date: every month on the 6th

I also have two Pre rules in place that create transfers when I do file imports (no sync for me) on the accounts:

One rule says

  • if imported payee is "credit card autopayment" and account is Credit Card
  • set payee to Checking Account

The other rule says

  • if imported payee is "credit card autopayment" and account is Checking Account
  • set payee to Credit Card

When I import a file from either account, the transfer gets created as expected, and if I do both imports, it is deduplicated as expected.

The BUG: If I import the transaction from the Checking Account first, the schedule is linked to the transaction as expected. HOWEVER, if I first import the transaction from the Credit Card Account, the schedule is not linked, not even after both imports are done.

Whether the schedule is linked is sensitive to which import is done first.

My initial suspicion is that this is related to the sign of the amount in the schedule compared to the value stored in the transfer, but I dunno -- never looked at the code.

How can we reproduce the issue?

I believe I described this sufficiently in the bug description.

Where are you hosting Actual?

Docker

What browsers are you seeing the problem on?

Chrome

Operating System

Linux

Originally created by @kenyarnall on GitHub (Oct 26, 2025). Original GitHub issue: https://github.com/actualbudget/actual/issues/6002 ### Verified issue does not already exist? - [x] I have searched and found no existing issue ### What happened? I have a scheduled payment from my checking account to my credit card (both on budget). I set up the schedule as follows: - Payee: Credit Card - Account: Checking Account - Amount: is approx xxxx.xx (note: is the exact amount of forthcoming payment) - Date: every month on the 6th I also have two Pre rules in place that create transfers when I do file imports (no sync for me) on the accounts: One rule says - if imported payee is "credit card autopayment" and account is Credit Card - set payee to Checking Account The other rule says - if imported payee is "credit card autopayment" and account is Checking Account - set payee to Credit Card When I import a file from either account, the transfer gets created as expected, and if I do both imports, it is deduplicated as expected. **The BUG:** If I import the transaction from the Checking Account first, the schedule is linked to the transaction as expected. **HOWEVER**, if I first import the transaction from the Credit Card Account, the schedule is **not** linked, not even after both imports are done. Whether the schedule is linked is sensitive to which import is done first. My initial suspicion is that this is related to the sign of the amount in the schedule compared to the value stored in the transfer, but I dunno -- never looked at the code. ### How can we reproduce the issue? I believe I described this sufficiently in the bug description. ### Where are you hosting Actual? Docker ### What browsers are you seeing the problem on? Chrome ### Operating System Linux
GiteaMirror added the transaction importbug labels 2026-04-30 18:56:38 -05:00
Author
Owner

@kenyarnall commented on GitHub (Oct 26, 2025):

I tried changing the schedule from an approximate amount to a large range from -xxxx to +xxxx, and that did not fix the issue.

<!-- gh-comment-id:3448621735 --> @kenyarnall commented on GitHub (Oct 26, 2025): I tried changing the schedule from an approximate amount to a large range from -xxxx to +xxxx, and that did not fix the issue.
Author
Owner

@MatissJanis commented on GitHub (Oct 26, 2025):

👋 Hi!

Please provide a budget we could download (zip file) as well as a CSV that we can import to reproduce the issue.

Thanks

<!-- gh-comment-id:3448934112 --> @MatissJanis commented on GitHub (Oct 26, 2025): 👋 Hi! Please provide a budget we could download (zip file) as well as a CSV that we can import to reproduce the issue. Thanks
Author
Owner

@kenyarnall commented on GitHub (Oct 27, 2025):

👋 Hi!

Please provide a budget we could download (zip file) as well as a CSV that we can import to reproduce the issue.

Thanks

I've put a sample budget together, along with two .csv imports -- attached to this comment. The budget contains two Pre rules and a schedule. The CSV files each contain a single transaction, both sides of a transfer.

My experience: Import checkingaccount.csv first, and the schedule is linked. Import creditcard.csv first and the schedule is not linked.

2025-10-27-Test Budget.zip
creditcard.csv
checkingaccount.csv

<!-- gh-comment-id:3453075515 --> @kenyarnall commented on GitHub (Oct 27, 2025): > 👋 Hi! > > Please provide a budget we could download (zip file) as well as a CSV that we can import to reproduce the issue. > > Thanks I've put a sample budget together, along with two .csv imports -- attached to this comment. The budget contains two Pre rules and a schedule. The CSV files each contain a single transaction, both sides of a transfer. My experience: Import checkingaccount.csv first, and the schedule is linked. Import creditcard.csv first and the schedule is not linked. [2025-10-27-Test Budget.zip](https://github.com/user-attachments/files/23172405/2025-10-27-Test.Budget.zip) [creditcard.csv](https://github.com/user-attachments/files/23172407/creditcard.csv) [checkingaccount.csv](https://github.com/user-attachments/files/23172406/checkingaccount.csv)
Author
Owner

@MatissJanis commented on GitHub (Oct 29, 2025):

Thanks! The reproduction really helped.

I think this change will fix the issue. Could you please verify using the demo link?

<!-- gh-comment-id:3463106334 --> @MatissJanis commented on GitHub (Oct 29, 2025): Thanks! The reproduction really helped. I think [this change](https://github.com/actualbudget/actual/pull/6025) will fix the issue. Could you please verify using the [demo link](https://github.com/actualbudget/actual/pull/6025#issuecomment-3463083576)?
Author
Owner

@kenyarnall commented on GitHub (Oct 29, 2025):

Thanks! The reproduction really helped.

I think this change will fix the issue. Could you please verify using the demo link?

I tried it using the test data, and here's what I observe:

  • If I import the source transaction first (checking account), then the schedule links immediately (the transfer displays as linked to the schedule in both accounts). Importing the sink transaction second works as expected.
  • If I import the sink transaction first (credit card), then the schedule disappears from both accounts as if it's been linked, but the link icon (the circular arrows) only appears on the source side. When I do the second import, the icon appears on both sides.

Here are some pics.

First, before any import:

Image Image

After import to credit card:

Image Image

After second import to checking account:

Image Image

Maybe it's just the logic that governs whether the linked schedule icon is displayed that is wrong now?

<!-- gh-comment-id:3463326745 --> @kenyarnall commented on GitHub (Oct 29, 2025): > Thanks! The reproduction really helped. > > I think [this change](https://github.com/actualbudget/actual/pull/6025) will fix the issue. Could you please verify using the [demo link](https://github.com/actualbudget/actual/pull/6025#issuecomment-3463083576)? I tried it using the test data, and here's what I observe: - If I import the source transaction first (checking account), then the schedule links immediately (the transfer displays as linked to the schedule in both accounts). Importing the sink transaction second works as expected. - If I import the sink transaction first (credit card), then the schedule disappears from both accounts as if it's been linked, but the link icon (the circular arrows) only appears on the source side. When I do the second import, the icon appears on both sides. Here are some pics. First, before any import: <img width="2652" height="528" alt="Image" src="https://github.com/user-attachments/assets/2813b830-1e83-439c-90f1-e4ce338430d5" /> <img width="2652" height="528" alt="Image" src="https://github.com/user-attachments/assets/0e49ea05-d57a-4942-a28f-fc7c11a52f7d" /> After import to credit card: <img width="2652" height="528" alt="Image" src="https://github.com/user-attachments/assets/d9389df6-83be-404a-a303-5e202dbe6acc" /> <img width="2652" height="528" alt="Image" src="https://github.com/user-attachments/assets/f21bee2d-2268-49bd-84ac-8f7189caa4a1" /> After second import to checking account: <img width="2652" height="528" alt="Image" src="https://github.com/user-attachments/assets/d99c5e8d-5cc1-4af8-b71d-b398f7f35085" /> <img width="2652" height="528" alt="Image" src="https://github.com/user-attachments/assets/e8dd7d3c-e17d-41dc-8af5-a2f80ab1f8ff" /> Maybe it's just the logic that governs whether the linked schedule icon is displayed that is wrong now?
Author
Owner

@MatissJanis commented on GitHub (Oct 29, 2025):

Thanks @kenyarnall!

Looks like only one side of the ledger got updated to match a schedule whereas the other was not updated (thus no icon). I've updated the PR. Try again and let me know if you spot any other issue.

<!-- gh-comment-id:3463906611 --> @MatissJanis commented on GitHub (Oct 29, 2025): Thanks @kenyarnall! Looks like only one side of the ledger got updated to match a schedule whereas the other was not updated (thus no icon). I've updated the PR. Try again and let me know if you spot any other issue.
Author
Owner

@kenyarnall commented on GitHub (Oct 29, 2025):

Hi @MatissJanis. That version works with my tests, and the code makes good sense, too.

Thanks very much for tending to this. I am very impressed with how you all run this project, and am hoping to start contributing next year when my work slows down.

<!-- gh-comment-id:3464058531 --> @kenyarnall commented on GitHub (Oct 29, 2025): Hi @MatissJanis. That version works with my tests, and the code makes good sense, too. Thanks very much for tending to this. I am **very** impressed with how you all run this project, and am hoping to start contributing next year when my work slows down.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/actual#51688