[GH-ISSUE #5222] [Bug]: Account balance is different on desktop and mobile sites #51344

Closed
opened 2026-04-30 17:39:23 -05:00 by GiteaMirror · 9 comments
Owner

Originally created by @AlesAlitis on GitHub (Jun 22, 2025).
Original GitHub issue: https://github.com/actualbudget/actual/issues/5222

Verified issue does not already exist?

  • I have searched and found no existing issue

What happened?

An account's balance amount differs on desktop and mobile pages. Mobile balance is correct. On the desktop page it is off by 3000. Vivaldi, Edge and Firefox show the same result on desktop.

Actual Budget server
OS: TrueNAS Scale
App Version: v25.6.1
AB Version: v1.3.5

Desktop environment
OS: Windows 11 Pro 24H2 26100.4351
Browsers:

  • Vivaldi: 7.4.3684.55 (Stable channel) (64-bit)
  • Edge: 137.0.3296.93 (Official build) (64-bit)
  • Firefox: 139.0.4 (64-bit)

Mobile environment
OS: Android 16, sec update 5 June 2025
Browsers:

  • Vivaldi: 7.4.3691.84
  • Chrome: 137.0.7151.115

Image
Image

How can we reproduce the issue?

  1. Import YNAB4 budget file
  2. Manually transfer scheduled transactions to Actual Budget
  3. Add ~1 month worth of transactions
  4. Compare account's balance between mobile device and desktop

Where are you hosting Actual?

NAS

What browsers are you seeing the problem on?

Chrome, Other, Firefox, Microsoft Edge

Operating System

Windows 11

Originally created by @AlesAlitis on GitHub (Jun 22, 2025). Original GitHub issue: https://github.com/actualbudget/actual/issues/5222 ### Verified issue does not already exist? - [x] I have searched and found no existing issue ### What happened? An account's balance amount differs on desktop and mobile pages. Mobile balance is correct. On the desktop page it is off by 3000. Vivaldi, Edge and Firefox show the same result on desktop. **Actual Budget server** OS: TrueNAS Scale App Version: v25.6.1 AB Version: v1.3.5 **Desktop environment** OS: Windows 11 Pro 24H2 26100.4351 Browsers: - Vivaldi: 7.4.3684.55 (Stable channel) (64-bit) - Edge: 137.0.3296.93 (Official build) (64-bit) - Firefox: 139.0.4 (64-bit) **Mobile environment** OS: Android 16, sec update 5 June 2025 Browsers: - Vivaldi: 7.4.3691.84 - Chrome: 137.0.7151.115 ![Image](https://github.com/user-attachments/assets/683bffc2-d848-4bcb-b300-640ad107f286) ![Image](https://github.com/user-attachments/assets/254e6ec4-af7f-446b-9afa-61fe8cf93626) ### How can we reproduce the issue? 1. Import YNAB4 budget file 2. Manually transfer scheduled transactions to Actual Budget 3. Add ~1 month worth of transactions 4. Compare account's balance between mobile device and desktop ### Where are you hosting Actual? NAS ### What browsers are you seeing the problem on? Chrome, Other, Firefox, Microsoft Edge ### Operating System Windows 11
GiteaMirror added the needs infobug labels 2026-04-30 17:39:23 -05:00
Author
Owner

@youngcw commented on GitHub (Jun 22, 2025):

You must have some broken splits. Try using the repair transactions option in the settings. If that doesn't work you will need to go through the history and look for where things get off.

<!-- gh-comment-id:2994306926 --> @youngcw commented on GitHub (Jun 22, 2025): You must have some broken splits. Try using the repair transactions option in the settings. If that doesn't work you will need to go through the history and look for where things get off.
Author
Owner

@AlesAlitis commented on GitHub (Jun 22, 2025):

You must have some broken splits. Try using the repair transactions option in the settings. If that doesn't work you will need to go through the history and look for where things get off.

Thank you! It was indeed a split transaction. Apparently YNAB4 didn't do very good job with those. The difference between desktop and mobile really threw me off.

<!-- gh-comment-id:2994315350 --> @AlesAlitis commented on GitHub (Jun 22, 2025): > You must have some broken splits. Try using the repair transactions option in the settings. If that doesn't work you will need to go through the history and look for where things get off. Thank you! It was indeed a split transaction. Apparently YNAB4 didn't do very good job with those. The difference between desktop and mobile really threw me off.
Author
Owner

@youngcw commented on GitHub (Jun 22, 2025):

If you feel like digging through your ynab file and finding why that one split was different, we could use that to prevent this in the future.

<!-- gh-comment-id:2994339104 --> @youngcw commented on GitHub (Jun 22, 2025): If you feel like digging through your ynab file and finding why that one split was different, we could use that to prevent this in the future.
Author
Owner

@AlesAlitis commented on GitHub (Jun 22, 2025):

If you feel like digging through your ynab file and finding why that one split was different, we could use that to prevent this in the future.

I did so. The only difference with the offending sub-transaction is that it this parameter on it: "isTombstone": true,. Other than that there doesn't seem to be anything suspicious with the record. Just in case, here is the full thing:

{
	"subTransactions": [
		{
			"categoryId": "Category/__ImmediateIncome__",
			"amount": 3000,
			"isTombstone": true,
			"entityVersion": "G-7179",
			"parentTransactionId": "BEE3342A-A46C-0FCA-E527-193BB4023448_2022-01-26_0",
			"entityId": "9CDC3995-B9BF-6E63-10CA-4B1991C78880",
			"entityType": "subTransaction"
		},
		{
			"categoryId": "EDA1A89F-C92C-D10D-7E43-9D9D70177E99",
			"amount": 33.85,
			"entityVersion": "G-7182",
			"parentTransactionId": "BEE3342A-A46C-0FCA-E527-193BB4023448_2022-01-26_0",
			"entityId": "F6EB7A48-E3EC-337B-4B28-4B1992185A9E",
			"entityType": "subTransaction"
		},
		{
			"categoryId": "Category/__ImmediateIncome__",
			"amount": 3261.08,
			"entityVersion": "G-7184",
			"parentTransactionId": "BEE3342A-A46C-0FCA-E527-193BB4023448_2022-01-26_0",
			"entityId": "BB4D59DF-C526-41C6-9D15-11F98A5CD05D",
			"entityType": "subTransaction"
		}
	],
	"date": "2022-01-21",
	"entityId": "BEE3342A-A46C-0FCA-E527-193BB4023448_2022-01-26_0",
	"entityType": "transaction",
	"categoryId": "Category/__Split__",
	"accepted": true,
	"payeeId": "BF23E3F1-DCDD-0479-263C-E3EA026BC8A2",
	"amount": 3294.93,
	"accountId": "7EBAA86F-A737-66F7-7B1C-46DB0CE10D0A",
	"entityVersion": "G-7180",
	"cleared": "Cleared",
	"dateEnteredFromSchedule": "2022-01-11"
}
<!-- gh-comment-id:2994351677 --> @AlesAlitis commented on GitHub (Jun 22, 2025): > If you feel like digging through your ynab file and finding why that one split was different, we could use that to prevent this in the future. I did so. The only difference with the offending sub-transaction is that it this parameter on it: `"isTombstone": true,`. Other than that there doesn't seem to be anything suspicious with the record. Just in case, here is the full thing: ``` { "subTransactions": [ { "categoryId": "Category/__ImmediateIncome__", "amount": 3000, "isTombstone": true, "entityVersion": "G-7179", "parentTransactionId": "BEE3342A-A46C-0FCA-E527-193BB4023448_2022-01-26_0", "entityId": "9CDC3995-B9BF-6E63-10CA-4B1991C78880", "entityType": "subTransaction" }, { "categoryId": "EDA1A89F-C92C-D10D-7E43-9D9D70177E99", "amount": 33.85, "entityVersion": "G-7182", "parentTransactionId": "BEE3342A-A46C-0FCA-E527-193BB4023448_2022-01-26_0", "entityId": "F6EB7A48-E3EC-337B-4B28-4B1992185A9E", "entityType": "subTransaction" }, { "categoryId": "Category/__ImmediateIncome__", "amount": 3261.08, "entityVersion": "G-7184", "parentTransactionId": "BEE3342A-A46C-0FCA-E527-193BB4023448_2022-01-26_0", "entityId": "BB4D59DF-C526-41C6-9D15-11F98A5CD05D", "entityType": "subTransaction" } ], "date": "2022-01-21", "entityId": "BEE3342A-A46C-0FCA-E527-193BB4023448_2022-01-26_0", "entityType": "transaction", "categoryId": "Category/__Split__", "accepted": true, "payeeId": "BF23E3F1-DCDD-0479-263C-E3EA026BC8A2", "amount": 3294.93, "accountId": "7EBAA86F-A737-66F7-7B1C-46DB0CE10D0A", "entityVersion": "G-7180", "cleared": "Cleared", "dateEnteredFromSchedule": "2022-01-11" } ```
Author
Owner

@youngcw commented on GitHub (Jun 22, 2025):

If you feel like digging through your ynab file and finding why that one split was different, we could use that to prevent this in the future.

I did so. The only difference with the offending sub-transaction is that it this parameter on it: "isTombstone": true,. Other than that there doesn't seem to be anything suspicious with the record. Just in case, here is the full thing:

{
	"subTransactions": [
		{
			"categoryId": "Category/__ImmediateIncome__",
			"amount": 3000,
			"isTombstone": true,
			"entityVersion": "G-7179",
			"parentTransactionId": "BEE3342A-A46C-0FCA-E527-193BB4023448_2022-01-26_0",
			"entityId": "9CDC3995-B9BF-6E63-10CA-4B1991C78880",
			"entityType": "subTransaction"
		},
		{
			"categoryId": "EDA1A89F-C92C-D10D-7E43-9D9D70177E99",
			"amount": 33.85,
			"entityVersion": "G-7182",
			"parentTransactionId": "BEE3342A-A46C-0FCA-E527-193BB4023448_2022-01-26_0",
			"entityId": "F6EB7A48-E3EC-337B-4B28-4B1992185A9E",
			"entityType": "subTransaction"
		},
		{
			"categoryId": "Category/__ImmediateIncome__",
			"amount": 3261.08,
			"entityVersion": "G-7184",
			"parentTransactionId": "BEE3342A-A46C-0FCA-E527-193BB4023448_2022-01-26_0",
			"entityId": "BB4D59DF-C526-41C6-9D15-11F98A5CD05D",
			"entityType": "subTransaction"
		}
	],
	"date": "2022-01-21",
	"entityId": "BEE3342A-A46C-0FCA-E527-193BB4023448_2022-01-26_0",
	"entityType": "transaction",
	"categoryId": "Category/__Split__",
	"accepted": true,
	"payeeId": "BF23E3F1-DCDD-0479-263C-E3EA026BC8A2",
	"amount": 3294.93,
	"accountId": "7EBAA86F-A737-66F7-7B1C-46DB0CE10D0A",
	"entityVersion": "G-7180",
	"cleared": "Cleared",
	"dateEnteredFromSchedule": "2022-01-11"
}

So it's marked as isTombstone, but isn't deleted? Is there a different flag that shows if something is deleted?

Wait, looking at the other fields, it says the total is 324.93. So was that split marked isTombstone imported when it shouldn't have been?

<!-- gh-comment-id:2994353867 --> @youngcw commented on GitHub (Jun 22, 2025): > > If you feel like digging through your ynab file and finding why that one split was different, we could use that to prevent this in the future. > > I did so. The only difference with the offending sub-transaction is that it this parameter on it: `"isTombstone": true,`. Other than that there doesn't seem to be anything suspicious with the record. Just in case, here is the full thing: > > ``` > { > "subTransactions": [ > { > "categoryId": "Category/__ImmediateIncome__", > "amount": 3000, > "isTombstone": true, > "entityVersion": "G-7179", > "parentTransactionId": "BEE3342A-A46C-0FCA-E527-193BB4023448_2022-01-26_0", > "entityId": "9CDC3995-B9BF-6E63-10CA-4B1991C78880", > "entityType": "subTransaction" > }, > { > "categoryId": "EDA1A89F-C92C-D10D-7E43-9D9D70177E99", > "amount": 33.85, > "entityVersion": "G-7182", > "parentTransactionId": "BEE3342A-A46C-0FCA-E527-193BB4023448_2022-01-26_0", > "entityId": "F6EB7A48-E3EC-337B-4B28-4B1992185A9E", > "entityType": "subTransaction" > }, > { > "categoryId": "Category/__ImmediateIncome__", > "amount": 3261.08, > "entityVersion": "G-7184", > "parentTransactionId": "BEE3342A-A46C-0FCA-E527-193BB4023448_2022-01-26_0", > "entityId": "BB4D59DF-C526-41C6-9D15-11F98A5CD05D", > "entityType": "subTransaction" > } > ], > "date": "2022-01-21", > "entityId": "BEE3342A-A46C-0FCA-E527-193BB4023448_2022-01-26_0", > "entityType": "transaction", > "categoryId": "Category/__Split__", > "accepted": true, > "payeeId": "BF23E3F1-DCDD-0479-263C-E3EA026BC8A2", > "amount": 3294.93, > "accountId": "7EBAA86F-A737-66F7-7B1C-46DB0CE10D0A", > "entityVersion": "G-7180", > "cleared": "Cleared", > "dateEnteredFromSchedule": "2022-01-11" > } > ``` So it's marked as isTombstone, but isn't deleted? Is there a different flag that shows if something is deleted? Wait, looking at the other fields, it says the total is 324.93. So was that split marked isTombstone imported when it shouldn't have been?
Author
Owner

@AlesAlitis commented on GitHub (Jun 22, 2025):

isTombstone is in multiple other records, but non of them is a sub-transaction. There were a couple more incorrect splits that I fixed right after the import. Maybe isTombstone is not processed correctly when in a sub transaction?

<!-- gh-comment-id:2994366460 --> @AlesAlitis commented on GitHub (Jun 22, 2025): isTombstone is in multiple other records, but non of them is a sub-transaction. There were a couple more incorrect splits that I fixed right after the import. Maybe isTombstone is not processed correctly when in a sub transaction?
Author
Owner

@youngcw commented on GitHub (Jun 23, 2025):

Want to try out this build and see if it imports correctly? https://github.com/actualbudget/actual/pull/5226

There is a deploy link where you can test it out. All data stays on your machine

<!-- gh-comment-id:2994597074 --> @youngcw commented on GitHub (Jun 23, 2025): Want to try out this build and see if it imports correctly? https://github.com/actualbudget/actual/pull/5226 There is a deploy link where you can test it out. All data stays on your machine
Author
Owner

@AlesAlitis commented on GitHub (Jun 23, 2025):

I tested it and it imported correctly this time. The tombstone sub-transaction wasn't in the split and the account balance looked correct. Great job!

<!-- gh-comment-id:2997268452 --> @AlesAlitis commented on GitHub (Jun 23, 2025): I tested it and it imported correctly this time. The tombstone sub-transaction wasn't in the split and the account balance looked correct. Great job!
Author
Owner

@youngcw commented on GitHub (Jun 23, 2025):

I tested it and it imported correctly this time. The tombstone sub-transaction wasn't in the split and the account balance looked correct. Great job!

Awesome, thanks for testing it.

<!-- gh-comment-id:2997269817 --> @youngcw commented on GitHub (Jun 23, 2025): > I tested it and it imported correctly this time. The tombstone sub-transaction wasn't in the split and the account balance looked correct. Great job! Awesome, thanks for testing it.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/actual#51344