Your dealers order themselves, on their own terms, into your ERP

What is a B2B dealer portal?

A B2B dealer portal is an ordering site your dealers and distributors sign into to see their own terms — contract prices, discounts, credit limit, open balance, live stock and order history — and to place orders that land in your ERP as sales orders. It is not a shop: every visitor is a known account, and every price is calculated for that account.

Two things separate it from a webshop with a login bolted on. First, price is resolved per session from commercial rules rather than read from a single list. Second, ordering is governed: credit limits, overdue balances and approval chains decide whether an order proceeds, and the ERP stays the system of record throughout. The terminology varies — dealer order portal, distributor portal, B2B ordering portal — but the mechanism below is the same one.

What actually breaks when dealers order by phone and email

These are the failure modes we hear described almost word for word by manufacturers and distributors, regardless of sector.

• The dealer orders from an old price list. A PDF was emailed in March. Prices changed in June. The dealer orders at the March price, the invoice carries the June price, and someone in finance now owns a credit note and an uncomfortable phone call.
• The discount is applied from memory. A dealer has a contract rate on one product group, a volume break on another and a campaign on a third. Whether all three are applied correctly depends on which person takes the order.
• The order is typed twice. Once by the dealer into a message or a spreadsheet, once by your staff into the ERP. Every transcription is an opportunity for the wrong code, the wrong quantity or the wrong variant.
• Stock is quoted from yesterday. Availability is confirmed on the phone from a report, then the same units are promised to a second dealer an hour later.
• Credit control happens after dispatch. The order is shipped, then finance discovers the dealer was already past their limit with invoices sixty days overdue. Recovering it is now a commercial negotiation instead of a rule.
• The support line answers the same four questions. Is it in stock, where is my shipment, what is my balance, can you resend that invoice. All four have factual answers already sitting in your systems.
• Nobody knows what a dealer did not order. Without a record of what each dealer browsed, ordered and stopped ordering, a declining account is noticed when the quarterly figures arrive.

What a dealer portal covers, and what stays in the ERP

A portal is a front end for commercial self-service. It is not a second ERP, and building it as one is the most common way these projects go wrong. If your ERP already ships a customer portal module, the module-versus-separate-portal comparison sets out where that module stops and what it costs per external user.

• Catalogue with the products, variants and units that a given dealer is allowed to buy
• Per-customer pricing: contract prices, group discounts, volume breaks, campaigns, currency and payment-term rules
• Live stock with reservation at order confirmation, and a stated lead time when stock is short
• Fast reordering: order history repeat, SKU paste, spreadsheet upload, size and colour grid entry
• Account balance, ageing, statements, invoices and receipts available for download
• Order approval chain on both sides: the dealer's own approver, and your credit or discount approval
• Shipment tracking with the carrier reference and the delivery document
• Card payment where you want a payment option that is not open account
• Target and rebate visibility, so a dealer can see where they stand against an agreed volume threshold

What stays in the ERP: the general ledger, invoice issuing, statutory e-invoice formats, tax, payroll and official inventory valuation. The portal reads from and writes to those; it does not own them. Where the boundary sits for each system is described on integrations.

How per-customer pricing actually works

This is the part that decides whether a portal is trusted, so it is worth describing precisely. The portal does not store “the price”. It stores rules, and resolves them for the logged-in dealer at the moment the screen is rendered.

1. Identify the commercial identity

   The login maps to a customer account, and the account carries its price list code, customer group, currency, payment term, and any contract-specific agreements. A dealer with three delivery addresses is still one commercial identity; a group with two legal entities is two.

2. Resolve in a fixed order

   A contract price for a specific product beats a customer-specific discount, which beats a group discount, which beats a campaign, which beats the base list price. The order is defined once, agreed with your commercial team, and applied everywhere. Ambiguity here is what produces two prices for the same order.

3. Apply the quantity and term layers

   Volume breaks apply to the resolved unit price. Payment term surcharges or early-payment discounts apply to the line or the order total, whichever your terms actually say. Currency is fixed to the account, with the rate source and rate date recorded on the order.

4. Freeze the price on the order

   When the dealer confirms, the resolved price, the rule that produced it and the exchange rate are written onto the order line. A later price change does not retroactively alter a placed order, and when a dispute arises the order itself explains how the figure was reached.

The same engine drives the printed or exported price list, so the document a dealer downloads and the screen they order from cannot disagree. That single property removes most invoice disputes on its own.

Credit, balance and the approval chain

Self-service ordering without credit control is just a faster way to ship goods to someone who cannot pay for them. The portal enforces the rules you already have, before the order exists rather than after it ships.

B2B dealer portal and ERP: how the two stay in one truth

Most of the risk in a dealer portal project sits in this layer, so we specify it before anything else is built. Two directions, three refresh classes, one reconciliation.

• ERP to portal, scheduled: product master, units and variants, base price lists, customer accounts, price list assignments, payment terms and credit limits. These change slowly, so a scheduled sync is enough, with an on-demand refresh for urgent changes.
• ERP to portal, near real time: stock levels, open balance and overdue ageing. These decide whether an order can be placed, so they are read close to the moment of the decision rather than from an overnight copy.
• Portal to ERP: confirmed orders as sales orders carrying the resolved prices and the applied rules, plus card payments as receipts. Approval status travels with the order so the ERP does not have to re-derive it.
• Reconciliation: a nightly job compares what the portal believes about open orders, balances and stock with what the ERP holds, and reports the differences to a person. A sync without a reconciliation looks fine right up to the day it does not.

Where an ERP has no usable API, the bridge is built on the interfaces it does offer — database views, file exchange, or a staging table it already reads. That is slower to design and entirely workable; what it is not is something to discover halfway through the build, which is why the integration is scoped first.

B2B dealer portal vs. a consumer e-commerce platform

The question is usually put as “why not just use a shop platform?”. That is a fair question, and the answer is criterion by criterion.

To be clear about the other side: a shop platform is genuinely the right answer when you sell the same price to everyone, take payment at checkout and do not need an ERP round trip. The comparison of packaged and custom is worked through on package versus custom.

When a B2B dealer portal is the wrong investment

• Low dealer count, low order frequency. Ten dealers ordering twice a month is a relationship, not a throughput problem. The portal would replace conversations that both sides value.
• Every order is negotiated. If price, lead time and specification are agreed case by case, there is no catalogue to browse and no rule to resolve. Automate the quotation instead.
• Configure-to-order products. When the customer specifies rather than picks, you need a configurator with engineering rules behind it. That is a different and larger build; the ordering portal can come afterwards.
• Your master data is not trustworthy yet. If product codes, units and price list assignments in the ERP are wrong, the portal will publish those errors to your dealers with full confidence. Clean the master data first; it is cheaper and faster than debating the software afterwards.
• Dealers will not use it and nobody will require them to. Adoption is a commercial decision, not a technical one. If order intake is not eventually moved onto the portal by policy, both channels stay open and you have added work rather than removed it.

How a build starts

1. Pricing rules and ERP interface, on paper

   Two documents in the first week: the price resolution order agreed with your commercial team, and the list of ERP objects and interfaces the bridge will use. Almost every failed portal we have been asked to rescue skipped one of these.

2. Prototype in the first 2 weeks

   Clickable screens with your own products and three real dealer accounts on their real terms, so your sales team can confirm that the price the screen shows is the price they would have quoted.

3. First module in production, 2–4 weeks

   Catalogue, per-customer pricing, order entry and write-back to the ERP, at $3,000–6,000. Piloted with a handful of cooperative dealers while the phone channel stays open.

4. Add the commercial layers

   Balances and statements, credit rules and approval chains, card payment, shipment tracking, targets and rebates. A full portal lands at $8,000–15,000 over 4–8 weeks; the bands are on pricing.

Related systems we have built

Portals of this kind sit on top of the same operational core as the rest of our work: Elevatora SAHA, a multi-tenant lift maintenance and field service system, Elevatora İMALAT, a manufacturing and ERP system for lift components, SEMP Group, a group-wide operations platform, SmartHukuk, our own legal technology product, and a pharmaceutical import and export process tracking system. Elevatora PROJE, our project tracking system, is still in development. Descriptions are on cases; the manufacturing side is on manufacturing, and the customer-facing application layer on web development.

Frequently Asked Questions