After migrating data from SplitPro V1 to V2, historical data integrity is broken

[Soulplayer]

Describe the bug

After migrating data from SplitPro V1 to V2, historical data integrity is broken:

1. Balances that were “Settled up” in V1 are no longer settled in V2. V2 shows a large outstanding total (“You owe €950.06”) and multiple per-person debts, while V1 shows everyone as “Settled up”.
2. Groups list differs between V1 and V2. A group that is active in V1 appears missing or moved to Archived in V2 (archived count increases).
3. “Settle up” fails in V2. Clicking Save in the settle-up modal triggers a toast “Error while saving expense” and no settlement is created.
4. Migration logs show settlement records being skipped, which likely explains the incorrect balances and may contribute to the settle-up save failure.

To Reproduce

A) Incorrect balances after migration

1. Start from a SplitPro V1 dataset where all participants show “Settled up” in Balances.
2. Migrate the same dataset to V2 (using the documented migration/upgrade path).
3. In V2, go to Balances.
4. Observe that V2 shows “You owe €950.06” and multiple per-person balances, despite V1 being fully settled.

B) Groups moved/missing after migration

1. In V1, go to Groups and note the active groups list:
   • 2026 Vriendenweekend
   • 2027 Vriendenweekend
   • Glenn - Sander
   • Archived count: 1
2. In V2, go to Groups.
3. Observe that only these remain active:
   • Glenn - Sander
   • 2027 Vriendenweekend
   • Archived count becomes 2 (unexpected change; 2026 Vriendenweekend appears missing or moved).

C) Settle up fails (cannot create settlement expense)

1. In V2, open Balances.
2. Click a participant you owe (example: degrooteglenn).
3. Choose Settle up (example modal shows: “You pay degrooteglenn”, group: “Vriendenweekend 2025”, amount: €331.59).
4. Click Save.
5. Observe toast: “Error while saving expense” and the settlement is not saved.

Expected behavior

• Migration preserves groups, memberships, expenses, and settlements.
• If V1 shows everything settled, V2 should show the same (or at least identical computed balances).
• “Settle up” should create the settlement expense and update balances.
• Group archived/active status should not change unless explicitly migrated.

Screenshots

• V1 Balances: all users show “Settled up”
• V1 Groups: active groups include 2026 Vriendenweekend, 2027 Vriendenweekend, Glenn - Sander, archived 1
• V2 Balances: “You owe €950.06” and per-person mismatches
• V2 Groups: active list differs, archived becomes 2

- V2 Settle up modal example before saving - V2 error toast: **“Error while saving expense”**

App version

• V1: v1.5.8
• V2: latest

Desktop (please complete the following information)

• OS: Windows (build 26200)
• Browser: Chrome 142.0.7444.235

Migration logs show skipped settlements

During the V1 → V2 migration, the migration tool skips settlement records, which likely explains why V2 shows large outstanding balances even though V1 was fully settled.

Log excerpts (many similar lines):

[SKIP] c6880772-00a7-4421-95c1-a3edfb9f5a94 (amount: 8448 EUR): unexpected sign convention. Settlement: -8448, Calculated: -8448
[SKIP] eb990e46-ed3b-4cda-9ea9-ac905c4fa7cf (amount: 8448 EUR): unexpected sign convention. Settlement: -8448, Calculated: -8448
[SKIP] a5fd7da2-0c17-4b0b-b3b3-fdc99778b9f3 (amount: 1205 EUR): balance mismatch (likely partial settlement). Settlement: -1205, Calculated: 0
[SKIP] d7e70fbb-bca9-4d8c-acba-2446fcd0a93d (amount: 2389 EUR): balance mismatch (likely partial settlement). Settlement: -2389, Calculated: -10837
[SKIP] 7cc528cf-df7e-4d0d-abd1-b08b45302e1a (amount: 2389 EUR): balance mismatch (likely partial settlement). Settlement: -2389, Calculated: -10837
[SKIP] a740755f-40d6-444f-8442-5526b86d2714 (amount: 2389 EUR): unexpected sign convention. Settlement: -2389, Calculated: -2389
[SKIP] 179b885e-5514-4432-bcf0-160880f147ce (amount: 42968 EUR): balance mismatch (likely partial settlement). Settlement: 42968, Calculated: 10626
[SKIP] bca5b747-47d0-4e08-8011-20ef0a0530b6 (amount: 15530 EUR): balance mismatch (likely partial settlement). Settlement: -15530, Calculated: -10837
[SKIP] bf30d4f1-9e9b-461b-b7cc-0cd84feaa0c4 (amount: 15006 EUR): balance mismatch (likely partial settlement). Settlement: 15006, Calculated: 0
[SKIP] 830a337d-1616-4f5c-8e12-90a57769d5a6 (amount: 33821 EUR): balance mismatch (likely partial settlement). Settlement: -33821, Calculated: 0
[SKIP] 7b7f4fd0-12db-41d7-8015-5c7e3bfc3dd6 (amount: 5222 EUR): balance mismatch (likely partial settlement). Settlement: -5222, Calculated: -10837
[SKIP] 148ef2a2-30b3-403a-91d5-8f107876fd63 (amount: 24256 EUR): balance mismatch (likely partial settlement). Settlement: -24256, Calculated: 0
[SKIP] 589ad8e5-7842-4397-bcc8-837f3129f9a6 (amount: 215 EUR): balance mismatch (likely partial settlement). Settlement: 215, Calculated: 0
[SKIP] d6fc2460-d256-4bc2-9c72-79411565698c (amount: 15667 EUR): balance mismatch (likely partial settlement). Settlement: -15667, Calculated: 0
[SKIP] 5ac6bd89-95df-4872-81f2-5983fb7a47df (amount: 35461 EUR): balance mismatch (likely partial settlement). Settlement: -35461, Calculated: 0
[SKIP] e5b7fba3-b81a-49c7-847a-30af27ba9ceb (amount: 11264 EUR): balance mismatch (likely partial settlement). Settlement: -11264, Calculated: 0
[SKIP] b9f4e823-08e4-443f-832f-e9c728702cee (amount: 7092 EUR): balance mismatch (likely partial settlement). Settlement: -7092, Calculated: 0
[SKIP] c5950ab1-d54a-4e57-bc54-a8416a746bc1 (amount: 14448 EUR): balance mismatch (likely partial settlement). Settlement: -14448, Calculated: 0
[SKIP] 74c6b0f7-c247-4dff-9a4d-57d6eb6af4d7 (amount: 4725 EUR): balance mismatch (likely partial settlement). Settlement: 4725, Calculated: 0
[SKIP] aeec5ad9-9264-4b38-ba6a-d3f67c60c065 (amount: 269 EUR): balance mismatch (likely partial settlement). Settlement: 269, Calculated: 0
[SKIP] cd1abea9-9b4d-45b0-8f80-07cd1829c7c0 (amount: 18750 EUR): balance mismatch (likely partial settlement). Settlement: -18750, Calculated: -10837
[SKIP] 49095682-9629-4205-b78c-1b21b0334003 (amount: 18750 EUR): balance mismatch (likely partial settlement). Settlement: -18750, Calculated: 0
[SKIP] 23034b37-8200-4755-a00c-65905636833b (amount: 18750 EUR): balance mismatch (likely partial settlement). Settlement: -18750, Calculated: -2389
[SKIP] 1adfbe8d-1a4d-4591-a534-9cb00ba3830e (amount: 6250 EUR): balance mismatch (likely partial settlement). Settlement: -6250, Calculated: -10837
[SKIP] 92d5b1f9-454f-4f5e-a61d-a76bbc3a2684 (amount: 8074 EUR): balance mismatch (likely partial settlement). Settlement: -8074, Calculated: -10837
[SKIP] 93149a58-7b53-4e8a-b29b-e150fcefb0ad (amount: 18750 EUR): balance mismatch (likely partial settlement). Settlement: -18750, Calculated: 0
[SKIP] 695fb7b9-7537-4c3f-b7a7-dc1efa967550 (amount: 3045 EUR): balance mismatch (likely partial settlement). Settlement: -3045, Calculated: 0
[SKIP] 6c9d9ab6-6882-4069-878d-8f3e41e7d70f (amount: 3200 EUR): balance mismatch (likely partial settlement). Settlement: -3200, Calculated: 0
[SKIP] e3d9307f-7809-4a18-95f4-f51b1925266a (amount: 18814 EUR): balance mismatch (likely partial settlement). Settlement: -18814, Calculated: -2389
[SKIP] c4e67019-19a2-413e-ac6a-c0d659b31819 (amount: 9100 EUR): balance mismatch (likely partial settlement). Settlement: -9100, Calculated: -2389
[SKIP] 8d629943-f65d-4c41-ae49-38c3dd5cb5ec (amount: 1205 EUR): balance mismatch (likely partial settlement). Settlement: 1205, Calculated: 0
[SKIP] 28cb87a3-88f7-4640-b399-cd748db01d5a (amount: 33198 EUR): balance mismatch (likely partial settlement). Settlement: 33198, Calculated: 0
[SKIP] 15cfd6a8-b4bf-4995-8e7b-c0f633b79062 (amount: 33197 EUR): balance mismatch (likely partial settlement). Settlement: 33197, Calculated: -10837
[SKIP] a59f1c8d-871e-49db-af84-ac408187415b (amount: 18750 EUR): balance mismatch (likely partial settlement). Settlement: 18750, Calculated: -2389
[SKIP] 6a09fdb6-1bab-4687-8df8-4e7fdf81ba31 (amount: 14448 EUR): balance mismatch (likely partial settlement). Settlement: 14448, Calculated: 0
[SKIP] 6321475c-9a71-4cec-9252-b003ff74e4ad (amount: 14447 EUR): balance mismatch

[Soulplayer]

Could this be as simple as a mismatch between “,” and “.”? In our country we use a comma as the decimal separator—for example, €94,50 means ninety-four euros and fifty cents.

[Silther]

Could this be as simple as a mismatch between “,” and “.”? In our country we use a comma as the decimal separator—for example, €94,50 means ninety-four euros and fifty cents.

I think that sounds reasonable, I never had 2000€ expenses but many 20,00€ expenses

[Soulplayer]

Yeah I think this is the issue. There were some large transactions but not this many…

[krokosik]

Oh my this looks rough. It seems I did not really phrase the migration docs and logs carefully enough.

It all started with issue #541 where a user reported that their interpersonal or group balances were changed significantly.

This was expected, because of the changes to group balances and the removal of total balance tables, as outlined in detail in the docs and issue comments.

In order to ease the burden of manually adjusting the balances, I figured we could implement a heuristic for automatic migration, where we check a settlement and compare it with balances at the given date. If there is an exact match, we assume that it was supposed to go into over all of these balances (this person + shared groups). So a mismatch occuring should actually be more common than not, because that simply means that the heuristic is not enough and it is very simple.

What is weird to me though, is the total balance being changed! That's super worrying and makes me consider actually removing the migration altogether, because this should not happen.

For the manual migration, I guess it would mean deleting the current settlement expenses and creating new ones inside of groups. I could make it simpler by adding expense filtering, altough pasting the ID into the URL from migration logs should also do the trick.

@Silther A full on UI editing solution would be pretty convoluted, as it would involve splitting a settleup into multiple expenses.

@Soulplayer decimal separator does not matter, as we store all amounts as bigints inside of the db. That's why you see huge values in the logs. The error toast is odd, could you check the console logs?

I would like to get some feedback whether you think the migration makes sense or should I just remove it to reduce confusion since it won't work most of the time?

[Soulplayer]

If it does not work then you should remove it and explain more how to fix the resolving issues. I want to migrate to v2 but now I cannot do this because of the expenses that remain. Is there a way I can do this? I don’t really understand what you mean with:

For the manual migration, I guess it would mean deleting the current settlement expenses and creating new ones inside of groups. I could make it simpler by adding expense filtering, altough pasting the ID into the URL from migration logs should also do the trick

[Silther]

A full on UI editing solution would be pretty convoluted, as it would involve splitting a settleup into multiple expenses.

It was more meant as a way to replace the old settle-ups with new ones, but without losing the historical data, when the settle up really happened. So being able to edit settle-ups like balances would be nice. (change the time they happened, ...)

For the manual migration, I guess it would mean deleting the current settlement expenses and creating new ones inside of groups.

Similar to this but without needing to delete and recreate old expenses.

[Soulplayer]

I use it mostly on weekends with friends. Since everything is settled I just removed my database and started fresh.

[Silther]

You shouldn't close the issue as the underlying problem is not fixed yet.

[william-barros-costa]

I was having the problem of my groups all being settled up when the version changed so I just created new groups and compiled what each person was owing me/me owing them. I will leave the tutorial here to help those who might require the same procedure:

1. Go to splitpro on your browser and open console;
2. Go to the group you need to do the calculations at;
3. All the expenses will now appear on the console as expensesQuery.data;
4. Open and right click on the number (in this case 6) and Store as global variable;

5. It should now appear as temp1
6. Paste the following code and download the data as json

const arr = [1, 2, 3];
const blob = new Blob([JSON.stringify(temp1, null, 2)], { type: 'application/json' });
const url = URL.createObjectURL(blob);
const a = document.createElement('a');
a.href = url;
a.download = 'data.json';
a.click();
URL.revokeObjectURL(url);

7. Install jq utility and run jq '[.[] | .expenseParticipants[] | select(.userId == 1656 or .userId == 1657)] | group_by(.userId) | map({userId: .[0].userId, total: map(.amount) | add})' data.json
   Note: Substitute userId by your users and add/remove as needed
8. You will receive a list of what you are owed as positive and what you owe as negative. It does not have decimal case so 1800 -> 18,00 .
9. You can then put these expenses on a new group, settling up the old one

[Silther]

I too had an idea to help with the migration issue explained in #587.