B2B Ordering Portal for Distributors: Scope Guide

A B2B ordering portal lets approved customers see their own catalogue and prices, place and repeat orders and track documents, all synchronised with the ERP. Scope it in phases: accounts, prices and orders come first, payments and approvals follow — a portal that tries to launch complete usually launches late and half-used.

What is a B2B ordering portal?

A B2B ordering portal is a branded web channel where your approved distributors and trade customers log in and do business themselves: browse the catalogue visible to their account, see the prices agreed with them, build an order or repeat a previous one, and find the documents that belong to their account — quotations, orders, invoices, credit notes, deliveries. The ERP stays the system of record; the portal is the window onto it, with rules about what each account may see and do. Send your customer segments, price lists and ERP and we will quote a phased portal that starts with accounts, prices and orders: request a quote.

It is worth separating the portal from three neighbours it is often confused with:

• A webshop. Retail pricing, open registration, card checkout. A distributor portal is the opposite: access is granted per account, prices are contractual, and payment follows agreed terms rather than a checkout.


• A customer account area on a marketing site. Useful for downloads and support tickets, but without catalogue, pricing and order logic it does not remove a single phone call to the sales desk.


• A PDF price list on email. The state most distributors live in before a portal: accurate on the day it is sent, wrong by the week after, and unsearchable per account.

Feature table: must, should, later

Vendor feature pages list everything at once. Scoping by phase is what keeps the first release shippable. The table sorts the recurring features into what the first release needs, what the second usually adds, and what can wait for real usage data:

Table A: feature | purpose | phase (1/2/3) | ERP dependency

Phase 1 is the release that changes behaviour: if a distributor can log in, see their prices, repeat last month's order and get it into the ERP, the phone and spreadsheet channel starts to close on its own. Phases 2 and 3 add the money and governance layers, which need the organisation's credit, finance and approval decisions made before the software can hold them.

ERP and CRM integration

The integration decides whether the portal is a mirror of the business or a brochure with a login. Four questions need written answers before any architecture is chosen:

1. Sync direction. Master data — accounts, products, prices, terms — flows from the ERP to the portal. Orders, quote requests and payments flow back. Anything else needs an explicit owner: who may change a price, and where does that change live?


2. Sync frequency. Nightly batch, periodic refresh during the day, or near-real-time. The honest rule: prices and credit positions justify more frequent sync than product images do, so a mixed strategy is normal — critical data more often, catalogue content less often.


3. Failure handling. When the ERP is down or a record fails validation, what does the portal do: queue, reject, or show the last known state with a clear notice? Silent failure is how a distributor ends up ordering at last week's price, which becomes your dispute, not theirs.


4. Reconciliation. How do you know every portal order became exactly one ERP document — no duplicates, no gaps, no half-converted records? The answer is an operational report someone reads daily during the first months, and it is one of the acceptance tests below.

Multilingual and multi-currency catalogues

Exporters hit both questions early, and they are cheaper to decide than to retrofit.

Languages. The catalogue needs translations for product names, categories and documents; the account structure needs a language preference per account so the portal does not ask the same buyer to choose every visit. Two practical points: decide who owns translations and their update rhythm — a half-translated catalogue reads worse than an English-only one to the buyer who notices — and decide whether documents (quotes, invoices) follow the interface language or stay in the language your finance system requires. That second question is not technical: an invoice in the wrong language is an accounting problem.

Currencies. Prices agreed in one currency should be shown in that currency regardless of the visitor's location; mixing display currencies with contractual ones is how disputes start. If an account trades in more than one currency, the rule must live in the ERP data, not in the portal's settings, and the portal must never be the place where a conversion is invented.

Both topics interact with the phased plan: an exporter selling to three markets can launch phase 1 in the languages those three markets actually use in orders, and add further catalogue languages when the market does. The general rule for language work on commercial sites — one owner, one source file, one update path — is set out on the internet marketing page, and it applies to a portal catalogue the same way.

Security and roles

A portal is a door into your commercial data, so the design questions are access questions:

• Access is granted, never self-registered. Each account is created by your team against an ERP account; the alternative — open registration with an approval step — invites noise and blurs who is a customer.


• Role-based permissions. A purchaser may build and submit orders within a limit; an approver may release them; a viewer may only read documents. Limits per role are part of the commercial terms, not a technical afterthought — they encode who in your customer's organisation may commit them.


• Account isolation. The most serious failure mode in this product class is one distributor seeing another's prices or documents. Per-account data visibility should be tested explicitly, and it is one of the acceptance tests below.


• Audit trail. Who placed the order, who approved it, who changed a price and when — kept as data, not as log files someone has to be convinced to read. Disputes in trade are settled by this trail more often than by memory.


• Identity and single sign-on. For larger distributors, SSO into their own directory is a frequent requirement worth scoping late rather than early — most accounts run happily on invitations and passwords until a head office asks for federation.


• Data protection. Customer data in the portal falls under the same duties the company already has for its customer records; for Turkish operations that is the KVKK framework and for European customers the GDPR, a topic treated in detail on the outsourcing page in the context of working with a development partner.

Build vs platform

The choice is not custom versus packaged in the abstract; it is about which layer you are actually buying.

Table B: route | what you get | what you carry | suits when

The middle route is chosen by most exporters the first time, and the mistake to avoid is treating it as the cheap one: a connector is a maintained product, and its cost is recurring. The decision framework for this question — configure, buy, or build — is treated at length on the custom vs packaged ERP page; what this page adds is the portal-specific test: whatever you choose, the price list per account and the order into the ERP must be provably correct, and the route you pick should be the one that makes that provable at the lowest recurring cost.

Phased rollout and acceptance tests

A portal launch fails quietly when "it works" means "the demo worked". Each phase should carry written acceptance tests, run with real accounts and real data:

1. Catalogue visibility per account. Log in as two different distributors; each sees exactly its own product set and no trace of the other's. Tested deliberately, not assumed.


2. Pricing accuracy. For a sample of accounts and articles, the portal price equals the ERP price — including the rules behind it (price group, tier, agreement). This is the test that protects the commercial relationship; a wrong price in a portal is worse than a wrong price in a quote, because the customer saw it as the standing agreement.


3. Order integrity. An order placed in the portal becomes exactly one ERP document, with correct articles, quantities, units and prices — and the reconciliation report shows it. Test the failure path too: an order blocked by a rule should say so clearly rather than failing silently.


4. Status and documents. An invoice and a delivery recorded in the ERP appear in the right account's portal view, with the right status, within the agreed sync window.


5. Terms and limits. Credit and payment terms per account display correctly, and where the rules say an order should be blocked or flagged, it is blocked or flagged — tested at the boundary, not in the comfortable middle.


6. The daily habits. Reorder, quick order by article number, and search — with two of your real distributors' product lists, not the demo catalogue. Adoption lives or dies on these three paths, and they cost a fraction of the build to test properly.

Frequently Asked Questions

Do we need an ERP first?

Not a new one — but you need the master data somewhere trustworthy: accounts, products, price lists and terms. If those live only in spreadsheets, the portal will automate the spreadsheet's errors per account, which is worse than staying on the phone. In that case the honest sequence is to stabilise the data first (often in an existing ERP that is underused), then portal afterwards; the Odoo for trading companies page treats that decision from the ERP side.

Can customers have their own price lists?

Yes — per-account pricing is the core of the product class, not an extra: price groups, tiered pricing or individual agreements, all held in the ERP and shown per account. The rule to insist on is that the portal never prices anything itself; it displays what the ERP holds, and every price a distributor sees can be traced to an agreement your team made.

How are orders approved?

Two layers, usually. Inside your customer's organisation, approval is theirs: a purchaser proposes, an approver releases, optionally within limits — the portal can carry those roles in phase 3. Inside your own organisation, the order arrives in the ERP and follows your normal order handling; the portal does not replace your sales desk's controls, it removes the re-entry and the phone call around them.

Can the portal handle multiple languages?

Yes, and it should — but decide the scope per phase. Catalogue translations, per-account language preference and translated documents are three different jobs; launch phase 1 in the languages your active markets use in orders and add the rest with real demand. The governance points — one owner for translations, one update path — are in the multilingual section above.

Who owns the data?

You do — accounts, prices, orders, documents and history remain the company's records, in the ERP. This is worth stating in the contract with whoever builds the portal: hosting access, source code or configuration, and export of your data at exit, all named. The outsourcing page covers intellectual property and exit terms in the wider development contract context.

How do we onboard distributors?

Start with the accounts that order most, invite them personally, and give them three things in the first message: their login, their price list visible on screen, and one person to call. Then watch the adoption signal that actually matters — not logins, but the share of reorder volume that arrives through the portal. Parallel working (portal ordered, then confirmed by phone) is normal for weeks; it ends when the portal is provably right on prices and documents, which is what the acceptance tests above are for.

Sources and standards

• The typical feature set described here (accounts, per-account price lists, reorder, invoices and credit notes, per-account visibility, roles with limits, net terms, payment gateways) follows vendor-described capability lists for B2B ordering portals generally; no performance outcome, cost or timeline is claimed on this page.
• Deployment patterns (ERP-native portal; commerce platform such as Shopify synced to the ERP through middleware or connectors) are described as the two recurring routes; no partnership with any platform vendor is claimed.
• Process and governance statements follow this site's pages: custom vs packaged ERP, vendor RFP checklist, Odoo for trading companies and IT outsourcing from Türkiye (data protection duties, IP and exit terms, pilot design).
• No client examples, portal budgets or project durations appear on this page; scope, phasing and commercial terms are set per project in the quotation.

Related pages

Software development · Custom vs packaged ERP · Vendor RFP checklist · Odoo ERP for trading companies · Internet marketing · Request a quote