B2B Dealer Ordering System: How to Build It

A B2B dealer ordering system is a closed ordering portal where your dealers and wholesale customers place orders around the clock while seeing their own price list, discount rate, credit balance and real stock levels. It differs from retail e-commerce in three ways: the price depends on who is logged in, payment usually runs through a credit account rather than a card, and the order passes through an approval flow. There are three routes to build one — switching on the B2B module of an existing e-commerce platform (a few days), writing a dealer layer on top of a standard platform (2-6 weeks), or developing a custom portal wired into your ERP (8-16 weeks). The variable that decides which fits is not your product count but the complexity of your pricing rules.

What makes a B2B dealer portal different from retail e-commerce?

On a retail store a product has one price, everyone sees the same number, payment is taken at checkout and the order needs no approval. On the dealer side all four of those statements are false. This is why "let us just add a dealer login to the current site" stalls in week three of most projects: what has to be added is not a login screen but a second commercial model.

• Price depends on the customer — The same product goes to dealer A at 18% off list, to dealer B at 27% off, and to dealer C at a unit price fixed by contract. The price does not live on the product; it lives in the relationship between product and customer.
• Credit account and risk limit — Payment is often not taken at order time. The system has to know the dealer’s balance, payment terms and credit limit, and must block or escalate an order when the limit is exceeded.
• Approval flow — The buyer at the dealer creates the order, their manager approves it; on your side a regional manager may have to approve the discount. Nothing reaches production or dispatch before approval.
• Case and pack multiples — Quantity is not free-form in B2B: if the product ships in cases of 12, nobody can order 17. The quantity field must round to the case multiple or reject it outright.
• Tax display — Dealer screens usually show prices excluding VAT, with tax as a separate line in the basket total. A cart written with retail logic does not carry that split.
• Fast ordering — Dealers do not browse. They know the product code and want to enter 60 lines on one screen; spreadsheet upload, search by code and repeat-last-order are the three most used features.

Core modules of a dealer system

• Dealer management — Dealer record, sub-users and their permissions (create / approve / view only), the price list they belong to and their territory.
• Price list and campaign engine — List-level discounts, quantity breaks, contracted per-dealer prices and date-bounded campaigns.
• Catalogue and stock — Different dealers may be entitled to see different product sets; stock comes from the ERP, and saying "lead time 5 days" instead of "out of stock" measurably lifts conversion.
• Ordering and approval — Basket, rounding to case multiples, order notes, approval steps, partial shipment and cancellation.
• Credit account screen — Balance, overdue amount, open orders, delivery notes and invoices. This is the screen dealers open most often, more than the order screen itself.
• Shipment tracking — Order status, tracking number and delivery confirmation. We covered the setup in shipping carrier integration.
• Reporting — Revenue by dealer, product breakdown, target attainment and mobile access for the field team.

Pricing logic: the genuinely hard part

The most time-consuming work in a B2B project is not the catalogue or the design. It is building a rules engine that answers "what is the unit price if this dealer buys 40 of this product?" the same way every single time. If rule precedence is not written down first, the project loses trust the day the portal and the invoice disagree. The usual order of precedence: contracted per-dealer price, then quantity break, then the dealer group’s list discount, then the base list price.

// Resolves the unit price a dealer sees for a product.
// Precedence: dealer-specific price > quantity break > list discount > list price
type PriceRule = {
  productId: string;
  dealerId?: string; // contracted price for one dealer
  listId?: string; // price list of the dealer group
  unitPrice?: number;
  discountRate?: number; // 0.18 = 18%
  minQuantity: number;
  startsAt: string; // 'YYYY-MM-DD'
  endsAt?: string;
};

export function resolveUnitPrice(
  product: { id: string; listPrice: number },
  dealer: { id: string; listId: string },
  quantity: number,
  date: string,
  rules: PriceRule[],
): { price: number; source: string } {
  const applicable = rules.filter(
    (r) =>
      r.productId === product.id &&
      quantity >= r.minQuantity &&
      date >= r.startsAt &&
      (!r.endsAt || date <= r.endsAt),
  );

  // 1) Contracted dealer price — the highest matching quantity break wins
  const contracted = applicable
    .filter((r) => r.dealerId === dealer.id && r.unitPrice !== undefined)
    .sort((a, b) => b.minQuantity - a.minQuantity)[0];
  if (contracted?.unitPrice !== undefined) {
    return { price: contracted.unitPrice, source: 'dealer-contract' };
  }

  // 2) List discount of the dealer group
  const listRule = applicable
    .filter((r) => r.listId === dealer.listId && r.discountRate !== undefined)
    .sort((a, b) => b.minQuantity - a.minQuantity)[0];
  if (listRule?.discountRate !== undefined) {
    const price = product.listPrice * (1 - listRule.discountRate);
    return { price: Math.round(price * 100) / 100, source: `list:${dealer.listId}` };
  }

  // 3) No rule matched — fall back to list price
  return { price: product.listPrice, source: 'list-price' };
}

The "source" field the function returns is not cosmetic: when a dealer disputes a price, it lets you show which rule fired in seconds. Write it onto the order line as well, and most of the month-end invoice arguments end right there.

Without ERP and accounting integration the portal does not work

A dealer portal is not an island; it is the face your existing systems turn towards the dealer. Stock, balances and price lists come out of the ERP or the accounting package, while orders travel the other way, from the portal into the ERP. Without that two-way flow the portal degrades into "a form that collects orders" and manual data entry comes straight back. We mapped which data moves in which direction in what an ERP is and accounting software integration; for the technical groundwork, what API integration is is a good starting point.

A practical rule: for fast-moving data such as stock and balances use a live query or a short sync interval; for slow-moving data such as price lists a nightly batch is enough. When writing the order into the ERP, always use a queue and an idempotency key — if the ERP goes quiet for a minute the dealer’s order must not vanish, and a retry must not create it twice. We went into the question of where stock should actually live in stock tracking software or custom development.

The measure of a dealer portal is not revenue; it is the drop in orders still arriving by phone and messaging apps. As long as part of the dealer base keeps its old habit, your internal team runs two channels at once and the expected saving never materialises. The rollout plan should contain a written date for closing phone orders.

Off-the-shelf platform or custom dealer portal?

• B2B module of a hosted platform — Wholesale modules on platforms such as Shopify Plus give you customer-group pricing and tax-exclusive display out of the box. Setup takes days. The limit: credit balance, risk limits and multi-step approval are either missing or very shallow.
• Standard platform plus a dealer layer — A separate dealer area is written on top of your existing store; catalogue and payment infrastructure are shared while pricing and approval logic are custom. 2-6 weeks. The most balanced route when the catalogue is large but pricing rules are only moderately complex.
• Custom dealer portal — An independent application wired into the ERP with its own rules engine. 8-16 weeks. The only realistic option when you need tiered discounts, territory and rep permissions, contracted prices and a mobile app for the field team.

One question settles the decision: can you describe your pricing rules in two sentences? If you can, a packaged module will do. If the description keeps going — "this dealer group is on that campaign, except the three on contract, and above 50 units it changes again" — stop forcing the module and look at custom development. We weighed that choice more generally in custom software or off-the-shelf.

Where the cost comes from

There is no single package price for B2B projects. Asking for the line items separately makes both comparison and scope discussion easier, and thinking in person-days shows you why two quotes differ so much.

• Analysis and pricing-rule discovery — Typically 3-8 person-days. Skip it and the rules get written twice during development; it is the most expensive saving on the list.
• Portal development — Catalogue, basket, approval flow, account screen, reports. Ranges roughly 25-60 person-days depending on scope.
• ERP / accounting integration — 8-25 person-days depending on the quality of the other system’s API. Low end for a cloud package, high end for an installed system that needs a middle layer.
• Data preparation — Cleaning up dealer records, price lists and product codes. In most companies this takes longer than the software and never appears in the quote.
• Rollout and dealer training — Pilot group, walkthrough video, support through the transition.
• Maintenance and iteration — The annual cost of changes on a running system. We broke this down in custom software cost.

If you also plan to collect card payments from dealers, the payment gateway and its commissions are a separate line; the detail is in payment integration for websites. If the retail side is being rebuilt at the same time, the cost of building an e-commerce site helps you plan both budgets together.

Five mistakes that kill dealer portal projects

• Hard-coding pricing rules — Discounts and campaigns belong to sales and marketing. If every change needs a release, the design is wrong. Rules should be data, not code.
• Showing stock from a nightly sync — What is in stock at 9am is gone by 3pm; the dealer orders, you cancel. Critical products need a live query or a reservation mechanism.
• Hiding the credit balance — It is the number dealers look at most. A portal that does not show it sends them back to the accounts department, and the "I am on the phone anyway, I may as well place the order" loop never breaks.
• Leaving mobile until later — Field reps and small dealers order from a phone. A table layout designed for desktop is unusable there; the portal has to be mobile-first from day one.
• Opening to every dealer at once — Start with a pilot group of five to ten, run real orders for two weeks, then launch. Every pricing and stock error surfaces in those two weeks.

Conclusion

A B2B dealer ordering system is not a private version of an online shop; it is a corporate project that translates your commercial rules into software. Ask the right questions at the start and the whole road gets shorter: how is the price determined, who sees the balance, who approves the order, and which system holds each of those three facts? With clear answers every option from a packaged module to a custom portal is on the table; without them, even the most expensive software brings the phone orders back. To shape a setup around your own dealer network, take a look at our corporate solutions service or request a quote and we will define the scope together.