Individual balance shows inconsistent transactions when group debt simplification is enabled

[jesusjmma]

Describe the bug

When debt simplification is enabled for a group with 3 or more members, the total balance shown between two individual users can be correct, while the expense lines displayed in their individual balance do not add up to that total.

Split Pro includes group expenses involving both users as individual expense lines, but it does not represent the effect of other group expenses that affect the simplified debt between those users.

As a result, the individual balance becomes internally inconsistent: the displayed total balance reflects the simplified group debts, while the listed transactions reflect the original unsimplified expenses.

This also affects exported data, since calculating the balance from the exported transaction lines produces a different result from the total balance shown by Split Pro.

To Reproduce

Consider a group with three members: A, B, and C.

1. Create a group with members A, B, and C.

2. Add an expense of €120:

   • Paid by A.
   • Split equally between A, B, and C.
   • Therefore, B owes A €40 and C owes A €40.

3. Add another expense of €50:

   • Paid by B.
   • Split equally just between B and C.
   • Therefore, C owes B €25.

4. Check the individual balance between A and B with debt simplification disabled.

   • The total balance correctly shows that B owes A €40.
   • The expense lines also show that B owes A €40.
   • The transaction lines and total balance therefore match.

5. Enable debt simplification for the group.

6. Check the individual balance between A and B again.

   • The simplified group debts correctly result in B owing A €15.
   • The total balance between A and B correctly shows €15.
   • However, the expense lines still show the original €40 debt from B to A; and no other lines are displayed to represent the effect of the other group expenses that have been simplified away.

7. The individual balance therefore contains:

   • Total balance: B owes A €15
   • Sum of displayed expense lines: B owes A €40

The displayed transactions no longer match the displayed total balance.

The inconsistency becomes even clearer after settling the simplified debt:

8. Register a €15 payment from B to A.

9. Split Pro correctly updates the total balance between A and B to €0.

10. However, the individual transaction history now effectively contains:

    • B owes A €40 from the original group expense.
    • B paid A €15.
    • Net result according to the displayed transaction lines: B still owes A €25.

11. The displayed total balance is nevertheless €0.

Therefore, the total balance and the transaction history represent two different accounting states.

Expected behavior

The transaction lines shown in an individual balance should always be consistent with the total balance displayed between those two users.

A possible approach would be the behavior used by Splitwise:

• Expenses belonging to a group should not be added as individual transaction lines between two specific users.
• Instead, the individual balance should contain a single entry representing that group and the current balance attributable to it between the two users.
• That group balance should be recalculated whenever expenses, payments, or debt simplification within the group change.
• Expenses or debts created directly between the two users outside the group should continue to appear as individual transaction lines.

For the example above, with debt simplification enabled, the individual balance between A and B should represent the group's current €15 balance rather than showing the original €40 expense as if it were still the effective debt between them.

After B pays the simplified €15 debt, both the displayed total balance and the transactions represented in the individual balance should consistently result in €0.

Screenshots

Not available, but the issue can be reproduced by following the steps above.

App version

• Split Pro: v2.1.5
• Git commit: 7e6a401212ce6c7bb109ff69adb1784a3fd6318a
• Deployment: Docker Compose
• Docker image: ossapps/splitpro:latest

Desktop (please complete the following information):

• OS: Linux x86_64
• Browser: Google Chrome
• Version: 152.0.7977.64 (Official Build)
• User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/152.0.0.0 Safari/537.36

Smartphone (please complete the following information):

• Device: Multiple / device-independent
• OS: Multiple
• Browser: Multiple
• Version: N/A

The same behavior occurs on smartphones because the issue is not device-specific; it is caused by how Split Pro calculates and represents individual balances when group debt simplification is enabled.

Additional context

The total balance itself appears to be calculated correctly. The problem is specifically that the transaction lines displayed for the individual relationship do not represent all the effects of the group's simplified debts.

This makes the individual balance misleading because the total cannot be reconstructed from the transactions displayed underneath it.

It also creates problems when exporting Split Pro data for external analysis: summing the exported expense/payment lines can produce a different balance from the total balance reported by Split Pro.

I would recommend using the same approach as Splitwise, where group expenses are not represented as individual transactions between two users, but rather as a single entry reflecting the current balance attributable to the group. I believe this would ensure consistency between the total balance and the individual transaction history.

[krokosik]

I agree, the thing is that at the beginning some design choices were made (not by me) which prioritized listing all balances with a friend over group functionality. This has led to many issues and finally to a breaking v2 update.

I considered following splitwise, but in the end decided to stick with the familiarity of the v1 behaviour and know that there are many users who got used to the current flow and prefer it. If you have some idea on how to cleanly support both workflows, I'm open to that