The short answer
A B2B customer self-service portal is a login-only area where your business customers see their own prices, stock levels, orders, invoices and outstanding balance, and place orders themselves instead of emailing or phoning a sales rep. For wholesalers, distributors and manufacturers it usually pays off not as a "new sales channel" but because it removes manual order entry, pricing errors and the endless "where is my delivery" and "how much do we owe" questions.
A portal only works if it is properly connected to your accounting or ERP system. The integration, not the design, drives most of the project's complexity, cost and value. Below we cover which features you actually need, how the portal connects to your ERP, when it pays off and which mistakes to avoid.
How a B2B portal differs from a regular online store
At first glance it's the same catalogue with a basket. The differences show up once you look at how business customers buy:
| B2C online store | B2B customer portal | |
|---|---|---|
| Prices | One price for everyone, promotions | Customer-specific price lists, discounts by customer, product group or quantity |
| Payment | Card or bank transfer up front | Payment on terms, credit limit |
| Buyer | One person | A company with several users and different permissions |
| Orders | A few items, occasionally | Dozens of lines, often the same ones repeated |
| Documents | A receipt by email | Invoices, credit notes, delivery notes, certificates, contracts |
| Access | Open to anyone | Approved customers only |
There is a legal difference too. The European Accessibility Act (Directive (EU) 2019/882) defines e-commerce services as services provided at the request of a consumer with a view to concluding a consumer contract, and a consumer as a natural person buying outside their trade or business. So a portal that only serves companies generally falls outside that scope. If private customers can buy through the same store, the requirements apply. We cover this in more detail in our article on WCAG and the European Accessibility Act. Even where accessibility isn't mandatory, a clear, keyboard-friendly interface saves your trade customers time.
The features you actually need
You don't have to build everything at once. Here is the order in which we usually recommend rolling features out.
Phase one: without these the portal is pointless
- Customer-specific prices. A logged-in customer sees their price, not a list price with "your price may differ". Prices should come from wherever you manage them today, usually your accounting system or ERP.
- Stock and lead times. At minimum "in stock / out of stock / expected" per warehouse. If you run several warehouses, show which one the item ships from.
- Quick ordering. Search by product code, enter quantities in a list, upload an order from a CSV or Excel file, and "repeat a previous order". Trade buyers rarely browse categories; they know what they want.
- Order history and status. What was ordered, confirmed and shipped, with tracking numbers.
- Invoices and balances. An archive of invoice PDFs, unpaid amounts and due dates.
Phase two: features that cut manual work
- Credit limits and payment terms. The portal knows how much more the customer can buy on credit, and either offers prepayment or holds the order once the limit is exceeded.
- Multiple users per company. A site foreman at a construction firm builds the basket and the purchasing manager approves it. The accountant only sees invoices.
- Delivery addresses. A company with several sites or shops picks the address at checkout instead of typing it into a comment.
- Document library. Certificates, data sheets and declarations of conformity attached to the right products.
- Saved lists. Customers keep lists of regularly ordered items by site or department.
Phase three: once the basics work
- Returns and claims with photos and status tracking.
- Quote requests for larger quantities, approved by your sales rep inside the portal.
- API or EDI access for your largest customers, who want to send orders straight from their own system.
- Customer reports: what they bought over the year, by department.
ERP integration: what gets synced and how
On many projects the integration takes more effort than the portal's interface. Start by deciding which system is the source of truth for each type of data.
| Data | Direction | How often | Worth knowing |
|---|---|---|---|
| Products and descriptions | ERP to portal | Daily or on change | Descriptions and images are often easier to keep in the portal, codes and prices in the ERP |
| Price lists and discounts | ERP to portal | On change | The hardest part: discount rules sometimes live in people's heads, not in the system |
| Stock | ERP to portal | Every few minutes or real time | Reservations, so you don't sell the same item to two customers |
| Customers and terms | ERP to portal | On change | Payment terms, credit limit, price group |
| Orders | Portal to ERP | Immediately | An order must never disappear on error: you need a queue and retries |
| Order status and shipments | ERP and couriers to portal | On change | Tracking numbers from the courier's system |
| Invoices and balances | ERP to portal | Daily or on change | A PDF archive and the balance, not just a list |
In Lithuania the usual systems are Rivilė, Directo, Agnum, Finvalda, Centas or larger ERPs, each with different API capabilities and limits. We walk through what that looks like in practice in our article on integrating Rivilė, Directo and Agnum, and shipping connections are covered in our courier integration guide.
A few principles prevent most problems:
- Calculate prices in one place. If the same discount logic is written in both the ERP and the portal, sooner or later they will drift apart. Either the portal receives ready-made price lists, or it asks the ERP for a price at order time.
- Orders must never get lost. If the ERP is unavailable, the order waits in a queue and is sent later, and someone can see what's stuck.
- Show how fresh the data is. If stock updates every 15 minutes, both the customer and your sales team should know.
- Keep an audit log. Who ordered, approved or changed what, and when. It's the first thing anyone asks for in a dispute with a trade customer.
Invoices, payment terms and the law
The portal is a convenient place to show due dates and balances, but the law sets the limits. Under Lithuania's Law on the Prevention of Late Payment in Commercial Transactions, the payment period between businesses may not exceed 60 calendar days unless the contract expressly says otherwise and this is not unfair to the creditor. When the buyer is a public body, the general rule is 30 calendar days from receipt of the invoice. The same law treats the invoice receipt date as uncertain if the invoice was not sent electronically. An invoice archive in the portal with a clear publication date helps avoid arguments about when an invoice was received.
If some of your customers are public sector bodies, their invoices still have to go through SABIS, Lithuania's public sector e-invoicing system. The portal doesn't replace that, but it can reuse the same invoice-sending logic. We explain the details in our article on e-invoicing, SABIS and Peppol.
Off-the-shelf module, ERP add-on or custom portal
There are three main routes, and none is right for everyone.
A B2B module for your existing online store. If you already run WooCommerce, PrestaShop or similar, you can add logins, price groups and payment on terms. It's the fastest and cheapest route when customer terms are simple: a few price groups, one user per company and a straightforward ERP link. Problems start when you need multiple users with approvals, credit limits pulled from the ERP or complex discount rules. That's when several plugins start fighting each other.
Your ERP vendor's portal. Some accounting and ERP systems offer their own customer portal or web shop module. Integration is solved from day one, but design and features are limited and the portal tends to look like accounting software. It works well when the portal is mainly for viewing invoices and balances.
A custom portal. Built around your ordering flow, pricing and ERP. It costs more up front but gives you more room when your trade has its own logic: configurable products, orders by project site, approval chains, integration with several systems. In that case, write the requirements down before asking for quotes so that supplier proposals are comparable. Our technical specification guide will help.
We used the same five-year comparison of off-the-shelf versus custom in our article on CRM systems.
When does a portal pay off?
Nobody can give you a figure without your data, but you can work it out yourself. Collect a few numbers for the last three months:
- how many orders arrive by email, phone or messaging apps, and how long it takes on average to key one into your system;
- how many orders need correcting because of a wrong price, code or quantity;
- how many questions your sales team gets about stock, deliveries, invoice copies and balances;
- how often you sold something that was no longer in stock.
Multiply the hours by your hourly staff cost and add the cost of the errors. If you get a dozen or so orders a month from the same customers, a portal probably won't pay for itself and a better order template will do. If you handle hundreds of orders from dozens of customers or more, a portal is often the cheapest way to grow without growing your sales admin team.
Don't forget the running costs: maintenance, hosting, updates and integration changes when your ERP changes. We break down what drives the cost of custom software in How much does custom software development cost.
Example: a distributor that took orders by email
The company below is fictional and the numbers are for illustration only.
Northline Supply is a distributor of plumbing and heating products selling to installers and construction firms. It has about 300 customers and around 8,000 product codes, with prices varying across five customer groups plus individual discounts for its biggest accounts. Its books are kept in Rivilė.
Orders arrived by email as Excel files, photos or simply lists typed into the message. Three sales reps spent a large part of their day re-entering orders and answering questions about stock, and orders with outdated prices slipped through every week.
The portal went live in two phases:
- Phase one (about three months). Customer logins, individual prices and stock from Rivilė, quick ordering by product code, order upload from Excel, order history and an invoice archive. Orders flow into Rivilė automatically.
- Phase two. Credit limits, multiple users per company with approvals, shipment tracking and a certificate library.
For the first few months some customers kept sending emails. A simple fix helped: the reps entered the order in the portal on the customer's behalf and sent them a link so they could see how it works. The main benefit wasn't fewer staff. The same team served more customers, and pricing errors all but disappeared.
Common mistakes
- Starting with design instead of data. If pricing rules and customer terms aren't set up properly in the ERP, the portal won't fix them.
- Copying a B2C store. Big product photos and category browsing matter less to a trade buyer than fast ordering by code.
- Not onboarding customers. A portal your customers don't know about saves nothing. You need a clear launch, help with the first orders and sales reps who use it themselves.
- Building everything at once. It's better to launch the core within a few months and extend it based on what customers actually use.
- Forgetting permissions. Who in the company sees prices, who can order and who approves. Misconfigured permissions mean one customer's employee can see another customer's terms.
- Not agreeing on ownership. Put in the contract who owns the code and the data. You'll find more questions worth asking before you sign in How to choose a software development partner.
FAQ
Can the B2B portal and the online store be one system?
Yes. A common setup is one platform with two modes: a public catalogue or shop for private buyers and a closed area for trade customers with their own prices and terms. What matters is that both share the same product and stock data.
How long does it take to build a B2B portal?
It depends on the features and on how complex the ERP integration is. A first working phase with prices, stock and orders can usually go live within a few months rather than a year, provided the scope is clearly limited and the ERP has a usable API.
Does a portal replace a CRM?
No. A CRM is for your team to manage customer relationships; a portal is for the customers themselves. They work best together: your sales rep sees in the CRM what the customer ordered in the portal and whether they ran into problems.
Do we need a mobile app?
Usually not. A portal that works well on mobile is enough. An app is only worth considering when customers order frequently from the field, for example by scanning product barcodes.
Can we start with invoices and balances only?
Yes, and it's often a good first step. Customers get used to logging in, you take fewer calls asking for invoice copies, and ordering can be added in phase two.
Next steps
Start with three questions: how many orders and enquiries are handled manually today, where your prices and customer terms live, and what kind of API your accounting or ERP system offers. The answers will show whether a module for your existing store is enough or a custom portal is worth building.
DESAmedia builds B2B online stores and customer self-service portals integrated with accounting, warehouse and courier systems. Find out more on our custom e-commerce development, web application development and integrations and automation pages, or get in touch through our contact page to talk through your situation.