Most manufacturers already take dealer orders digitally. They take them on WhatsApp, against a PDF price list that went out in March, from a dealer who is not certain whether his last payment cleared. That is a digital process in the sense that a photograph of a ledger is a spreadsheet.
A dealer portal replaces that with something that knows who is ordering, what they pay, what they owe and whether they are allowed to place this order at all. The software is not the hard part. Agreeing what the rules actually are is the hard part, and most projects discover that two people in the same office apply them differently.
This is what a portal has to do to be worth building, in the order the decisions come up, with the India-specific parts that change the answer. Written for manufacturers, wholesalers and distributors rather than for retail brands.
Why a B2B order is not a retail order with a discount
Every retail platform assumes four things that are false for dealer ordering. It assumes a public price, one price for everybody, payment at checkout, and that an order is final when placed. A dealer business breaks all four on the first day.
| Retail assumes | Dealer ordering needs |
|---|---|
| A public price on the page | Prices visible only after login, and different per customer |
| One price per product | Rate contracts, slab pricing, scheme discounts, sometimes all three |
| Payment at checkout | Ordering against a credit limit, settled on terms |
| An order is final when placed | Quotation, approval, revision, then order |
| One buyer per account | A firm, with several people ordering under it |
| Stock is stock | Allocation, reservations and what this dealer is allowed to see |
Any one of these can be bolted onto a retail platform. Two or three of them together is where the workarounds start costing more than building the thing properly, and where the plugin stack becomes the maintenance problem rather than the solution.
The test we apply before recommending a build: write down your pricing rules on one page. If a competent person could price any order correctly from that page, a platform with a wholesale extension will probably hold it. If it takes a conversation, a dealer portal built for the rules is the cheaper answer over three years.
The part that is already settled: buyers will order through a portal
The usual internal objection is that dealers will not use it. That question has largely been answered at national scale, and by the least likely institution. It is the same shift that moved retail buyers online, which choosing an ecommerce platform traces from the other direction.
Government buying is the most conservative procurement in the country, and it runs at five lakh crore a year through a web portal, with two thirds of orders fulfilled by small businesses. The dealer who says he prefers to phone is not refusing technology. He is refusing a portal that is slower than phoning you, which is a design problem and a solvable one.
The corollary is unforgiving. If repeat ordering takes more taps than a WhatsApp message, adoption stalls and the project is judged a failure for reasons that have nothing to do with the rules engine underneath it.
Pricing, which is the whole project in disguise
Almost every B2B build we have done has spent more time on pricing than on anything else, and the schedule slips when that work is deferred rather than done first. Pricing logic of this shape is the most common reason a project becomes custom ecommerce development rather than a configured store.
The customer rate
A price list per dealer or per dealer group. The commonest shape, and the one every wholesale extension handles. If this is all you have, you do not need a custom build.
Quantity slabs
The rate moves at volume breaks, and the breaks differ by product or category. Still tractable, but the edge cases start here. What happens at exactly the break point is a question somebody has to answer.
Schemes and periods
Seasonal offers, festival schemes, quantity-plus-free-goods, rates that apply only until the end of the quarter. This is where spreadsheets go to die and where two people in the same office genuinely disagree.
Negotiated exceptions
The rate one dealer has because of a conversation in 2019 that nobody wrote down. Every business has these. The portal has to hold them explicitly rather than pretend they do not exist.
The workshop that produces this document is worth paying for on its own, whoever builds the software. Bring the rate sheets, the last hundred invoices and the person who knows the exceptions. Expect to find at least one rule that two people apply differently, because that is the normal outcome rather than a sign of a badly run business.
Credit limits, and the rule that made payment terms a tax question
A dealer portal that cannot answer "can this dealer place this order" is a catalogue. The credit position has to be visible to the dealer, enforced at checkout, and consistent with whatever your accounts team believes, which means it has to come from the system that already holds it. That is an ERP or Tally integration rather than a field somebody types.
What changed recently is that the credit period itself is no longer purely commercial. Section 43B(h) of the Income-tax Act 1961, inserted by the Finance Act 2023 and effective from assessment year 2024-25, allows a buyer to deduct a payment to a micro or small enterprise only in the year it is actually paid, if payment falls outside the limit in section 15 of the MSMED Act 2006.
Read that in the direction that matters for a portal. If your dealers are registered micro or small enterprises and you are the one buying from them, your payment terms have a tax consequence. If you are the seller and your buyers are larger firms, their finance teams are now under pressure to pay you inside the window, which makes a portal that issues a correct invoice immediately worth more than it was three years ago.
This is not tax advice and the application turns on the registration status of both parties. Raise it with your accountant before you set default terms in the portal, because a default of sixty days configured once is a decision that quietly repeats on every order.
- Show the dealer their credit limit, used and available, before they start ordering.
- Decide what happens at the limit: block, warn, or route to approval. Not all three.
- Keep the limit authoritative in one system. Two systems disagreeing is worse than one being wrong.
- Record the agreed payment terms per dealer rather than assuming one policy fits all.
The ERP question, which sets the timeline
For most manufacturers the ERP, or Tally, already holds the truth about stock, dealers, rates and outstandings. The portal is a new face on data that exists, and the single biggest driver of how long the project takes is not the portal. It is what the ERP will expose and how quickly somebody will give you access to it.
Three situations, and they produce very different projects. A clean API is straightforward. A system that needs a middleware layer is a real piece of work but predictable. A system that offers only scheduled file exchange still works, and produces a portal where stock is accurate as of this morning rather than this second, which is usually fine if everybody agrees it in advance.
The failure mode is not technical. It is that getting API credentials and a test environment out of an ERP vendor regularly takes longer than writing the integration, so that conversation belongs before scoping rather than after. We start it in week one for exactly that reason.
What flows in each direction is worth agreeing explicitly: stock and rates from the ERP to the portal, orders from the portal to the ERP, and one owner for anything both sides can change. Ecommerce integrations covers the mechanics, including conflict rules and what happens when the two disagree.
Invoicing, where B2B is stricter than retail
A retail store can get away with a mediocre invoice because the buyer is not reclaiming anything. A dealer is, which makes the document part of the product rather than an afterthought.
The buyer GSTIN has to be captured and printed, or your dealer cannot claim input credit and will ask you to reissue. HSN codes have to be right: four digits up to five crore of aggregate annual turnover and six above it, under Notification 78/2020, in force since 1 April 2021. Place of supply has to follow the delivery state rather than the billing address, which for dealers shipping to branch addresses is a real and frequent difference.
If your turnover puts you above the e-invoicing threshold, the portal has to produce invoices that can be registered rather than merely printed, and that constrains how the invoice series is generated. GST invoicing for an Indian online store works through the document itself in detail.
Adoption, which is where these projects actually fail
The rules engine can be perfect and the portal can still be unused. Everything below is about the dealer's first week, which decides the next two years. Where the same business also sells to the public, the retail side has its own adoption question covered in how to sell products online in India.
Design for a phone in a godown
Not a desk. One hand, poor light, patchy signal, possibly a cracked screen. If it needs a laptop, it will be used by the office and not by the person who knows what to order.
Repeat order in one tap
The single highest-value feature in any dealer portal. Most orders are close to the last one, and a portal that makes reordering slower than a WhatsApp message will lose to the WhatsApp message.
Show the credit position first
It is the thing dealers most want to know and most dislike phoning to ask. Putting it on the landing screen converts the portal from an obligation into a tool.
Pilot with a handful, not everybody
Three or four dealers who will tell you the truth, for a month, before a wider rollout. The complaints from that group are the roadmap.
Do not switch the phone off
Orders will keep arriving by phone and WhatsApp, and that is fine. The goal is that the portal is easier, not that the alternative is banned.
We launched it to all two hundred dealers with a training PDF.
Nobody reads it, the first confused dealer phones your sales team, and the sales team quietly goes back to taking orders by phone.
Four dealers, one month, and the sales manager watching them use it.
You find out in a fortnight which two screens are wrong, fix them, and roll out something that survives contact.
Selling to the public on the same site
Common, and entirely workable: a public catalogue with enquiry forms and no prices, plus a login that reveals dealer rates and ordering. The requirement that matters is that dealer pricing can never leak into the public view or into a search engine.
That is handled at the template level and at the robots level rather than by hoping nobody guesses a URL. Logged-out requests must not render rates at any URL, and the pages that exist only for logged-in dealers should not be in the sitemap or crawlable in the first place.
There is a search consequence worth planning for. Your public catalogue pages are the ones that can rank, and they are competing on product and category terms like any other store. Why your category pages do not rank applies to a manufacturer's public catalogue exactly as it does to a retail one.
What to do before you scope anything
Four things, and none of them need a developer. They are also the four things that decide the quote, so doing them first usually lowers it.
- Write your pricing rules on one page, including the exceptions nobody has documented.
- Ask your ERP vendor, in writing, what API or export they provide and what it costs.
- Pull your last hundred dealer orders and count how many are repeats of a previous order.
- Check with your accountant how the MSME payment window applies to your dealer terms.
- Name three dealers who will pilot it and tell you honestly what is wrong.
That third one is the most revealing. If most orders are close repeats, the portal pays for itself on reorder speed alone and the rules engine matters less than the interface. If they are all different, the rules are the project. Our B2B ecommerce and dealer portal page sets out how we scope and build these, including the rules workshop that comes before any code.
That is the normal starting point, not a problem. Send us your rate sheets and a hundred recent orders and we will tell you what a portal would have to hold, what your ERP will allow, and whether a platform extension would do instead.
Questions we get asked about this
What is a B2B ecommerce platform, as opposed to a normal one?
One that assumes the buyer is a business with an account rather than a stranger with a card. In practice that means prices visible only after login and different per customer, ordering against a credit limit instead of paying at checkout, quotation and approval steps before an order is final, several people ordering under one firm, and an ERP that holds the authoritative stock and rates. A retail platform can be extended to do some of this. It cannot usually do all of it.
Can a dealer portal run on Shopify or WooCommerce?
Sometimes, and we build that where it fits. WooCommerce with customer-group pricing and role logic handles a moderate set of rules well. Shopify sells a B2B capability on its higher plans and it is a real product. The line is usually crossed when dealer-specific price lists, slab rules, scheme discounts, credit limits and a two-way ERP sync are all in play at once, at which point a custom build tends to cost less over three years than fighting the platform.
Will our dealers actually use it?
If it is faster than phoning you, yes. The evidence at national scale is fairly strong: the Government e-Marketplace processed around five lakh crore rupees of procurement in FY 2025-26, with MSMEs executing 68% of orders, which is the most conservative buying in the country running through a web portal. Where adoption fails it is almost always because repeat ordering took more effort than a WhatsApp message.
How does the 45-day MSME payment rule affect dealer credit terms?
Section 43B(h) of the Income-tax Act, inserted by the Finance Act 2023 and effective from assessment year 2024-25, means a buyer can deduct a payment to a micro or small enterprise only in the year it is actually paid if it falls outside the MSMED Act window, which is 15 days by default and 45 days at most with a written agreement. It makes payment terms a tax question as well as a commercial one. Confirm how it applies to your specific arrangement with your accountant before configuring default terms.
What decides how long a dealer portal takes to build?
Rules agreement and ERP access, rarely the code. A pricing structure nobody has documented takes a workshop to establish, and getting API credentials plus a test environment from an ERP vendor regularly takes longer than writing the integration itself. We start the ERP conversation before scoping anything else for that reason, and give a timeline after the rules workshop rather than before it.
Can we sell to the public on the same site as the dealer portal?
Yes, and many manufacturers do. A public catalogue with enquiry forms and no prices, plus a login that reveals dealer rates and ordering. The important part is that dealer pricing can never leak into the public view or be reachable by a crawler, which is handled at the template and robots level rather than by obscure URLs.