Discounts that do not quietly eat your margin

Most businesses can tell you their list prices. Far fewer can tell you what they actually sold at, by customer, last quarter. The gap between those two is the discount, and when it is decided conversation by conversation, it is not measurable - which means it is not manageable either.

Make the price a rule, not a decision

The useful shift is from deciding a price to applying one. A price list per customer segment, a rule for quantity breaks, a rule per product category, and - where it is genuinely needed - a fixed price for a specific product and customer.

The point is not rigidity. It is that when the price comes from a rule, you can answer two questions that are otherwise unanswerable: what should this customer have paid, and why did they pay something else?

Decide how rules combine, once

The moment you have more than one rule, you have to decide what happens when two apply. A category discount and a quantity break on the same line: do they add, multiply, or does the better one win?

Any of those is defensible. What is not defensible is leaving it undefined, because then the answer depends on the order the system happens to evaluate them in, and two salespeople will produce two different totals for the same basket. Write the combination rule down, apply it in one place, and make it visible on the line so a customer asking why can be told.

One exception is worth building in deliberately: a fixed negotiated price for a specific customer and product should override the calculation entirely rather than being discounted further. A fixed price that then receives a category discount is not a fixed price.

The price must be checked on the server

This is the part that gets skipped. If the price is calculated in the browser or the app and then saved as submitted, then anyone who can reach the save endpoint can set any price. That is not a hypothetical: it is how a price becomes whatever a stale page, a modified request or an out-of-date mobile app says it is.

The correct shape is that the client calculates for display and the server recalculates before saving, refusing anything it cannot reproduce. The customer-facing effect is nil. The effect on your margin report is that it becomes true.

Authority is part of pricing

Who may give a discount, and up to what percentage, is a pricing rule like any other. It belongs in permissions, not in a manager memory. And a discount beyond the limit should require an approval that is recorded - not blocked outright, because real sales need exceptions, but recorded, because an exception nobody can find is indistinguishable from a leak.

What to look at once it is in place

• Realised price versus list price per customer. The customers at the bottom of that list are your actual discount policy.

• Margin per product after discount, not before. A product with a healthy list margin and a habitual discount may be your worst line.

• Discounts given by person. Not to police individuals, but because a pattern usually indicates a price list that is wrong rather than a salesperson who is generous.