Spoken Group Bill Splitting
After a group dinner or trip, state the total and exceptions aloud to get each person’s itemized share and a payment link immediately.
After a group dinner, shared ride on a trip, or household purchase, the hardest part is usually not the total but the exceptions: one person did not drink, another joined only for the latter half, and someone else paid upfront. When everyone opens a spreadsheet to fill in numbers, the awkwardness can turn into a long chain of follow-up questions.
The person who paid simply says a complete sentence, such as: “Dinner was 680. I paid. Xiaoli did not drink, so split the alcohol among the other three.” The product identifies the amount, payer, participants, and exception items from the spoken request, then turns uncertainty into one specific question, such as: “How much was the alcohol?” Once confirmed, it immediately breaks the bill down for each person.
Each participant receives their items, amount due, and a payment link. If someone questions a split, they can open the bill to see the basis for the calculation—such as “did not drink” or “rode only half the trip”—rather than seeing only a final number. Payment status returns to the same bill, so the person who paid does not have to chase each person in a group chat.
The first version covers RMB amounts, fixed participant lists, and common per-person or per-item exceptions. It does not guess who should pay for what or replace complex reimbursement rules. The point is to turn one clearly stated sentence into a split everyone can understand immediately.
Why now
As observed on August 3, Finamie ranked 10th in Product Hunt’s new-product feed, and its page promotes recording expenses by voice and receiving instant insights. S1 That makes “say it once and log it” easier for users to compare, while highlighting the unresolved need to manually enter exceptions in shared bills.
Target user
The primary user is the person who pays upfront for a group dinner or short trip, especially when exceptions emerge just as everyone is about to leave. At that point, people are in a hurry, and rebuilding a spreadsheet or asking about each item one by one is easy to postpone. It also suits stable shared-household groups, where members and responsibility for items often vary. The value is confirming the rules on the spot and keeping the basis for payment on the same bill.
Minimal entry point
Start on the web with MediaRecorder to capture short audio; it has broad support across mainstream browsers. S2 After transcription, extract only the total, currency, payer, participants, items, and exclusion rules. Store the data as a structured bill rather than letting the model calculate final amounts directly. The rules engine supports only equal splits, specified amounts, item exclusions, and partial participation. When a required field is missing, generate one specific follow-up question. The confirmation page shows the original words, parsed result, and per-person calculation; edits trigger an immediate recalculation. Payment links initially lead to a shared bill page with the payer’s payment QR code. Both sides confirm payment status; the first version does not integrate fund settlement.
Punching above its weight
Early users are most likely to come from travel groups, shared-household groups, and tabletop-game organizers. Use short videos built around real, long spoken requests, showing that the system asks only for the missing detail: “How much was the alcohol?” Participant bill pages should open without registration, so payers can review a group link while the organizer naturally drives one round of sharing. Build searchable templates around exceptions such as “someone did not drink” and “rode only half the trip.”
Competitors & gaps
- SplitwiseGoogle
- Splitwise already supports groups, advances, equal and unequal splits, and calculations by percentage or shares. Its paid features also include receipt scanning, itemized allocation, currency conversion, and transaction import. S3 Its ledger, balance, and settlement flows are mature, and users can review and edit past expenses. The existing flow still requires users to create an expense, then choose the payer and split method. Itemized receipt allocation works well when working from a receipt, but it does not interpret spoken exceptions for the organizer. Its public features also do not show a single targeted follow-up for a missing condition. People typically see a balance and expense record, then must work out for themselves why they owe a particular item. The opening is spoken bill creation plus an explanation layer, not rebuilding a full balance system. If parsed results can be exported, the product can coexist with Splitwise.
- QuassamaGoogle
- Quassama already combines voice expense entry, group expenses, percentage splits, receipt recognition, and balance calculations in one product. S4 It shows that speaking an expense and splitting a group bill are already directly adjacent product categories. Its public pages emphasize capturing amounts and details by voice, and show 50/50 and proportional splits. They do not show a single sentence identifying the payer, participants, and excluded items at once, nor do they show asking only for the missing condition when the alcohol total is absent. The gap is therefore narrow: Chinese relational references and exception rules. The product should not expand into a general-purpose voice finance assistant. If it can only record a single expense such as “dinner was 680,” its differentiation disappears immediately. It must also use expandable calculations to prove the parsed result, or users will return to manual splitting.
How it makes money
Basic bill splitting is free. Charge a monthly subscription to frequent trip, household, or event organizers for bill archives, recurring groups, bulk reminders, and data export.
The case against
Ellipsis in speech is especially prone to errors: “the other three” depends on the preceding participant list. One incorrect split creates follow-up questions, leaving the organizer to correct each item anyway. Alcohol, discounts, service charges, late arrivals, and early departures often overlap, causing rule combinations to grow quickly. A payment QR code can enable a transfer but cannot reliably return payment status. Bilateral confirmation adds more steps. Voice recordings and bills contain sensitive relationship and spending information, so storage, deletion, and access permissions must be clear. If most items still need manual verification, the speed advantage of voice input disappears.