CSV export loses information

[flooc]

CSV export feature introduced by #287 and PR #292 aim at providing a way to export data as a user-friendly CSV file, similar to Splitwise.
First I'd like to thank every contributor to this feature: I have never used Splitwise, but the CSV export has already been useful to me, even with these issues.

Current Spliit and Splitwise CSV export are very different, both have limitations induced by the same (questionable) objective: exporting as much information as possible with only one column per participant (plus common columns), instead of keeping both payment and shares information separately.
Note this objective has already been questioned by Splitwise users, and will be even harder to defend when/if multi-payer support is implemented (#14).

Briefly, for a value v in a participant (Bob) column:

• Splitwise: v is Bob’s balance implied by the related operation, ie. the possibly negative debt from the group to Bob, computed as paid_by_user - user_share.
• Spliit: abs(v) is Bob’s share (with a notable exception), while its sign indicates wether Bob is the payer (v>0) or not (v<0).

Here are tests exports from both Spliit and Splitwise, for the exact same sequence of operations:

Spliit:

Date	Description	Category	Currency	Cost	Is Reimbursement	Split mode	Alice	Bob	Carol	Dave
2025-05-16	Altruist payment	General	€	20	No	Evenly	0	-10	-10	0
2025-05-17	By amount	Payment	€	40	No	Unevenly – By amount	20	-10	-10	0
2025-05-17	By percentage	General	€	40	No	Unevenly – By percentage	-20	10	-10	0
2025-05-17	By shares	General	€	50	No	Unevenly – By shares	-10	-30	10	0
2025-05-17	Income	General	€	-30	No	Evenly	-10	10	10	0
2025-05-17	Reimbursement Bob→Carol	General	€	10	Yes	Evenly	0	0	-10	0
2025-05-17	Self-payment	Payment	€	100	No	Evenly	0	100	0	0

Splitwise:

Date	Description	Category	Cost	Currency	Alice	Bob	Carol	Dave
2025-05-16	Altruist payment	General	20	USD	20	-10	-10	0
2025-05-16	By amount	General	40	USD	20	-10	-10	0
2025-05-16	By percentage	General	40	USD	-20	30	-10	0
2025-05-16	By shares	General	50	USD	-10	-30	40	0
2025-05-17	Income	General	30	USD	-20	10	10	0
2025-05-17	Bob paid Carol	Payment	10	USD	0	10	-10	0
2025-05-17	Self-payment	General	100	USD	0	0	0	0
2025-05-17	Total balance			USD	-10	0	10	0

I spent some time confronting both approaches to the main properties and possibilities we could expect from a CSV export.
First, for each operation, we should be able to know who paid what, who owes what, etc., an operation being either:

• a classical expense: Alice pays 40, somehow shared between Bob, Carol and herself.
• an "altruist payment": Alice pays 20, of which 10 for Bob, 10 for Carol, nothing for herself.
• a self-payment: Bob pays 100, for himself.
• an income: a negative payment.
• a reimbursement: an internal transfer of money, which is not an expense (no money left the group; no impact on participant shares, only on their balances).
  The exported CSV should allow to easily compute, on a spreadsheet editor, even for a subset of the operations (I do know all of these values are already provided in Spliit web UI for the whole operation set):
• the total group expenses (how much did this trip cost in total)
• a participant share (how much did this trip cost me)
• a participant balance (how much do I owe)

Now to summarize, here is how well Spliit and Splitwise are doing, with the objective of not losing information and to compute these values:

	Spliit	Splitwise	Comment
Classical expense	🟢	🟢
Altruist payment	🔴	🟢	Not counted in payer balance
Self-payment	🟢	🔴	Not counted in payer share
Income	🟢	🟠
Reimbursement	🟠	🟠

🔴: Information is lost due to the way payment and sharing information is merged. Can’t be fixed without breaking the semantic, making computations a nightmare.
🟠: Information is lost, but a minor change could fix it.
🟢: Ok.

All issues can be observed on the examples. For Spliit:

• Alice has no share (by definition) in the altruist payment, so there is no way to know which of Alice and Dave did pay.
• There is no way of knowing the reimbursement came from Bob. This can be fixed easily by setting Bob’s value (to 10 here), which would be consistent. The cost should be 0: an internal reimbursement is not a cost.
  This would make the Is Reimbursement column useless, and the total group expense computation straightforward.

This last point could be fixed easily now. Then one might take some time to discuss wether to keep this format, adopt Splitwise’ for interoperability and for its different limitations, or put back the whole information with two columns per participant.