Apps and PWA
A B2B portal for wholesalers: a ready-made platform or a custom portal?
Short answer
A B2B portal is a closed, signed-in part of sales in which a business customer sees their own prices, limits, documents and order history, and the data comes from the ERP. A ready-made B2B platform is enough when the sales process is standard. A custom portal makes sense when a wholesaler's advantage is non-standard processes: account activations, price lists, serving many branches and linking sales with invoices and receivables.
A wholesaler that sells to businesses sooner or later arrives at the same question: buy a ready-made B2B platform from an ERP vendor or from the SaaS market, or build a portal around its own processes? Vendors' offers mainly compare lists of features. We propose a different criterion: where your wholesaler's advantage lies and how many processes you want to tie together in one place.
This guide is for wholesalers' owners and sales directors. We clear up the terms, show what a B2B portal must be able to do, how it connects to an ERP and how to make the decision. At the end we describe how it looks at our end, using a deployment in a company from the wholesale industry as an example.
A B2B portal, a B2B platform, a B2B shop — straightening out the terms
In short: these are three names for similar solutions. A B2B shop suggests a basket and a catalogue, a B2B platform a ready-made vendor product, and a B2B portal a broader, signed-in application for customers and the team.
- A B2B shop (what it means in practice): a catalogue and a basket for business customers. It differs from a B2C shop in that prices, discounts and available goods depend on the customer, and payment is usually by bank transfer with a term, within a trade limit.
- A B2B platform: a ready-made product, usually offered by an ERP vendor or a SaaS company, with a connector to specific systems. You configure it, but you do not write it from scratch.
- A B2B portal: a signed-in application in which a business customer manages the relationship with the wholesaler: orders, but also documents, payments, complaints. It often also has an internal part for sales reps, the warehouse and accounting.
The boundaries are fluid. More important than the name are the processes the system handles and where it gets its data from.
What a B2B portal in a wholesaler must be able to do
In short: five things: prices and commercial terms from the ERP, current stock levels, controlled account activation, documents with receivables, and roles. The rest are add-ons.
Individual price lists and commercial terms from the ERP
A wholesaler rarely has a single price list. There are discount groups, contract prices, promotions, trade limits and payment terms. All of this should come from the ERP, not be maintained a second time in the portal. If a sales rep changes a discount in the ERP, the customer should see it without a manual export.
Stock levels and availability in near real time
A B2B customer orders for a specific job. An "available" label on goods that are not there costs a phone call to a sales rep, and sometimes the customer. Decide with what delay stock levels may appear in the portal and whether you show the exact quantity or ranges ("plenty", "low", "on order").
Customer account activation
An account in a B2B portal is in practice consent to sales with deferred payment. That is why, before the customer sees prices, it is worth checking the company in public registers, and each of them has an official API:
- GUS (REGON): name, address, legal form, through the REGON API (BIR1), free of charge, after obtaining a key,
- CEIDG for sole proprietorships, through the CEIDG data warehouse and API,
- KRS for limited companies, through the Ministry of Justice's KRS API,
- the VAT white list: taxpayer status and bank accounts, through the VAT taxpayer list API.
On top of that a decision on the limit and the payment term, and a contract, best generated from a template as a PDF and sent automatically. Account approval run in email inboxes is a frequent bottleneck: the application waits until someone notices it.
Documents, receivables and payment reminders
A customer wants to see invoices, orders and what they have to pay in one place. The wholesaler wants payment reminders to go out on their own, and a sales rep to see the receivables of their portfolio before accepting the next order.
Roles: customer, sales rep, warehouse, accounting
A customer sees only their own data. A sales rep their own customers, a manager their own branch, accounting the receivables. Well-designed permissions are also security: two-factor sign-in for employees and a change log.
How does a B2B portal connect to an ERP?
In short: either it works online directly on ERP data, or it has its own database synchronized cyclically. Each approach has costs, and in practice the two are often combined.
Online mode on the ERP database vs cyclic synchronization
Simplified, regardless of the vendor:
| Online mode on the ERP database | Cyclic synchronization | |
|---|---|---|
| Currency of prices and stock levels | always current | with a delay depending on the schedule |
| Load on the ERP | reads go to the ERP (depending on cache) | queries in batches, outside peak hours |
| ERP failure | the portal loses access to data | the portal works on the latest data, orders wait in a queue |
| Freedom of development | depends on the ERP structure | the portal can have its own data and processes |
Both models can be seen in the Comarch documentation. According to it, Comarch B2B works "online directly on the ERP system's database" and "no synchronization process is performed", while Comarch e-Sklep in the B2B version exchanges data with the ERP through synchronization.
An intermediate solution: fast data (stock levels, prices) synchronized often, heavy data (history, registers) less often, and writes to the ERP through a queue with retries.
Who "owns" the data
Before you start the integration, write out every class of data:
- prices and terms: the ERP, the portal only reads,
- stock levels: the ERP (or a WMS), the portal only reads,
- customers: registration in the portal, the register in the ERP after activation,
- orders: created in the portal, fulfilled in the ERP, and the status goes back to the portal.
A typical mistake: editing the same piece of data in two places. It ends in a dispute about which system is right and manual reconciliation.
What about KSeF
Invoices for B2B customers are issued in KSeF (Poland's National e-Invoicing System) from the system in which they are created, that is, usually from the ERP. The obligation covered companies that had sales above PLN 200 million with VAT in 2024 from 1 February 2026, and the rest from 1 April 2026 (MoF: from when invoices must be issued in KSeF). Until the end of 2026 the smallest taxpayers may still issue invoices of up to PLN 10,000 gross per month outside KSeF, so some invoices from suppliers will still arrive another way (MoF: below PLN 10,000). The buyer receives the invoice in KSeF, and the seller may additionally issue its visualization with a QR code and the KSeF number (MoF: issuing and receiving invoices). A B2B portal therefore does not have to issue invoices. Its role is to show the customer the document, and if it makes it available outside KSeF, for example as a PDF, the visualization must have a QR verification code.
A ready-made B2B platform or a custom portal?
In short: a ready-made platform wins on time to start and predictability, a custom portal on fit to the process and ownership of the solution. What decides it is whether your advantage lies in the standard or in the exceptions.
| Criterion | A ready-made B2B platform | A custom portal |
|---|---|---|
| Fit to the process | you adapt the process to the platform | you adapt the portal to the process |
| Integrations | ready connectors to supported ERPs, others have to be built | any: ERP, registers, email, KSeF, supplier systems |
| Cost | a licence or subscription, usually depending on scale | building and development; the billing model (licence, subscription, transfer of rights) is set in the contract |
| Time to start | fast if the process is standard | an MVP with one module, then in stages |
| Ownership of code and data | on the vendor's side, data as per the contract | code to be agreed in the contract; data always on the company's side, with the right to export |
| Vendor lock-in | high: the vendor sets the roadmap and prices | depends on the contract: access to code, documentation and data export |
| Module development | what is in the offer and the roadmap | what the business needs |
A ready-made platform is a good choice when you sell by a typical process, your ERP is supported by the platform, and a quick start matters most. A custom B2B portal makes sense when serving a business customer involves many "exceptions that are the rule": multi-stage activations, price lists from many suppliers, branches with their own plans, debt collection run by sales reps.
You do not always have to choose. Often the best is a combination: orders on a ready-made platform, and the processes around it in a portal. Typical mistakes when choosing:
- comparing feature lists instead of the processes that are really the problem,
- overlooking the cost of adapting the platform to a non-standard process,
- no clause on data ownership and export when changing vendor,
- building everything at once instead of one module that saves time straight away.
A B2B portal is more than orders — an example from a wholesaler
Our Business Panel runs in a company from the wholesale industry and shows the combined model well. It is a panel for a wholesaler's team. Customers order on an external B2B platform, and the panel integrated with Comarch ERP XL handles everything around the orders. In the context of this article three elements matter most:
- B2B account activations. A new customer from the platform arrives in the panel through a webhook, and opening a trade account goes through a multi-stage workflow with company verification in registers, a limit and a payment term. A PDF contract is created from a template and sent by email.
- Receivables and debt collection. Open payments from Comarch ERP XL, email reminders and demands with a schedule. A sales rep sees their own portfolio, a manager their own branch.
- The combined model. The panel synchronizes registers and sales data with Comarch ERP XL cyclically, every few minutes, and reads part of the data directly from the ERP. Writes to the ERP wait in a retry queue when it is unavailable.
The remaining modules (CRM, supplier price lists, KSeF invoices, B2B leads from registers) we describe in the Business Panel case study. The whole catalogue of systems we work with is on the technologies and integrations page.
Performance in practice
In this deployment 40–50 wholesaler employees work in the panel at the same time, and views load in about 0.5 s. In a load test a single server handled about 300 active users at once.
How to start building a B2B portal?
In short: with a process workshop, then an MVP with one module that relieves the team straight away, and development in stages. The first working version is typically ready with us in 2–3 months from the start of the project.
- A workshop. Write out the B2B customer's process from registration to payment. Mark the places where data is retyped by hand and the decisions waiting in email inboxes.
- A data map. For each class of data decide the source and direction: what the portal reads, what it writes to the ERP.
- An MVP with one module. Choose the module with the biggest gain, for example account activations or receivables. Start with one branch.
- Development. Further modules on the same data and permissions. If the team works in the field, the portal can run on a phone as a PWA.
If the main problem lies in the shop itself and not in the processes around it, start with the integration. We describe it in the guide on shop-to-ERP integration: Magento, BaseLinker, Comarch and on the page about e-commerce optimization.
Want to check whether a ready-made platform, a portal or a combination of both will work better in your wholesale business? See how we build custom applications, or write to us. We start with a free consultation.
Questions and answers
What is a B2B portal and how is it different from an online shop?
A B2B portal is a signed-in part of sales for business customers. Unlike a B2C shop, every customer sees in it their own prices and discounts, a trade limit, a payment term, documents and receivables, and an account is created after the company has been verified, not with one click.
How does a B2B portal connect to an ERP?
In two ways. In online mode the portal reads data directly from the ERP, so prices and stock levels are always current, but performance depends on the ERP server. In synchronization mode the portal has its own database that it regularly fills with ERP data, and it sends orders back to the ERP. In practice the two approaches are often combined.
When is a ready-made B2B platform enough for a wholesaler, and when is a custom portal better?
A ready-made platform is enough when the wholesaler sells by a standard process, has an ERP supported by the platform vendor and wants to start quickly. A custom portal pays off when the company's advantage is its own processes, for example multi-stage account activations, non-standard price lists, many branches working, or the need to link sales with invoices, receivables and CRM in one place.
Which B2B portal features matter most for a wholesaler?
Individual price lists and commercial terms from the ERP, current stock levels and availability, controlled activation of a customer account with company verification in registers, access to documents and receivables, and roles for the customer, sales rep, warehouse and accounting. Without these elements the portal becomes an ordinary order form.
How many people can work in the portal at the same time?
It depends on the architecture and infrastructure, not on the idea of a portal itself. In our Business Panel (an application for a wholesaler's team, that is sales reps, accounting and managers) 40–50 employees work at the same time, and views load in about 0.5 s. In a load test a single server handled about 300 active users at once. This is deployment data, not a guarantee.
Sources
- Differences between e-Sklep B2B and Comarch B2B (online mode on the ERP database) — pomoc.comarch.pl (in Polish)
- Below PLN 10,000 — an exception until the end of 2026 — Ministry of Finance, ksef.podatki.gov.pl (in Polish)
- From when invoices must be issued in KSeF — Ministry of Finance, ksef.podatki.gov.pl (in Polish)
- Issuing and receiving invoices — Ministry of Finance, ksef.podatki.gov.pl (in Polish)
- QR verification codes — Ministry of Finance, ksef.podatki.gov.pl (in Polish)
- REGON API (BIR1) — Statistics Poland (GUS), api.stat.gov.pl
- CEIDG data warehouse and CEIDG API — dane.biznes.gov.pl
- KRS API — Court Registers Portal, Ministry of Justice
- VAT taxpayer list API (the white list) — Ministry of Finance, wl-api.mf.gov.pl
Legal and technical status as of 9 October 2026. This article is for information only and is not legal or tax advice.