Weighted cost split calculator
Split 1000 by weights 2, 1 and 1 and the shares come out as 500, 250 and 250, or use percentages that add up to 100. Each named party gets an exact amount that adds back to the total. Free in your browser.
- Free
- Runs in your browser
- No sign-up
- Your data stays on your device
Run — free
Worked example
- Amount
- 1,000
- Calculation mode
- Weight
- Party count
- 3
- Weight sum
- 4
- Precision
- 2
- Amounts
- 500, 250, 250
A weighted cost split calculator takes one shared bill, deposit, or project cost and divides it among named parties using either relative weights or explicit percentages. Households use it when one roommate occupies a larger room, couples hosting guests assign double weight to a shared seat, and project teams bill stakeholders by agreed ownership stakes. Unlike an itemized shared-expense splitter that first sums many receipts, this tool starts from a single total you already know and reports each party's exact currency amount so the shares add back to that total. Equal weights produce an equal split; a two-one-one pattern gives the first party half; percentages that add to one hundred map directly onto the bill. Zero-sum weights and percentages that do not add to one hundred are rejected rather than silently invented.
How weights and percentages become each party's exact amount
Begin with a single shared cost you already know: a security deposit, a contractor invoice, a group gift, a legal settlement, or a project budget. This calculator does not ask you to itemize receipts. You supply that one total as amount and then list at least two named parties, each with a non-negative share number.
The mode field decides how those numbers are read. In weight mode, the numbers are relative weights. The engine sums them and each party receives the total multiplied by that party's weight divided by the weight sum.
Two, one, and one therefore means one half and two quarters, regardless of whether you think in rooms, heads, or ownership units. In percent mode, each number is a percentage of the total, and the percentages must add to exactly one hundred. Forty, thirty-five, and twenty-five of two hundred become eighty, seventy, and fifty.
Individual zero weights or zero percents are allowed when someone is excused for this settlement, as long as the remaining parties still form a valid sum. Negative totals and negative shares are rejected because this model describes a cost to recover, not a refund ledger. Empty party lists, a single party, a missing amount, non-finite values, and a zero weight sum are rejected for the same reason: the exact amount would be undefined or meaningless.
Currency symbols stay out of the math so the same numbers work for dollars, euros, or any unit the group already chose. Results are rounded to a currency-style precision of two decimal places by default, and the last positive-share party absorbs a one-unit residual so the reported amounts add back to the rounded total.
Where a weighted cost split belongs, and what it is not
Roommates settling a known monthly rent or a single security deposit need a trusted answer when bedrooms are different sizes, so they assign weights rather than splitting equally and posting guesses in a chat. Startup cofounders dividing a contractor invoice by ownership stakes, sports-team treasurers recovering a field booking, and families splitting a vacation rental by occupancy nights all start from one total and a short table of names.
Search intent here is a weighted cost split calculator: one known cost, named parties, weights or percentages, exact amounts that add back to the total. That is a different query from an itemized shared-expense splitter that first sums many receipts, from a tip-and-split calculator that adds a restaurant percentage and then divides equally by headcount, and from a road-trip fuel-and-tolls splitter that assumes equal passengers. Do not expect currency conversion, tax, who-already-paid ledgers, or pairwise IOU graphs; those belong to dedicated tools.
Use this page when the only question is how much each named party owes of a cost you already have in hand.
What you can do with it
Uneven roommate rent or deposit
Split a known monthly rent or security deposit by room size or nights present, and post each named party's exact amount without a shared spreadsheet.
Ownership or occupancy percentages
Recover a contractor invoice or vacation rental from stakeholders whose agreed percents add to one hundred, and keep the leftover at zero.
FAQ
How is each party's amount calculated?
In weight mode each party receives amount × (their weight ÷ sum of all weights). In percent mode each party receives amount × (their percent ÷ 100), and the percents must add to 100. Amounts are rounded to the requested precision and adjusted so they add back to the total.
What is the difference between weight mode and percent mode?
Weights are relative: 2, 1, and 1 always mean 50%, 25%, and 25% of the total, even though they do not add to 100.
What happens if all weights are zero, or percents do not add to 100?
A zero weight sum would divide by zero, and a percent total other than 100 would leave an unallocated remainder this calculator refuses to invent.
Can one party have a zero share?
Yes, as long as the others still form a valid sum (a positive weight total, or percents that add to 100). A zero-share party is reported with amount zero for this settlement.
What does it cost?
The browser tool is free and runs locally.
Related tools
For developers — API access
Everything on this page is available programmatically. This section is for teams who want to wire it into their own systems; everyone else can just use the tool above.
API endpoint
Prefer to automate it? One authenticated POST creates the task; the result comes back by webhook or a signed link. The same capability also runs here on the web, by email and from Telegram — and soon from our app too.
Call it from your stack
curl -X POST https://api.kit.forhosting.com/life/weighted-split \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"amount":1000,"parties":[{"name":"Alice","weight":2},{"name":"Bob","weight":1},{"name":"Carol","weight":1}]}'const res = await fetch("https://api.kit.forhosting.com/life/weighted-split", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"amount": 1000,
"parties": [
{
"name": "Alice",
"weight": 2
},
{
"name": "Bob",
"weight": 1
},
{
"name": "Carol",
"weight": 1
}
]
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/life/weighted-split",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"amount": 1000,
"parties": [
{
"name": "Alice",
"weight": 2
},
{
"name": "Bob",
"weight": 1
},
{
"name": "Carol",
"weight": 1
}
]
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/life/weighted-split", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"amount":1000,"parties":[{"name":"Alice","weight":2},{"name":"Bob","weight":1},{"name":"Carol","weight":1}]}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"amount":1000,"parties":[{"name":"Alice","weight":2},{"name":"Bob","weight":1},{"name":"Carol","weight":1}]}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/life/weighted-split", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Example request
{
"amount": 1000,
"parties": [
{
"name": "Alice",
"weight": 2
},
{
"name": "Bob",
"weight": 1
},
{
"name": "Carol",
"weight": 1
}
]
}Example response
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "life.weighted_split",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}The API is asynchronous: the call returns a task_id immediately and the result arrives by webhook. Polling is capped at 1 req/s per task.
Pricing
Published price — no tokens, no invented credits. A failed task is never charged.
Limits
max_parties | 200 |
max_abs_value | 1000000000000000 |
Errors
| HTTP | Code | Meaning |
|---|---|---|
401 | unauthorized | Missing or invalid API key. |
402 | insufficient_balance | Your balance doesn't cover the task price. |
404 | unknown_type | That task type doesn't exist. |
429 | rate_limited | Too many requests. Use the webhook instead of polling. |
Technical notes
How weights and percentages become each party's exact amount
If the percentages add to ninety or one hundred and five, the request fails with invalid_input instead of silently normalizing or leaving a leftover the group never agreed to. The path is deterministic floating-point arithmetic with no network, no random seeds, and no clock, so identical inputs always produce identical JSON.
What you send, what you get back, and which errors are not billed
Send two required fields and two optional fields. Classic checks include one thousand with weights two, one, and one for five hundred, two hundred fifty, and two hundred fifty, or two hundred with percents forty, thirty-five, and twenty-five for eighty, seventy, and fifty. Wire the free browser form for housemate chats and kickoff meetings, then call the identical contract from scripts when a bot or backend needs the same numbers. The field amount is the shared cost as a finite non-negative number, or a numeric string; aliases total, cost, total_cost, and bill are accepted so spreadsheets and forms can reuse a familiar column name. The field parties is an array of at least two objects, each with a display name and a non-negative weight, or a JSON string of that array; aliases people and shares are accepted. Optional mode is the closed set weight or percent and defaults to weight; aliases split_mode and as are accepted. Optional precision is an integer from zero to eight and defaults to two currency decimals; aliases decimals and dp are accepted. Missing required fields, non-numeric strings, NaN, Infinity, fewer than two parties, more than two hundred parties, negative amounts, negative weights, an unknown mode, a names-less row that cannot be labeled, a zero weight sum in weight mode, and a percent column that does not add to one hundred all fail with invalid_input and are not charged. On success the response echoes the rounded amount, the resolved mode, party_count, weight_sum, and precision; a parties array of objects each with name, weight, percent, share_ratio, and amount; a parallel amounts array and amounts_sum for easy scripting; plus the method string weighted_cost_split and a formula string that restates either amount times weight over the sum of weights or amount times percent over one hundred. Pricing for successful API calls is the published base of $0.002 per item; validation failures do not consume prepaid balance.
Where a weighted cost split belongs, and what it is not
Keep this landing focused on the single-total, named-party contract so the page ranks for that phrase and the JSON stays small enough for widgets and SMS bots. Because this capability is a pure parse engine, API pricing is the published base of $0.002 per successful item and failed validation does not consume balance. Automation pipelines store amount, mode, weight_sum, share ratios, and per-party amounts for audit after each settlement.
Integration use cases
Settlement bots and finance widgets
Feed one total and a party table into a backend bot or a free blog widget so payment requests match the same math as the browser tool.