A business customer's order arrives by email. The salesperson finds the right price list, checks the discount, calls the warehouse and retypes the data into the ERP. If an item is out of stock, another round of coordination follows. The customer later calls again, because they do not know whether the order was accepted and when it will be delivered.
A B2B ordering portal turns this process into a controlled data flow. The customer logs in, sees their prices and availability, places an order and tracks status and documents in the same place. The ERP stays the central business system, and the portal adds a simple, secure interface for buyers.
In practice the same solution is often also called a customer portal, B2B ordering or a wholesale portal. The name matters less than the fact that data on the customer, price, stock and order stay consistent with the back end system.
What a B2B portal is and what it does not replace
A B2B portal is a private web environment for business customers, distributors or other partners. Access is not the same for everyone. The portal recognises the user, links them to the right company and shows them the data that apply to them.
- agreed prices, discounts and payment terms,
- available stock or the expected delivery time,
- ordering products or services,
- order history and quick reordering,
- quotes, delivery notes, invoices and technical documents,
- processing and delivery statuses,
- different rights for buyers and approvers.
The portal is not a new ERP and must not quietly duplicate its rules. The ERP should keep managing items, customers, stock, business terms and documents. The portal securely displays this data to the right user and sends accepted orders back into the back end system. More on this type of solution is on the page business portals and records.
When does a B2B portal make sense?
A portal starts creating value with a larger number of business customers with recurring orders and sufficiently predictable ordering rules. A good candidate is a company where:
- orders come in by email, phone or Excel files,
- sales frequently checks prices, stock and past purchases,
- different customers have different price lists or payment terms,
- the same orders recur regularly,
- someone has to manually retype data into the ERP,
- customers frequently ask about status, invoices or delivery notes,
- wrong codes, quantities or prices cause corrections and complaints.
A portal is not automatically the right solution for every company. If you have a handful of customers and every order involves individual negotiation and technical advice, a smaller internal application or just automated transfer of the order into the existing system may make more sense.
How a B2B order needs to flow
The core of a good portal is not the product catalogue, but a reliable flow: the order, checking prices and stock, writing to the ERP, confirmation, documents and status. Each step needs a defined data source and clear error handling.
1. Login and customer recognition
The user logs in with their own account. The portal links them to the business partner in the ERP, for example via a customer code. On this basis it determines the price list, delivery locations, payment terms, the right to place or confirm orders, and access to documents.
One business partner can have several users. A buyer prepares the order, a manager confirms it, and accounting only accesses invoices. Rights need to be verified on the server; hiding a button in the interface is not a security mechanism.
2. Individual prices
Prices must not be calculated by different rules in the portal than in the ERP. The final amount can include the base price list, a customer group discount, a customer's contractual discount, a quantity scale, the validity of an offer and a special promotion.
If prices change rarely, they can be synced periodically. If they depend on the current order or complex conditions, it is safer to check them when adding an item and again before submission. The customer must always see the final price before confirming, or a clear note that sales still needs to confirm it.
3. Stock and delivery time
The company needs to decide what "in stock" means to the customer:
- physical quantity,
- quantity available after reservations,
- stock in a selected warehouse,
- an approximate delivery time,
- or just an "available" versus "made to order" status.
For less frequent stock changes, refreshing every few minutes may be enough. For low stock and fast sales, real time checking is needed. If the ERP is unreachable, the portal must not present stale data as reliable. It can show the time of the last refresh, or accept the order for manual checking.
4. Writing the order into the ERP
On confirmation, the portal again checks mandatory fields, prices, quantities and business rules. It then writes the order into the ERP via an API or another agreed connection. Every order gets a unique identifier that prevents a duplicate record if retried.
A successful write returns the document number from the ERP. If the connection fails, the order stays in a queue and the responsible person receives an alert. The user should not see a final confirmation until it is clear the record was accepted.
5. Confirmation, status and documents
When the ERP later prepares a delivery note or an invoice, the document is linked to the same order. The portal thus shows an understandable progression: submitted, accepted, in preparation, dispatched, delivery note issued, invoice issued and completed. The customer gets an answer without calling the salesperson, while staff still handle exceptions in the system they know.
Individual price lists without three different truths
A problem arises when sales manages discounts in the ERP, additional agreements in Excel, and the portal keeps its own copy of the prices. Sooner or later the systems diverge. Before rollout, answer:
- Where does the base price arise, and where does the contractual discount arise?
- Does the discount apply to the customer, the group, the item or the quantity?
- Which rule takes priority if they overlap?
- Who approves a change and from what date does it apply?
- What happens to a basket that has already been prepared?
For speed, the portal can use a temporary copy of the data, but it must be clear where it came from and when it refreshes. Business rules must not be duplicated without control.
Rights, documents and reorders
A larger customer may need separate users for branches, cost centres and roles. One person just prepares a basket, another approves above a certain amount, accounting sees invoices, and a local user sees orders for their own location. Significant changes leave a trace: who prepared the order, who approved it and when.
For recurring purchases, speed matters more than an attractive catalogue. The user needs the option to reorder a past order, save favourite items or import several line items at once. The system always rechecks current prices and stock before submission.
Does the portal need a mobile app?
For most cases the best first step is a responsive web application. It works in a browser on a computer, phone and tablet, so customers do not need to install anything.
A separate mobile app makes sense when the user often works in the field and needs a camera, barcode scanning, notifications or offline work. More important than the label "mobile app" is that search, quantities, confirmation and reordering are actually usable on a phone.
How to connect the portal to the ERP
- Direct API: data are checked and written in real time.
- Existing connector: useful if the provider already supports both the portal and the ERP.
- Integration application: suited to multiple systems, complex rules or flow control.
- File based exchange: an XML, CSV or other agreed file is exchanged on a schedule.
- Manual import: useful as a transitional stage, not as a final automated process.
Even a system without a modern API can often be connected. What matters most is the required refresh speed and the quality of the available exports. Official options can be checked, for example, in the documentation for the Minimax API or PANTHEON web services. What is actually feasible always depends on the version, licence and access rights.
A good integration provides, alongside the transfer itself, validation, execution history, alerts, retries and protection against duplication. This is described in more detail on the page integrations and data flows.
Rollout without stopping the business
The portal does not need to launch for all customers on the same day. First map the process from receiving an order through to the invoice, and define the primary sources for prices, stock, customers and documents. The first version should cover one clear flow and a limited group of regular customers.
- Login, catalogue and individual prices.
- Basket and order submission.
- Writing to the ERP and reliable confirmation.
- Statuses and business documents.
- Reorders and more advanced rights.
The pilot should be used by customers who order frequently and are willing to give concrete feedback. The email channel can stay open temporarily for exceptions. Once the data and rules are verified, the portal is rolled out further. This kind of phased rollout is part of a considered planning and development process.
How to measure whether the portal is working
Record the starting state before launch, then track:
- the share of orders placed via the portal,
- the average time to process an order manually,
- the number of price, code and quantity corrections,
- the number of questions about status or documents,
- the time from submission to writing into the ERP,
- the share of orders requiring manual intervention,
- use of reorders by individual partners.
A basic calculation of the effect is the number of orders multiplied by the minutes saved and the real value of an hour of work. You can add the cost of errors, credit notes and repeat communication, and subtract development, licences, hosting, support and internal rollout time.
What determines the price of a B2B portal?
Price depends more on the complexity of the business rules than on the number of screens. The biggest factors are the way it connects to the ERP, the complexity of price lists, user roles and approvals, data quality, documents and statuses, multiple warehouses or languages, and security and support requirements.
A short inventory of the process and systems is needed before an estimate. An outline of the approach is described on the page development price list, with wider context in the article on the price of a custom application.
The goal is not just another online shop
A B2B portal makes sense when you have recurring business customers, definable price and stock rules, and enough manual work that the effect is measurable. First tidy up the data and define the primary source. Then connect the smallest usable flow and test it with a limited group of customers.
The end goal is simple: the customer orders correctly, staff do not retype data, and the ERP stays a tidy source of business truth.
Frequently asked questions
What is a B2B ordering portal?
A B2B portal is a private web application for business customers. Once logged in, it shows them their price lists, stock, orders, statuses and documents, and typically reads data from the ERP and returns new orders to it.
Can a B2B portal be connected to an existing ERP?
A connection is often possible via an API, web services, a connector or structured files. First check the specific version, licence and whether the interface allows access to price lists, stock, customers and documents.
What most affects the price of a B2B portal?
The biggest factors are the complexity of ERP integration, rules for individual prices and discounts, user roles, approvals, the quality of existing data, and the number of documents, warehouses, companies and languages. The price is therefore set after a short review of the process.
Will business customers be able to use the portal without training?
If the first version follows their usual way of ordering, uses clear naming and is tested on a phone, onboarding should be quick. It is safest to start with a pilot group of regular customers and refine the interface based on real use.