Wholesale and retail prices on one item, without two catalogues

Many Indian shops sell the same product at more than one price. The walk-in customer pays MRP or the shelf price. The regular kirana owner who buys by the carton pays a wholesale rate. The contractor who sends business your way every month gets something in between.

On paper, this lives in the owner's head. In most billing software, it turns into a mess: duplicate items ("Sugar 1kg – Retail", "Sugar 1kg – Wholesale"), a price list taped to the counter, or staff overriding the price on every bill and getting it wrong.

There is a cleaner way.

Why duplicate items are a bad idea

Creating a second copy of each product for wholesale feels quick, but it breaks things:

• Stock splits in two. You have one shelf of sugar, but your records now have two items. One goes negative, the other piles up, and neither is right.
• Reports become meaningless. Your best-selling product is now split across two lines.
• The catalogue doubles. Every new product, price change or HSN update has to be done twice — and eventually someone forgets.

Why manual overrides are not much better

Letting staff type the price on every bill avoids duplicates, but:

• the price depends on whoever is at the counter remembering the right rate;
• mistakes go both ways — you either undercharge a regular or overcharge one and lose their trust;
• you have no record of what rate a customer is supposed to get.

The better model: one item, prices by customer

The idea is simple:

1. Each product has one entry, with one stock count, one HSN code and a default selling price.
2. For specific customers, you save a special rate on the products they buy.
3. When you bill that customer, their rate is applied automatically. Everyone else gets the default price.

Stock stays in one place. Reports stay accurate. The counter staff don't need to remember anything — they pick the customer, add the items, and the right prices appear.

In MyShoppingBill this is called per-party pricing: on any item, you can set a price for a particular party, and that rate applies whenever you bill them.

Setting it up without a weekend of data entry

You don't need to enter special prices for every customer and every product. Start where it matters:

1. List your top 10 regular buyers — the ones who actually get a different rate today.
2. For each, list the 10–20 products they buy most. That covers most of their bills.
3. Save their rates on those products.
4. Add the rest as they come up. If a regular asks for a rate on a new product, save it once and it is there next time.

A few rules that keep it clean

• Write down the reason for special rates. "Bulk buyer", "contractor referral", "family". When you review prices later, you'll know why each one exists.
• Review rates when your cost changes. When a supplier raises prices, check which special rates now leave you with too little margin.
• Watch the margin, not just the price. A wholesale rate that is below your purchase cost is not a discount — it is a loss. Whenever you save a special rate, compare it with your latest purchase price for that item.
• Keep credit separate from price. A good customer may deserve a better rate or more credit — but mixing the two (a low price and a long credit period) is how margins disappear.

What about GST?

Price differences don't change how GST works. The tax is calculated on the actual sale value of each line — so a customer paying a lower rate simply pays tax on that lower value. The HSN code and tax rate stay the same because they belong to the product, not to the customer.

The result

With one product list and prices per customer:

• the counter bills faster, because nobody is looking up a rate;
• regulars get the same price every time, which builds trust;
• stock, sales and GST reports are accurate, because each product exists exactly once.

It is the way most shop owners already think about pricing. Their software should work the same way.