Margin or markup — what’s the difference?
This is the most common mistake in a wholesale business. Markup is calculated on the purchase price, margin on the selling price. Example: you buy an item for 100, sell it for 125. The markup is 25% (25 / 100), but the margin is only 20% (25 / 125). Same 25, two different numbers.
The consequence is practical: if your boss says “I want 30% margin” and you add 30% to the purchase price (i.e. markup), you actually achieve only ~23% margin. On a single item it’s trivial; on a 200k offer it’s a few thousand of difference.
How to price an offer from the purchase price?
If you target a specific margin percentage (m), price the selling price with: price = purchase / (1 − m). For a purchase price of 100 and 20% margin: 100 / (1 − 0.20) = 125. For 30% margin: 100 / 0.70 = 142.86.
If you prefer to think in markup (n), the formula is simpler: price = purchase × (1 + n). Both approaches are correct — the key is that everyone in the company calculates the same way and calls it the same thing. The worst case is reps where one “adds 25” and another “does 25 margin” — and nobody knows how much an offer actually earns.
- Price from target margin: price = purchase / (1 − margin).
- Price from markup: price = purchase × (1 + markup).
- Markup → margin: margin = markup / (1 + markup).
- Margin → markup: markup = margin / (1 − margin).
Where does margin “leak” on long offers?
On a single item, margin is easy to control. The problem starts with offers of dozens of lines made under time pressure. Typical leak points:
- Customer discount applied “by eye” instead of by group — an item that should get 8% gets 12%.
- Stale purchase price — you calculate from a price list from last quarter, but the supplier already raised prices.
- “On request” items inserted with zero margin because the purchase price arrived later and nobody came back to fix it.
- Round-downs on each line that together eat a margin point.
- Substitutes more expensive to buy, sold at the original item’s price.
How to calculate margin consistently across customer groups?
In practice a wholesaler has rules of varying specificity: a discount on a whole manufacturer, a different one on a category, yet another negotiated on a specific name. The rule: the most specific rule wins (name > category > manufacturer). If you calculate this by hand, it’s easy to apply the manufacturer discount where a specific category discount should kick in — and again you lose margin.
This is where calculating prices in code, not in the rep’s head, helps. OferIQ applies the discount by rule specificity and supports a per-product mode (discount or margin), and for “on request” items it runs the cycle: price request to the manufacturer → purchase price → margin → offer price. As a result margin doesn’t depend on who made the offer and when. More in the steel and metallurgy section (/en/industries/stal-hutnictwo/), where prices change especially fast.