Commission and discount arithmetic
Commissions and discounts are both a percentage applied to a price, yet each hides a reliable trap: a split quoted against the wrong base, a second discount read as addition, a cut and a rise assumed to cancel. This guide walks through what the Sumvia engine actually does with these inputs — the single multiplication at the core, how splits and tiers are composed from it, why stacked discounts multiply, and how a change reports its direction. Every figure below is computed at build time by the same functions behind the commission, discount, and price change calculators, on labelled fictional numbers. The full set of guides, with the calculators and the method behind them, is on the guides hub.
A commission is one rate on one base
The core operation is a plain percentage: commission = base × rate ÷ 100. The engine requires the base to be greater than zero and the rate to sit between 0 and 100, then returns the commission and the remainder it calls the net to the seller. A 8,000 sale at 5% produces a commission of 400 and leaves 7,600 — the sale amount minus the commission, before any other costs of the transaction. Nothing about the figure is rounded inside the engine; the two decimals you see here come only from the display layer, which is the subject of its own guide.
The "base" is deliberately unlabelled as to its meaning. Most arrangements pay on the sale amount, but a plan that pays on gross margin or on collected revenue is the same arithmetic with a different number in the base field. The engine does not know or care which; it multiplies what it is given.
A split is a percentage of the commission, not of the sale
When an agent works under a broker, the commission is divided again, and the division is quoted against the commission — never against the sale. Supplying an agent share turns the single result into a split: on a 240,000 sale at 6%, the commission is 14,400, and a 70% agent share is 10,080, with the broker keeping the remaining 4,320. The engine also restates each share as a percentage of the sale, because that is the figure people actually compare: the agent's 10,080 is 4.2% of the sale price, and the broker's portion is 1.8%. "I'm on 70%" and "I earn 4.2% of the sale" describe the same paycheck; reading the first as if it meant the second is the standard commission surprise.
Tiers are composed, not a single input
A tiered schedule pays different rates on different slices of the sale, and the engine models each slice as its own single-rate calculation rather than accepting a schedule directly. Suppose the first 100,000 of a sale pays 3% and the portion above it pays 5%. The first slice returns 3,000; the next 50,000 returns 2,500; adding them gives 5,500 on a 150,000 sale. The single rate that would have produced the same total — 3.67% — is a result of running the slices, computed here as the total commission over the total sale. It does not exist until the schedule has been applied, which is why entering a blended rate up front and entering the slices separately answer two different questions. The slice-by-slice method is also the honest one: it survives a change to any single tier's boundary or rate without re-deriving a blended figure that was only ever a summary.
A discount keeps the complementary share
A discount is the mirror image of a markup: it multiplies the price by what remains after the cut, sale price = original × (1 − discount ÷ 100). The engine requires the original price to be positive and each discount to sit between 0 and 100, where a 100% discount is allowed and simply yields a zero price. A 30% reduction on 120 keeps 70% of it, which is 84, saving 36. For a single discount the effective percentage the engine reports equals the one you entered — 30% here — which only becomes interesting once a second discount joins it.
Stacked discounts multiply; they do not add
"20% off, and an extra 15% off at the register" is built to be misread as 35% off. The register multiplies the two remaining shares: the price keeps 0.80 × 0.85 = 0.68 of itself, so 120 falls to 81.6 — an effective 32% discount, not 35%. The engine computes that single equivalent percentage directly from the surviving fraction, so the number on the sign and the number on the receipt can be set beside each other. The order of two percentage discounts never matters, because multiplication commutes; order only enters when one reduction is a fixed amount rather than a percentage, which this function does not model.
A discount is a negative price change
The same cut, read as a change rather than a saving, exposes the asymmetry that catches people trying to undo it. Going from 120 down to 84 is a change of -30%; going back up is 42.86%, because the return trip measures the same 36 difference against the smaller baseline. Adding 30% back onto the 84 sale price therefore does not restore 120: it adds only 25.2 and reaches 109.2. To reverse a known change the engine divides by the growth factor rather than subtracting the percentage — the reason a figure discounted and then "un-discounted" by the same percentage never comes back to where it started.
How the engine labels the direction of a change
Every change the engine reports carries an explicit direction — one of increase, decrease, or no-change — decided purely by the sign of the difference, so the label and the number can never disagree. The 120 to 84 move is a decrease of 30%. When the two values are equal the direction is no-change and the engine reports a difference of 0 rather than a percentage. The one case it refuses to answer with a percentage is a change from a zero baseline: 0 to 50 is an increase, and the engine returns the direction and the absolute difference but no percentage, because a percentage of nothing has no conventional value — it reports that plainly instead of showing an infinity.
Frequently asked questions
Does the commission rate apply to the sale price or to the profit?
The engine applies the rate to whatever base you enter. In the common arrangement that base is the sale amount: 5% of a 8,000 sale is 400, leaving 7,600 on the seller's side. If a plan instead pays on gross margin or collected revenue, enter that figure as the base — the arithmetic is the same multiplication either way.
Is a 70% share the same as earning 70% of the sale?
No, and the gap is the usual source of confusion. The share is applied to the commission, not the sale. On a 240,000 sale at 6% the commission is 14,400; a 70% share is 10,080, which is only 4.2% of the sale price, with 4,320 (1.8% of the sale) left over.
How does the calculator handle a tiered commission schedule?
It does not treat tiers as one input. Each slice is a separate single-rate calculation, and the results add: 100,000 at 3% gives 3,000 and the next 50,000 at 5% gives 2,500, totalling 5,500. The blended rate, 3.67% of the 150,000 sale, exists only after the fact — it is a result of the schedule, never an input to it.
Why is 20% off then an extra 15% off not 35% off?
Because the second discount applies to the already-reduced price, so the two factors multiply instead of adding. On 120, keeping 0.80 then 0.85 of the price leaves 81.6 — an effective 32%, not 35%. The engine reports that single equivalent percentage so the sign and the receipt can be compared directly.
A 30% discount cut 120 to 84. Why does adding 30% back not restore it?
Because the two percentages are measured against different baselines. The 30% cut was taken from 120; a 30% rise on the 84 sale price is taken from the smaller figure, so it adds only 25.2 and lands at 109.2. Going from 84 back to 120 is a 42.86% increase, not a 30% one.
What does the engine report when nothing changes, or when the baseline is zero?
When the two values match, it labels the direction "no-change" and reports a difference of 0 rather than a percentage of nothing. When the starting value is zero — say 0 to 50 — a percentage change is not defined, so the engine returns the direction ("increase") and the absolute difference of 50 but no percentage, instead of an infinity.
Every figure on this page is computed in the browser-side engine at build time on fictional, labelled inputs; no rate or price here is a recommendation. The calculator implements the general definition of each operation; your jurisdiction's or contract's own conventions may differ, and deciding which calculation fits your situation is a judgment the arithmetic cannot make for you. How results are validated, rounded, and displayed is set out on the methodology page.