Feature Request: Align CSV Export with JSON: Add Sorting and Missing 'Paid By' Columns

[Jessica1213]

Fixes #455

• Add a column 'Paid By', which displays the descriptive name of the paying participant.
• Implement consistent sorting logic to match the UI and JSON export: expenseDate (asc), createdAt (asc)

[Uli-Z]

Thanks a lot for this PR, @Jessica1213 – adding the “Paid By” column makes the CSV export much more useful and it’s great that you started this.

While testing this, I realised that the current CSV format is still quite hard to work with in practice. The per‑participant columns don’t really represent a clear, directly usable value (they are more like signed shares), and it’s difficult to answer the usual question “who owes whom how much?” from the export alone.

I’d love to take this one step further and make the CSV export express per‑expense saldo per participant instead:

• For each expense, the participant columns would show the net effect of that single expense on each person’s balance.
• For the paying participant (Paid By):
  saldo = totalAmount - participantShareAmount
  → how much they effectively advance for others.
• For all other participants:
  saldo = -participantShareAmount
  → how much they owe the payer for that expense.
• The sum of all participant saldos for a given expense is always 0, which makes it very easy to aggregate in Excel or similar tools.

I’ve spiked this approach in my fork in the branch
feature/csv-saldo-export here:
https://github.com/Uli-Z/spliit-room/tree/feature/csv-saldo-export

If this direction makes sense to you and the maintainers, I’d be happy to turn this into a proper follow‑up PR (or you can cherry‑pick the change into this one).

[bramvonk]

@Uli-Z: please see this issue: #342 .

In the end it seems to be having to choose between 3 evils:

• not being able to see the net effect of the expense
• not being able to see the costs for each participant
• needing 2 columns for each participant

[Uli-Z]

@bramvonk

Thanks for the link — that thread really convinced me that the current CSV format needs an adjustment. Jessica’s PR addresses the main shortcomings of the current “signed share” export.

Together with my proposed patch (https://github.com/Uli-Z/spliit-room/tree/feature/csv-saldo-export) this becomes a very usable solution. I tested the approach by entering the edge cases discussed in #342 into a group and exporting the data as CSV in the new format (Jessica’s PR + my patch). To demonstrate that no information is lost and everything can be reconstructed, I added a tiny Python script that re-analyzes the exported CSV. You can try it yourself in the branch above:

• test-cases.csv
• scripts/convert-csv-to-sentences.py

By the way, I made one small change to my suggestion: beyond a reimbursement-related bug, it became clear that the is_reimbursement column is fully redundant once reimbursements use Cost=0 across the board.

Script output (evidence the CSV is complete and consistent)

2025-05-16 – Altruist payment: Alice paid $20.00

• Paid for: Bob=$10.00, Carol=$10.00
• Share distribution: Alice=0, Bob=1, Carol=1, Dave=0
• Net expenses: Alice=$0.00, Bob=$10.00, Carol=$10.00, Dave=$0.00
• Per-expense balance: Alice=+$20.00, Bob=-$10.00, Carol=-$10.00, Dave=$0.00

2025-05-17 – By amount: Alice paid $40.00

• Paid for: Alice=$20.00, Bob=$10.00, Carol=$10.00
• Share distribution: Alice=2, Bob=1, Carol=1, Dave=0
• Net expenses: Alice=$20.00, Bob=$10.00, Carol=$10.00, Dave=$0.00
• Per-expense balance: Alice=+$20.00, Bob=-$10.00, Carol=-$10.00, Dave=$0.00

2025-05-17 – By percentage: Bob paid $40.00

• Paid for: Alice=$20.00, Bob=$10.00, Carol=$10.00
• Share distribution: Alice=2, Bob=1, Carol=1, Dave=0
• Net expenses: Alice=$20.00, Bob=$10.00, Carol=$10.00, Dave=$0.00
• Per-expense balance: Alice=-$20.00, Bob=+$30.00, Carol=-$10.00, Dave=$0.00

2025-05-17 – By shares: Carol paid $50.00

• Paid for: Alice=$10.00, Bob=$30.00, Carol=$10.00
• Share distribution: Alice=1, Bob=3, Carol=1, Dave=0
• Net expenses: Alice=$10.00, Bob=$30.00, Carol=$10.00, Dave=$0.00
• Per-expense balance: Alice=-$10.00, Bob=-$30.00, Carol=+$40.00, Dave=$0.00

2025-05-17 – Income: Bob earned $30.00

• Distributed to: Alice=$10.00, Bob=$10.00, Carol=$10.00
• Share distribution: Alice=1, Bob=1, Carol=1, Dave=0
• Net expenses: Alice=$10.00, Bob=$10.00, Carol=$10.00, Dave=$0.00
• Per-expense balance: Alice=+$10.00, Bob=-$20.00, Carol=+$10.00, Dave=$0.00

2025-05-17 – Reimbursement Bob→Carol: Bob paid $10.00

• Paid for: Carol=$10.00
• Share distribution: Alice=0, Bob=0, Carol=1, Dave=0
• Net expenses: Alice=$0.00, Bob=$0.00, Carol=$0.00, Dave=$0.00
• Per-expense balance: Alice=$0.00, Bob=+$10.00, Carol=-$10.00, Dave=$0.00

2025-05-17 – Self-payment: Bob paid $100.00

• Paid for: Bob=$100.00
• Share distribution: Alice=0, Bob=1, Carol=0, Dave=0
• Net expenses: Alice=$0.00, Bob=$100.00, Carol=$0.00, Dave=$0.00
• Per-expense balance: Alice=$0.00, Bob=$0.00, Carol=$0.00, Dave=$0.00

Sum of all balances: $0.00
Total per participant spending:

• Alice: $40.00
• Bob: $150.00
• Carol: $30.00
• Dave: $0.00
  Sum of participant spending: $220.00
  Total group spending: $220.00

I believe this also closes your issue #471.

[Jessica1213]

Hi @Uli-Z,

Thanks again for the detailed analysis and for sharing your work in the feature/csv-saldo-export branch. I appreciate your initiative in looking to improve the practical usability of the CSV export.

I agree that converting the output to a "per-expense saldo" format would be a valuable functional enhancement that makes aggregation much easier for users.

However, to ensure a smooth review process and adhere to the Single Responsibility Principle, I need to keep the scope of this PR #455 strictly focused on the original goal: the essential bug fix for sorting and basic column alignment with JSON export.

We should proceed to merge my current PR first independently (the sorting fix and alignment).

I strongly recommend your feature/csv-saldo-export changes be opened as a separate, dedicated follow-up PR.

You can base your new branch on the changes from this PR. This approach ensures a cleaner git history and clear accountability for each set of changes.

Thanks for your understanding!