UX: "Split by Amount" rounding errors cause frustrating off-by-one-cent validation failures

[aChrisYouKnow]

Summary

When splitting an expense unevenly by exact amounts, rounding often causes the sum of entered amounts to differ from the expense total by $0.01. The current validation message is unhelpful, forcing users to switch to an external calculator to find and fix the discrepancy. This is the biggest source of frustration reported by users during group trips.

Steps to Reproduce

1. Create an expense for $524.34 with five participants.
2. Select "Unevenly - by amount".
3. Enter amounts from a receipt that sum to slightly more than the total. For example:
   • User A: 110.11
   • User B: 209.74
   • User C: 104.87
   • User D: 89.14
   • User E: 10.49
   • Result: The total is $524.35, which is $0.01 over the expense amount.
4. Alternatively: Enter the first four amounts above and let the app auto-calculate User E's share as $10.48. Then delete that auto-filled value and manually enter 10.49.

Current Behavior

The app only shows a generic error:

"Sum of amounts must equal the expense amount"

It does not indicate:

• The current sum of entered amounts
• How much the sum is over or under by
• Which direction to adjust

Screenshot of the rounding issue with these exact values:

Example of the current state after deleting User E's auto-filled value:
Note, it does not fill itself in with the remainder once it has been deleted.

Desired Behavior

The app should make resolving rounding discrepancies effortless. Two potential solutions:

Option 1: Improve the error message
Include the exact discrepancy in the validation error. For example:

"Sum of amounts is $524.35, which is $0.01 more than the expense amount of $524.34."

This allows the user to simply adjust one split (e.g., change User E from 10.49 to 10.48) to resolve the error.

Option 2: Show remaining balance as greyed-out placeholder text
When a split field is cleared, display the remaining unpaid amount as greyed-out placeholder text. For instance, if the first four amounts above are entered and User E's field is cleared, the placeholder should show 10.48 (the exact remainder needed to balance the expense).

If multiple fields are empty, the remainder should be divided equally between them and shown as placeholders in each. For example, if the remaining balance is $10.00 and two users clear their fields, both should show a greyed-out $5.00.

In all cases, this text must act as a true placeholder (not a pre-filled default value), so users can type their own amount directly without having to delete the suggestion first.

This preserves the auto-calculation hint while keeping manual entry frictionless.

Mockup of desired placeholder behavior:

This frustration has come up multiple times, and removing it would take away the biggest complaint I get when suggesting a group use this app for group trips. Thanks to all contributors for making such an awesome app!

[BastiOfBerlin]

Could you please specify the release version you used?

[aChrisYouKnow]

I assume 1.22.0 as we were using the PWA from https://spliit.app/ on an August 15th-21st trip. Is there a way to see from the PWA what current version is being run on spliit.app? I'd say the same issue has come up on half of the trips I've used Spliit for over the last two years, so very rough estimate, 4 of 8 group trips. Should have opened the issue sooner, but finally got around to it. It always seems to frustrate people when they need to go do their own math to figure out why they are getting the error.

[aChrisYouKnow]

I'll add that the uneven splits usually come from restaurants and using the tab app to split receipts. When going to enter those totals into spliit, sometimes rounding results in it being off by a cent or two, or a fat finger enters one value wrong, and that's where the problem comes in

[BastiOfBerlin]

I was asking because this was fixed in #562 but might not have landed when you experienced the issue. Unfortunately, I have no idea which version runs on the website.
Are you able to set up a local app in order to reproduce your case with the current version?

[aChrisYouKnow]

I had a chance to spin up a local version and the issue persists. I ran the main branch as of Sept 2 2026, the branch tip being commit ae35cd6, a little ahead of v1.23.1.

The issue is reproduced by deleting the individual uneven splits. If you just edit them, the last split remaining is the correct remainder and it calculates nicely. However, once you delete the values (for example, you edit a value, make a mistake and delete it to correct said mistake. Or if you are about to paste your own values in and you decide to clear the existing values out first), you can't get the remainder calculation to return, and that is where I have seen things get frustrating for friends/family using spliit.

This would be solved by either of my two proposed solutions above.

The most useful would probably be just including how far off of the total the user is in the red error message of "Sum of amounts must equal the expense amount" to add an additional message of "sum of splits is $_.__ above/below the expense total"

The alternate would be light text showing the remaining sum in each split box even after the user has deleted the text there. I.e any blank split box will show the remainder calculation.

Edit: updated some of the text for clarity