A B2B portal is a closed platform for wholesale clients, dealers and partners, where every company sees its own price list, its own stock, its own limits and its own documents. What sets it apart from an online store is personalisation and the link to the accounting system: price, stock and shipment status come from 1C or an ERP, and the order goes back without manual re-entry.
Key takeaways
A store shows one shop window to everyone; a portal shows a different one to each client. Everything else follows from that: contract-based sign-in, personal prices, deferred payment, documents and roles inside the client company.
| What we compare | Online store | B2B portal |
|---|---|---|
| Access to prices | Open to everyone | Authorised companies only |
| Price | The same for all, discounts by promo code | Set by contract, depends on volume and category |
| Payment | By card, up front | Invoice, deferred payment, credit limit |
| Who buys | One person | Several employees with different rights |
| Order size | A few items | Hundreds of lines, file upload, repeat purchases |
| Documents | A receipt | Invoice, waybill, reconciliation act, tax invoice |
| Link to accounting | Desirable | Mandatory: without it the portal is useless |
If you already run a retail side, the portal does not replace it — it stands next to it and draws data from the same accounting system. What a retail shop window consists of is covered in the article on launching an online store.
Wholesale has no single price list: every client has their own discount, their own volume and their own arrangements. A portal turns those terms into part of the system instead of an email from a manager.
The terms live in the accounting system and the portal displays them. Keeping a discount matrix separately inside the portal is a trap: within a month it drifts from accounting, and the client sees one price while the invoice shows another.
A wholesale order differs from a retail one in the number of lines and in the fact that it repeats. So the scenario is built around speed rather than around a shop window.
After that the client tracks the order themselves: reservation, picking, shipment, delivery. The same set of statuses is used in notifications, so that nobody calls a manager to ask where their truck is.
Shipping rules deserve separate thought: pack multiples, minimum batch, indivisible items. If the portal lets a dealer order seven units where goods ship in boxes of twelve, a manager will be fixing the order by hand and the point of the automation is lost.
More than one person from the client company works in the portal, and their rights differ. A shared login for the whole company breaks both approvals and the investigation of disputes.
Inviting new colleagues must be the client's own job: otherwise user setup comes back to your managers and becomes the very routine the portal was built to remove. General requirements for sign-in, roles and access recovery are covered in the article on the client portal.
A separate case is a dealer with several legal entities or retail locations. One person then has access to several contracts at once, so the portal has to show which entity an order is placed for and file the documents under the right one.
When selling goods and services, legal entities, individual entrepreneurs and self-employed people are obliged to issue tax invoices to buyers — that is article 47 of the Tax Code of Uzbekistan. The same article says a tax invoice is as a rule drawn up in electronic form in the electronic invoice information system; the rule does not apply if the seller issued a cash receipt or another document of an established form.
Important This is not a recent change: Cabinet of Ministers Resolution No. 522 of 25 June 2019 made electronic invoicing voluntary from 1 July 2019 and mandatory for all business entities from 1 January 2020. The same document appointed the authorised roaming operator for inter-operator transfer and storage of electronic invoices.
For the portal this means something simple: it does not print paper forms and does not replace the electronic invoice system. Its job is to hand correct shipment data to the accounting system and to show the client a link to the issued document and the current state of settlements.
The portal becomes the front end of the accounting system, so the exchange is designed before the interface. For every block of data you define the owner, the direction and the update frequency.
| Data | Direction | How often it updates |
|---|---|---|
| Catalogue, attributes, images | From accounting to the portal | On a schedule, usually once a day |
| Stock across warehouses | From accounting to the portal | Several times a day or on a screen request |
| Personal prices and discounts | From accounting to the portal | On an event: contract terms changed |
| Dealer order | From the portal to accounting | Right after approval |
| Order status, reservation, shipment | From accounting to the portal | On an event |
| Invoices, waybills, reconciliation acts | From accounting to the portal | On an event and on client request |
| Payments and outstanding debt | From the bank and accounting to the portal | On a schedule, usually once a day |
If the warehouse and the accounting department run on 1C, the platform provides an automatic REST interface over the OData protocol — it is switched on for standard objects, while non-standard logic moves into separate handlers. How to choose between an API, a webhook and a scheduled export is covered in the article on integration with 1C, telephony and messengers.
Decide in advance how the portal behaves when the accounting system is unavailable. A workable option is to show the last known stock with a timestamp and queue orders for a retry. A silent failure is the worst outcome: the client believes the order went through while accounting has no record of it.
A portal does not tidy up your data — it shows the client what is already there. So the accounting side is checked before development starts.
The last point is organisational rather than technical, and it is usually the one that decides the fate of the portal. If a manager still takes orders in a chat, the dealer will not bother opening the portal.
The price consists of two parts: the web platform with a catalogue and orders, and the exchange with the accounting system. There is no separate B2B portal line on the service pages, so the nearest works serve as a reference.
The budget grows with the complexity of pricing, the number of warehouses and the requirements around documents. A portal with a single price list and a portal with a discount matrix, credit limits and order approvals are different projects. The scope of integration and accounting work is described on the page for ERP and systems integration.
Syntra Systems starts by examining the accounting side: where prices are kept, how stock is maintained, what happens to an order from a dealer's email to the shipment. That produces the exchange scheme, and only then the portal screens.
Then we build the portal as part of the infrastructure: orders reach the accounting system without manual re-entry, documents and settlements come back, and the exchange is logged with retries. After launch we look at which items dealers search for most and at which steps they go back to a manager — those are the places the portal is improved.
Let’s discuss your project
Tell us what you need, and we will estimate the timeline and cost and suggest a solution.
The measure is the volume of routine, not the number of clients. If managers forward price lists, calculate totals and issue invoices by hand every day, a portal pays off even on a small base. If orders arrive once a month and never repeat, there is no gain.
Sometimes: if the store platform supports closed sections, price groups and user roles. What needs checking is not the shop window but the depth of exchange with the accounting system and the handling of documents — that is where store platforms usually hit their ceiling.
What remains is scheduled file exchange and an intermediate database that accounting exports into. It works, but not instantly: stock in the portal will lag. In that case you agree in advance how stale the data may be and show that to the client.
For legal entities the main route stays the same: an invoice and a bank transfer, with the portal showing the payment state. Cards are usually used for small wholesale and prepayments; then a payment provider is connected, as in an ordinary online store.
The price is taken from the accounting system when the screen opens and fixed in the order at approval. The client sees a current line, and any dispute about the price an order was placed at is settled by the document record rather than by correspondence.
Move them over gradually, one scenario at a time: statuses and documents first, order placement later. An internal rule helps too — a manager enters chat orders into the portal, so the client's history accumulates in one place.
