Skip to content
Operations15-Jan-20246 min read

Dealer pricing tiers, where every distributor SaaS breaks.

Generic distributor software handles one list price and one discount field. Real Indian distribution has dealer tiers, scheme discounts, volume slabs, freight terms, and GST treatment by state. Here is where every SaaS breaks.

By Mohammad Jamnagarwala · Simply Five Studio

A distributor of automotive parts in Mumbai signed up for a popular distribution SaaS in early 2024. By the third week, the founder was running a parallel spreadsheet to figure out what each invoice should actually have shown. The software handled a list price. It handled one discount field. It could not handle the way the business actually priced a Platinum dealer in Maharashtra versus a Silver dealer in Karnataka receiving a scheme of 1 percent plus 1 percent plus 2 percent on a quarterly volume slab, with freight to be borne by the dealer, but only above a 50,000 rupee invoice value.

That spreadsheet is the universal symptom. Generic distributor software was built around a single pricing axis. Real distribution operates on six. The gap between the two is where founders end up either rebuilding the SaaS by configuration (which fails) or running shadow logic outside the system (which fails differently). The right answer is custom pricing infrastructure built around the firm's actual scheme.

What generic distributor SaaS actually models

Most distributor SaaS, whether built abroad or in India, assumes a flat pricing model. There is a list price on the product master. There is a customer-level discount percentage that applies across the catalogue. Some products allow a customer-specific price override. That is the entire model.

The model is sufficient for businesses that sell at MRP to retail walk-ins, or that have a single negotiated rate per customer. It is not sufficient for an Indian distributor with dealer tiers, region splits, vendor schemes, and seasonal slabs running at the same time.

What real Indian distribution pricing looks like

A founder running a parts distributorship across three states keeps something like the following structure in their head, in a notebook, or in a spreadsheet the founder personally maintains.

Dealer tier is the first axis. Platinum, Gold, Silver, Bronze. Each tier has a different base discount off list. The tier is reviewed annually based on volume.

Scheme discount is the second axis. The principal manufacturer announces a scheme: 1 percent plus 1 percent plus 2 percent on a quarterly volume slab. The percentages compound. The distributor passes some portion of this to the dealer, retains some portion as margin. The pass-through varies by tier.

Volume slab is the third axis. Dealers who cross 5 lakh rupees in a quarter unlock the next slab. The slab applies retroactively in some cases and prospectively in others, by category.

Freight is the fourth axis. Some dealers in some states get free freight above a threshold. Some get freight reimbursed against a separate ledger. Some absorb freight entirely.

GST treatment is the fifth axis. Inter-state sales attract IGST. Intra-state sales attract CGST plus SGST. The split affects the invoice format, the e-way bill requirement, and downstream reconciliation in the dealer's Tally.

Product-specific override is the sixth axis. A new launch carries a higher margin for the first quarter. A slow-moving SKU gets a clearance price for selected dealers. A bulk pack carries a different price than a single pack of the same item.

Every founder in distribution recognises this structure. No distributor SaaS implements it natively.

What founders do when the software cannot keep up

The first response is configuration. The founder asks the SaaS vendor to add fields, build rules, or expose a discount engine. The vendor adds two fields. The founder adds a third spreadsheet to bridge the gap.

The second response is parallel tooling. The founder maintains a master Excel that calculates the actual price for each dealer for each invoice. The team enters the invoice into the SaaS at the calculated price, bypassing the pricing engine entirely. This works for a while. It fails the first time a junior team member skips the spreadsheet.

The third response is to give up on the SaaS for pricing and use it only for inventory and invoicing. The pricing intelligence migrates back to the founder's head. The firm loses leverage over its own scheme structure. Dealer disputes increase because the team cannot reproduce the calculation under pressure.

The fourth response, which is the one AKSD took with their custom ERP, is to commission a pricing engine that fits the firm. The engine sits inside the ERP. The dealer tier, the scheme, the slab, the freight, the GST split, and the override all resolve at invoice time. The invoice ties out. The team does not maintain a parallel spreadsheet. The founder can audit any line of any invoice from first principles.

What custom dealer pricing actually looks like

A custom pricing engine carries explicit data structures for each axis. The dealer master has tier, region, GSTIN, and credit terms. The product master has list price, GST slab, and pack configuration. A scheme table holds active schemes by principal, by period, by category, with the pass-through percentages encoded. A slab table holds volume tiers by category. A freight policy attaches to dealer tier and region.

At invoice time, the engine resolves the price in a defined order. List price loads. Tier discount applies. Scheme discount layers on with the correct compounding rule. Volume slab unlocks if the dealer has crossed the threshold this quarter. Override applies if one is active for this SKU for this dealer for this period. Freight resolves to bill-to-customer or absorb. GST splits according to the supply state and the dealer state. The invoice prints with each component visible. The dealer's accountant can reconcile against their Tally. The founder can reconcile against the firm's scheme commitments.

This is the structural shift documented in our piece on why WooCommerce plus a custom ERP beats every all-in-one. The pricing engine is not a feature of the storefront. It is the heart of the back office.

When the SaaS is wrong on principle, not on features

The temptation, when a SaaS fails on pricing, is to evaluate another SaaS. The temptation is the wrong instinct. The reason the first SaaS failed is the same reason the second will. The data model assumes a single pricing axis. The vendor cannot rewrite their core model for one Indian distributor. The result is the same dance: configure, parallel-tool, give up, parallel-tool again. We have written about this directly in our piece on why SaaS cost eventually exceeds custom build.

A founder running distribution at 5 to 50 crores in revenue should treat the pricing engine as a core operational asset, not as a configuration of a generic tool. The asset goes into internal systems, owned by the firm, evolved as the scheme structure evolves. The firm's competitive advantage in distribution often lives precisely in the cleverness of its pricing structure. That cleverness needs software that can hold it.

Decision infrastructure for a distributor is the system that resolves a dealer's price correctly on the first try, every time, without the founder having to verify. When the system can do that, the founder's attention returns to the decisions that matter: which tier to promote, which scheme to push, which dealer to grow.

A founder considering whether to keep patching a generic distributor SaaS or commission a fitted pricing engine should ask one question of the current tool. Can it explain, line by line, why this invoice came out at this number, without anyone running a calculator? If the answer is no, the tool is not pricing. It is recording. The pricing is happening elsewhere. Start a Conversation.

More reading

Related essays.

Continue the conversation

If this resonated, tell us about your operation.

The contact form takes about two minutes. The reply comes from the founder within two working days.