[Bug]: YNAB4 import leads to malformed split transactions #1470

Open
opened 2026-02-28 19:44:23 -06:00 by GiteaMirror · 4 comments
Owner

Originally created by @mullermn on GitHub (Oct 4, 2024).

Verified issue does not already exist?

  • I have searched and found no existing issue
  • I will be providing steps how to reproduce the bug (in most cases this will also mean uploading a demo budget file)

What happened?

After migrating to Actual from a large YNAB4 install I found that my split transactions did not show up correctly:
image

There is evidence that the data was imported behind the scenes but is not displayed:
image

I suspect this is because YNAB4 [can] tracks payees for split transactions solely at parent transaction level, and does not require payees for the splits, while Actual computes the parent payee name from that of the splits?

This doesn't break the app but introduces the dangerous gotcha that these transactions will not show up in reports and filters based on Payee name.

Split transfers do not seem to be affected:
image

The repair split transactions tool seems to handle this correctly, but ideally the situation should not exist in the first place:
image

Where are you hosting Actual?

Pikapods

What browsers are you seeing the problem on?

Desktop App (Electron)

Operating System

Mac OSX

Originally created by @mullermn on GitHub (Oct 4, 2024). ### Verified issue does not already exist? - [X] I have searched and found no existing issue - [X] I will be providing steps how to reproduce the bug (in most cases this will also mean uploading a demo budget file) ### What happened? After migrating to Actual from a large YNAB4 install I found that my split transactions did not show up correctly: ![image](https://github.com/user-attachments/assets/ddecacc9-a01a-4386-857f-2fd5903ec4ba) There is evidence that the data was imported behind the scenes but is not displayed: ![image](https://github.com/user-attachments/assets/668ad0fd-5934-4706-8c3f-8e706b4ea0a0) I suspect this is because YNAB4 [can] tracks payees for split transactions solely at parent transaction level, and does not require payees for the splits, while Actual computes the parent payee name from that of the splits? This doesn't break the app but introduces the dangerous gotcha that these transactions will not show up in reports and filters based on Payee name. Split transfers do not seem to be affected: ![image](https://github.com/user-attachments/assets/319bb9b5-c6c7-42d8-a8d0-9808ccf4721d) The repair split transactions tool seems to handle this correctly, but ideally the situation should not exist in the first place: ![image](https://github.com/user-attachments/assets/d8755e23-b823-4944-9654-4f1fb481e11e) ### Where are you hosting Actual? Pikapods ### What browsers are you seeing the problem on? Desktop App (Electron) ### Operating System Mac OSX
GiteaMirror added the bughelp wantedimporters labels 2026-02-28 19:44:23 -06:00
Author
Owner

@MatissJanis commented on GitHub (Oct 4, 2024):

👋 Hi. Could you upload a sample ynab export that we could use to reproduce the issue? Thanks

@MatissJanis commented on GitHub (Oct 4, 2024): 👋 Hi. Could you upload a sample ynab export that we could use to reproduce the issue? Thanks
Author
Owner

@aa-hr commented on GitHub (Oct 7, 2024):

My Budget~100D554C.ynab4.zip

Hi, sorry for the delay. I started by trying to prune down my real budget to produce a real world sample without too much personal data in it but that proves to be borderline impossible due to the size of it, sorry. I have made this one, which is a brand new budget and does demonstrate the visual issue with Payees not showing up on splits.
YNAB4:
image

Actual:
image

The parent transaction in this example DOES seem to show up in filters in Actual, so either I was mistaken about that or that was a consequence of something else in my real budget data (I can't check now, having run the 'fix splits' process). However, I think this visual bug would be worth fixing in its own right as it is a bit ugly and confusing.

I have also created a second transaction (after I took those screenshots) with a transfer as one of the splits. The transfer element seems to get imported correctly, so it looks like the missing behaviour is just to take the payee at parent level in YNAB and apply it to any non-transfer splits.

Edit: Sorry, I am the original reporter, just uploaded this while logged in on a work account by mistake.

@aa-hr commented on GitHub (Oct 7, 2024): [My Budget~100D554C.ynab4.zip](https://github.com/user-attachments/files/17278546/My.Budget.100D554C.ynab4.zip) Hi, sorry for the delay. I started by trying to prune down my real budget to produce a real world sample without too much personal data in it but that proves to be borderline impossible due to the size of it, sorry. I have made this one, which is a brand new budget and does demonstrate the visual issue with Payees not showing up on splits. YNAB4: ![image](https://github.com/user-attachments/assets/443a2f64-3b4b-4ff3-9ddb-f6176914ca03) Actual: ![image](https://github.com/user-attachments/assets/2d977345-bc0e-4d43-abb9-d75a1a115c6d) The parent transaction in this example DOES seem to show up in filters in Actual, so either I was mistaken about that or that was a consequence of something else in my real budget data (I can't check now, having run the 'fix splits' process). However, I think this visual bug would be worth fixing in its own right as it is a bit ugly and confusing. I have also created a second transaction (after I took those screenshots) with a transfer as one of the splits. The transfer element seems to get imported correctly, so it looks like the missing behaviour is just to take the payee at parent level in YNAB and apply it to any non-transfer splits. Edit: Sorry, I am the original reporter, just uploaded this while logged in on a work account by mistake.
Author
Owner

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

I think this is also happening with nynab imports

@youngcw commented on GitHub (Oct 8, 2024): I think this is also happening with nynab imports
Author
Owner

@ppittle commented on GitHub (Jan 16, 2025):

Ran into this issue as well -

From my naïve reading of the application code, it looks like the YNAB4 imported explicitly doesn't support Splits:

function getCategory(id: string) {
    if (id == null || id === 'Category/__Split__') {
      return null;

As @mullermn mentioned, running the Fix Split Transactions tool seems to fix this (it seemed to work for me).

One solution could be update YNAB4 Importer to call tools/fix-split-transactions as the last stage of import?

@ppittle commented on GitHub (Jan 16, 2025): Ran into this issue as well - From my naïve reading of the application code, it looks like the [YNAB4 imported explicitly doesn't support Splits](https://github.com/actualbudget/actual/blob/master/packages/loot-core/src/server/importers/ynab4.ts#L137C3-L138C19): ```typescript function getCategory(id: string) { if (id == null || id === 'Category/__Split__') { return null; ``` As @mullermn mentioned, running the Fix Split Transactions tool seems to fix this (it seemed to work for me). One solution could be update YNAB4 Importer to call [`tools/fix-split-transactions`](https://github.com/actualbudget/actual/blob/master/packages/loot-core/src/server/tools/app.ts#L13) as the [last stage of import](https://github.com/actualbudget/actual/blob/master/packages/loot-core/src/server/importers/ynab4.ts#L364)?
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/actual#1470