B2B eCommerce Development in India: Why Most Dealer Portals Fail (and How to Build One That Doesn't)

Quick answer: B2B eCommerce development in India costs ₹18 lakh to ₹60 lakh and takes four to seven months. It fails most often for three reasons: the price book architecture cannot resolve conflicting rules, the ERP integration fails silently, or dealers never adopt the portal because nobody budgeted for rollout. A B2B portal is not a B2C store with a login screen — it is a pricing engine, a credit system and an ERP synchronisation problem with a catalogue attached.

Key takeaways

• Price book architecture is the make-or-break decision. Plugin-based B2B pricing breaks when a customer has both a contract rate and an active promotion.

• The India compliance layer — GST e-invoicing, e-way bills, TCS — is why imported B2B platforms fail here.

• Silent ERP sync failures are the most expensive class of B2B commerce bug, because nobody notices for days.

• Manufacturer D2C fails on channel conflict, not technology. Four architectural patterns solve it.

• Budget 8–12% of build cost for dealer adoption. Portals that skip this get built and then not used.

A manufacturer in Ludhiana spent ₹22 lakh on a dealer portal. Eighteen months later, roughly 14% of dealer orders came through it. The rest still arrived by WhatsApp, phone and email, and the inside sales team still keyed them into the ERP by hand.

The portal was not broken. It logged in, it showed products, it accepted orders. It simply did not do the specific things that would have made a dealer prefer it to a WhatsApp message: it showed list price instead of that dealer's contract price on twelve product lines, it did not know the dealer's credit position, and reordering last month's basket took eleven clicks.

So dealers did what people always do when a tool is slower than the habit it replaces. They kept the habit.

This is the most common outcome in Indian B2B commerce, and it is almost never caused by the thing buyers worry about during procurement. It is caused by three specific technical decisions — pricing architecture, integration design, and rollout — that get made quietly during a build and determine everything afterwards.

This guide is about those decisions.

B2B eCommerce Is Not B2C With a Login Screen

The single most expensive assumption in Indian B2B commerce is that wholesale is retail with restricted access. Platforms built on that assumption reach production and then quietly stall.

Seven structural differences

Any one of these can be bolted onto a B2C platform. All seven together cannot, and the failure is not linear — it compounds. Each workaround constrains the next one, until the store is a stack of interlocking exceptions that nobody wants to modify.

Why B2C-first platforms fail at B2B scale

Hosted platforms handle roughly the first two layers of B2B well. Customer groups with a percentage discount: fine. Volume breaks per product: usually fine. Contract pricing that varies per account per SKU: increasingly strained. Contract pricing that must interact correctly with a promotion, a volume break and a regional book simultaneously: this is where it breaks, and it breaks in a way that produces wrong prices rather than error messages.

Wrong prices in B2B are not a bug. They are a commercial dispute with a customer who has a contract.

The Anatomy of a B2B eCommerce Platform

Account hierarchy and user roles

A B2B customer is not a user. It is an organisation with a structure.

The model that survives contact with reality: account group → account → sub-account (branch, site, cost centre) → user → role. Pricing and entitlements attach at account or account-group level. Permissions attach at role level. A dealer with six branches needs each branch ordering independently against one shared credit limit, with the head office seeing consolidated activity.

Get this wrong at the start and every subsequent feature — approvals, credit, reporting, entitlements — inherits the fault.

Price book architecture

This is the heart of B2B commerce development, and it is where most projects are decided before anyone notices a decision was made.

The data model that works:

Customer
  → Account Group        (e.g. "North Zone Distributors")
    → Contract           (validity dates, agreed terms)
      → Price Book       (SKU-level rates for this contract)
        → Volume Break   (tiered rates by quantity)
          → Promotion    (time-bound, may or may not stack)

Five layers, any of which may apply to a given line item. The critical engineering question is not how to store them. It is what happens when more than one applies at once.

Precedence, and why it must be explicit:

Consider a dealer with a contract rate of ₹840 on a SKU, whose account group has a regional book listing ₹880, who is ordering 500 units where the volume break gives ₹820, during a promotion offering 10% off list price of ₹1,000 (₹900).

Four candidate prices. What should the system charge?

There is no universally correct answer — it depends on commercial policy. But there is a universally correct engineering requirement: the policy must be explicit, configurable, and auditable. A working precedence model looks like this:

Rule 5 is the one that gets omitted and the one that matters most in a dispute. When a dealer calls about a price, you need to know why the system charged what it charged.

Why plugin-based B2B pricing breaks: most B2B extensions for hosted platforms implement layers one through three as independent features that do not know about each other. Each works in isolation. Run two simultaneously and precedence becomes whichever plugin executes last — which is a deployment-order accident, not a pricing policy.

That is the specific technical reason B2B businesses outgrow hosted platforms earlier than B2C businesses at comparable revenue. It is also why the crossover point where custom becomes cheaper arrives at ₹6–8 crore GMV for a B2B business rather than ₹25–30 crore for a simple D2C one.

Credit limits, payment terms and order holds

In Indian B2B, credit is the product as much as the goods are.

A working credit module tracks: sanctioned limit, current outstanding, orders in flight not yet invoiced, overdue ageing buckets, and available balance derived from all four. Checkout must evaluate against available balance in real time, not the sanctioned limit.

What separates a good implementation: what happens when a dealer exceeds their limit. A blunt rejection loses the order. A better pattern places the order on credit hold, notifies the credit controller with the ageing detail, and lets them release it from a dashboard — turning a blocked sale into a two-minute decision.

Also required: partial payment against outstanding invoices from within the portal, and a visible ledger. Dealers will use a portal that answers "what do I owe?" without a phone call, and they will resent one that does not.

Quote-to-order and RFQ workflows

Not everything in B2B has a price before someone asks. Custom configurations, large tenders, non-standard terms — these start as an enquiry.

A quote workflow needs: request capture against the catalogue, internal routing to whoever can price it, an approval step above threshold values, a versioned quote document, validity dates, and single-click conversion to order. Quotes that expire silently and quotes that cannot be revised are the two most common gaps.

Approval chains

Above a rupee threshold, most B2B buyers require internal approval before an order commits. If the portal does not support this, the requisitioner assembles the basket, then emails it out for approval, then comes back — and at that point they may as well have emailed you directly.

Build: configurable thresholds per account, multi-level chains, delegation for absence, and mobile approval. The last one matters more than it sounds. Approvals happen on phones, in transit.

Bulk and repeat ordering

The single highest-adoption feature in B2B commerce, and routinely underbuilt.

What dealers actually need: reorder an entire past order in one action, upload a CSV or paste a SKU-quantity list, saved templates for recurring baskets, and a rapid-entry grid where they type part codes rather than browsing categories. A dealer who orders the same 60 lines monthly should complete that in under a minute.

If reordering last month's basket takes eleven clicks, WhatsApp wins. That is the whole story of the Ludhiana portal.

MOQ, packs and configure-to-order

Minimum order quantities, case packs, pallet quantities, and unit-of-measure conversion — a buyer thinking in cartons, a warehouse thinking in pieces, an ERP holding both. Getting UoM conversion wrong produces order quantities off by a factor of twelve, discovered at dispatch.

ERP Integration: Where B2B Portals Actually Break

If the pricing engine is the heart, the ERP integration is the circulatory system, and it fails quietly.

Integration patterns by system

The practical lesson from delivery: the constraint is usually organisational, not technical. Whoever maintains the ERP has their own change process, their own release windows and their own priorities. Get them into the project during discovery, not at integration testing. Projects that slip in B2B slip here more than anywhere else.

Real-time versus batch: a decision framework

Not everything needs real-time sync, and treating it as though it does inflates cost and fragility.

A rule worth adopting: decide explicitly which system is the master for each data domain. Products, prices, customers, stock, orders. When two systems both believe they own customer records, you get divergence, and reconciling it later is manual work measured in weeks.

Handling silent failures

This is the difference between an integration that survives and one that quietly destroys trust.

Every integration needs six things, none of which appear in a typical quote:

1. Idempotency keys — so a retried order does not become two orders

2. Retry with exponential backoff — transient failures are the majority of failures

3. A dead-letter queue — failed messages held for inspection, never dropped

4. Alerting with thresholds and a named recipient — an alert nobody owns is not an alert

5. A daily reconciliation report — orders in portal versus orders in ERP, differences flagged

6. A replay mechanism — the ability to reprocess a day's failed messages after a fix

The Friday-order problem I mentioned earlier — the manufacturer losing orders on Fridays — was a webhook timeout under end-of-week volume, with no retry and no queue. Failed orders returned a success message to the dealer and never reached the ERP. It ran for eleven weeks before anyone connected the complaints.

Not sure whether your pricing model needs a custom engine or a configured platform? Bring your price list and your ERP. We will map your pricing rules against what each platform can actually resolve, and tell you plainly if a configured platform will do. Book a B2B architecture review →

The India Compliance Layer

Every global article on B2B commerce architecture omits this section entirely. It is the reason imported platforms and imported reference architectures fail in India.

GST-compliant invoicing inside checkout

A B2B invoice is not a receipt. It is a tax document that feeds the buyer's input tax credit, and getting it wrong creates a problem for your customer's accountant, which becomes a problem for your sales team.

The portal must handle: correct GSTIN capture and validation per shipping location, place-of-supply determination driving CGST/SGST versus IGST, HSN codes at line level, correct tax rates per HSN, and reverse-charge scenarios where applicable.

Place of supply is the one that catches teams out. It depends on the ship-to location rather than the bill-to, so a dealer headquartered in Haryana receiving stock in Rajasthan changes the tax treatment. Getting this wrong on hundreds of invoices is a reconciliation exercise nobody enjoys.

E-invoicing and IRN generation

Businesses above the notified turnover threshold must generate an Invoice Reference Number through the Invoice Registration Portal before the invoice is valid. The current thresholds and technical specifications are published on the government e-invoice portal.

Architecturally, decide one thing early: does the portal generate the IRN, or does the ERP? In most Indian implementations the ERP should, because it already owns the invoice. The portal's job is to display the IRN and QR code and to handle the state where an invoice exists but IRN generation has failed — which does happen, and needs a defined behaviour rather than a blank field.

E-way bills

Consignments above the threshold value require an e-way bill before movement. Trigger this at dispatch, not at order, and handle: part-B updates when the vehicle changes, consolidated bills for multi-order shipments, validity extension on transit delays, and cancellation on returns.

TDS and TCS

TCS on sale of goods applies above threshold turnover with the buyer, and TDS on purchases may apply from the buyer's side, with rules on which takes precedence. This affects the invoice total and therefore the credit calculation. Build the logic; do not leave it to a manual adjustment afterwards.

Returns and credit notes

B2B returns are a document problem more than a logistics one. A credit note must reference the original invoice, adjust GST correctly, reflect against the dealer's outstanding balance, and reconcile in both systems. Portals that handle returns as "raise a ticket" push this back into email and undo much of the automation.

The Distributor Conflict Playbook

Ask a manufacturer why they have not launched D2C and the answer is almost never technical. It is: we cannot upset our distributors.

That fear is rational. Dealers carry inventory, extend credit to retailers, and provide local service. A manufacturer who undercuts them online can lose more channel volume than the website ever generates.

This is an architecture problem with known solutions. Four patterns, in ascending order of channel protection:

Pattern 1: Territory-routed orders

The D2C storefront takes the order at MRP. The system identifies the servicing dealer by pin code and routes fulfilment and margin to them. The customer buys from the brand; the dealer fulfils and earns.

Requires: pin-code-to-territory mapping, dealer capacity and stock visibility, fallback rules when the mapped dealer cannot serve. Suits: categories where local delivery or installation matters — appliances, building materials, equipment.

Pattern 2: Dealer-attributed D2C

The brand fulfils centrally, but every order is attributed to a dealer — by territory, by referral code, or by the customer's service relationship — and that dealer receives commission without touching the logistics.

Requires: attribution logic, commission calculation, dealer-visible reporting. Suits: smaller, shippable products where central fulfilment is more efficient but channel goodwill matters.

Pattern 3: MOQ and SKU separation

D2C sells single units and consumer packs. Dealers sell cases, pallets and trade SKUs. Different pack configurations, genuinely different products, minimal overlap.

Requires: disciplined SKU and pack architecture, and consistency in holding the line. Suits: FMCG, consumables, spare parts.

Pattern 4: Price floor enforcement

D2C sells at MRP with no discounting, ever. The channel keeps its margin because the brand refuses to compete on price. Simple, and the most commonly broken by the brand's own marketing team three quarters later.

Requires: enforcement in the promotions engine — a floor price rule that marketing cannot override. Suits: brand-led categories where price integrity is already a policy.

Most manufacturers end up combining two or three. The engineering point is that all four are architectural decisions made at build time. Retrofitting territory routing onto a live D2C store is materially harder than designing for it, which is why this conversation belongs in discovery.

Platform Options: Honest Pros and Cons

Decision matrix

The honest version: most Indian B2B businesses under 50 dealers with straightforward tiered pricing should not commission a custom build. Configure a platform, run it for two years, and let the friction tell you when to move. Building custom infrastructure before you know your own pricing complexity is how businesses end up with expensive software that encodes assumptions they later abandon.

Cost and Timeline for a B2B Portal in India

Where the money actually goes on a ₹30 lakh build, approximately: pricing engine 20%, ERP integration 25%, core commerce and catalogue 20%, credit and compliance 15%, front-end and UX 12%, testing and hardening 8%.

Note what that says. Roughly 60% of a B2B portal budget is pricing, integration and compliance — the parts nobody sees in a demo. Quotes that under-weight these relative to front-end work are quotes for something else. A fuller breakdown sits in our eCommerce development cost guide, and the evaluation framework covers how to test whether a vendor has actually built this before.

Rollout: Getting Dealers to Actually Use It

The most under-budgeted phase in Indian B2B commerce, and the one that decides whether the previous six months were worth anything.

The adoption problem, stated plainly: you are asking someone to replace a habit that works — a WhatsApp message to a salesperson they have known for years — with software. The software must be faster, not merely available. Faster than typing a message. That is the actual benchmark, and it is a demanding one.

What works, from delivery experience:

Segment the rollout. Start with 10–15 dealers who order frequently and are comfortable with software. Fix what they complain about. Then expand. A big-bang launch to 300 dealers surfaces 300 simultaneous complaints and creates a permanent first impression.

Run parallel deliberately, with an end date. Phone and email orders continue during transition. Announce when they stop for routine reorders — and hold that date. Parallel running with no end date is a portal nobody adopts.

Build for the phone. Most Indian dealer ordering happens on a mobile handset, frequently on patchy connectivity, often by someone in a warehouse rather than at a desk. If your portal is a desktop application that technically works on mobile, adoption will disappoint.

Vernacular where it matters. In agriculture, auto parts, building materials and rural distribution, interface language is not a courtesy — it is the difference between use and non-use.

Give the salesperson a reason to push it. If your field sales team's incentives are unchanged by portal adoption, they will keep taking orders by phone, because that is what they know and it protects their relationship. Attribute portal orders to the servicing salesperson. Make the portal their tool, not their replacement.

Make the first login valuable. Not a tour. Show them their outstanding balance, their last three orders ready to reorder, and their contract prices. Value in the first thirty seconds.

A Real Build: Industrial Distribution

Mullen Equipment sells process equipment into chemical, pharmaceutical and process industries — over seventy-five years of history, and a website that had accumulated content for years with no structural plan.

The revealing part was who the buyer is. A procurement engineer specifying a pump does not browse. They search by specification, compare technical parameters, and need documentation before they will enquire. A disorganised site does not simply frustrate them — it signals that the supplier may not be the detail-oriented partner needed for a long-term equipment relationship.

The work was information architecture rather than design: restructuring six-plus product categories around how a technical buyer actually searches, with the platform working as a sales tool rather than a brochure.

The transferable lesson for B2B commerce generally: in B2B, the catalogue structure is the product experience.B2C shoppers browse and discover. B2B buyers arrive knowing roughly what they need and must find it fast. Category hierarchy, attribute filtering and search quality are not decoration — they determine whether the portal is faster than a phone call.

Read the full case study →

Frequently Asked Questions

What is B2B eCommerce development?

B2B eCommerce development is the building of online ordering platforms for business customers rather than consumers. It centres on account hierarchies, contract and volume-based pricing, credit limits and payment terms, approval workflows, bulk ordering, and live synchronisation with ERP systems. In India it also requires GST-compliant invoicing, e-invoicing with IRN generation, and e-way bill handling.

How is B2B eCommerce different from B2C?

Seven structural differences: pricing is per-account rather than universal; the buyer is a team with roles rather than one person; payment runs on credit terms rather than at checkout; orders contain dozens to hundreds of repeated lines; the catalogue is entitlement-based; fulfilment involves partial dispatch and backorders; and the invoice is a tax document feeding the buyer's books. Individually each is manageable on a B2C platform. Together they are not.

Can Shopify handle B2B pricing?

Shopify Plus handles B2B pricing well up to a point — company accounts, catalogue-based pricing and payment terms are native. It becomes strained when several pricing rules must resolve against each other, such as a contract rate interacting with a volume break and an active promotion, and when deep ERP-driven pricing logic is required. As a rough guide, it suits up to around 200 accounts with straightforward contract pricing.

How much does a B2B eCommerce portal cost in India?

₹6 lakh to ₹14 lakh for a configured platform with tiered pricing and light integration. ₹18 lakh to ₹32 lakh for contract pricing, credit limits and batch ERP sync. ₹32 lakh to ₹60 lakh for a full custom build with a multi-layer pricing engine, live ERP integration, quotes, approvals and e-invoicing. Add 8–12% for dealer rollout and adoption.

How long does it take to build a B2B eCommerce portal?

Eight to twelve weeks for a configured platform. Four to five months for mid-complexity builds with contract pricing and ERP synchronisation. Five to seven months for full custom platforms. ERP-side change control is the most common cause of slippage, which is why the ERP owner should be involved from discovery rather than at integration testing.

Why do most dealer portals fail?

Three reasons, in order of frequency. The price book architecture cannot resolve conflicting pricing rules, so dealers see wrong prices and stop trusting the portal. The ERP integration fails silently, with orders lost and nobody alerted for days. And nobody budgeted for dealer adoption, so the portal is slower than the WhatsApp habit it was meant to replace and dealers keep the habit.

How do I integrate my B2B portal with Tally or SAP?

Tally is typically integrated through scheduled XML or ODBC synchronisation, or via middleware, and is best designed around batch rather than real-time patterns. SAP integrates through OData services, BAPIs or an integration layer, and requires early engagement with the ERP team because change control is slow. In both cases, decide explicitly which system is master for products, prices, customers, stock and orders before building anything.

How can a manufacturer sell direct without upsetting distributors?

Four architectural patterns. Territory-routed orders send D2C orders to the servicing dealer for fulfilment and margin. Dealer-attributed D2C fulfils centrally but pays commission to the mapped dealer. MOQ and SKU separation gives consumers single units and dealers case packs. Price floor enforcement holds D2C at MRP so the channel keeps its margin. Most manufacturers combine two or three, and all four are decisions made at build time.

What GST compliance does a B2B eCommerce platform need in India?

GSTIN capture and validation per shipping location, place-of-supply determination driving CGST/SGST versus IGST, HSN codes and correct rates at line level, e-invoicing with IRN generation above the notified turnover threshold, e-way bill triggers at dispatch, TCS handling where applicable, and credit notes that reference the original invoice and adjust GST correctly. Place of supply follows the ship-to location, which is the rule most commonly implemented incorrectly.

What features do B2B buyers actually use most?

Rapid reordering above everything else — one-click repeat of a past order, CSV or SKU-list upload, saved templates, and a fast entry grid using part codes. After that: visible account-specific pricing, real-time stock availability, and a credit ledger showing outstanding balance and ageing. The benchmark is not "does the portal work" but "is it faster than sending a WhatsApp message," and reordering is where that is won or lost.

Where This Leaves You

B2B eCommerce is the highest-return commerce project most Indian mid-market businesses can undertake, because it removes cost rather than adding acquisition spend. Every order that moves from a phone call to a portal is inside-sales time recovered and a keying error avoided.

It is also the easiest to get expensively wrong, because the parts that decide success are invisible during procurement. Nobody demos a precedence rule. Nobody demos a dead-letter queue. Nobody demos the reconciliation report that catches eleven weeks of missing Friday orders on day two instead.

If you are scoping a portal, the three questions worth settling before you speak to any vendor: what happens when two pricing rules conflict, what happens when the ERP is unavailable during a sale, and who is responsible for dealer adoption after launch. A vendor with good answers to those three has probably built one before.

We run B2B architecture reviews as a scoped engagement — bring your price list, your ERP details and your dealer count, and you get a mapped pricing model, an integration pattern recommendation and an honest answer about whether a configured platform will do the job. As an eCommerce development company in India that treats B2B eCommerce development as a core specialism rather than a side offering, we would rather tell you to configure Shopify Plus than sell you a build your pricing model does not need yet.

Book a B2B architecture review →

Related reading

• B2B eCommerce development services

• eCommerce development cost in India: 2026 pricing guide

• How to choose an eCommerce development company in India

• Magento development for enterprise B2B catalogues

• Digital transformation and API integration