Markup vs margin: the cost-plus mistake most teams make

A category manager targets "30%." Finance reports 23%. Nobody is lying, and nobody is wrong - they are using two different numbers with the same name. Multiplied across 40,000 SKUs and four quarters, that confusion is one of the most expensive unforced errors in retail. Retailgrid removes the ambiguity by making the calculation explicit in the rule itself, but the concept is worth getting right regardless of what pricing tools you run.

The two formulas

Markup is calculated on cost: Markup % = (Price - Cost) / Cost.

Margin is calculated on price: Margin % = (Price - Cost) / Price.

Same two inputs. Different denominators. Completely different answers.

A product costing €10 sold at €13 carries a 30% markup and a 23.1% gross margin. Sell it at €14.29 and you have a 42.9% markup and a 30% margin. If your target was 30% margin and someone applied a 30% markup, you are short €1.29 per unit - roughly 10% of revenue on that SKU.

The conversion worth memorising

Reading markup across to the margin it actually produces: a 20% markup is a 16.7% margin; 25% markup is 20.0% margin; 33% markup is 24.8% margin; 50% markup is 33.3% margin; 100% markup (keystone) is 50.0% margin; and 150% markup is 60.0% margin.

To convert: Margin = Markup / (1 + Markup) and Markup = Margin / (1 - Margin).

Note how the gap widens as numbers grow. At 20% the two figures differ by three points. At keystone they differ by fifty. Fashion and health & beauty teams working at high markups are exposed to the largest error.

How the mistake actually happens

It is rarely one person misunderstanding the maths. It is a translation failure across systems:

• Supplier terms are quoted as markup, because vendors think from cost upward.
• P&L targets are set as margin, because finance thinks from revenue downward.
• Spreadsheet formulas get copied between category files, and the denominator quietly changes with them.
• Legacy ERP fields labelled simply "margin" sometimes store markup.

Nobody catches it because each function validates against its own definition. The variance only surfaces at quarter close, by which point the prices have been live for ninety days.

The other half: which cost?

Even with the right formula, cost-plus fails when the cost input is incomplete. Invoice price is not landed cost. Freight, duty, handling, payment processing, and a returns provision all belong in the denominator. A category running 22% margin on invoice cost may be running 14% on true landed cost - and negative on high-return SKUs.

Fixing it structurally

The durable fix is not training. It is encoding the definition once, where prices are actually set.

Rules-based pricing lets you state the intent unambiguously - hold a 28% gross margin floor on landed cost, round to .99, cap movement at ±10% - and applies it identically across every category, with the logic visible and version-controlled. Ambiguity cannot survive a rule that names its own denominator.

From there, cost-plus becomes the floor rather than the answer. Price optimization proposes the margin-optimal price inside that floor, using elasticity and competitor position, and shows the margin impact before you commit. If markup and margin are still being used interchangeably in your planning meetings, the pricing glossary is a short, useful thing to circulate first.

Get the denominator right, get the cost right, then let the system hold the line.

Book a demo and see Retailgrid in action.