A B2B portal is a working account for companies that regularly buy from a supplier. Unlike an ordinary public store, orders depend on contracts, user roles, customer-specific pricing, payment terms and available warehouses. Its main purpose is to give partners the information and actions they need without requiring a manager to re-enter every request manually.
Start with the rules between companies
One customer company may have several employees. A buyer prepares an order, a manager approves it and an accountant views invoices. The concepts of customer and user should therefore be separate. The portal needs to know which organisation a person belongs to, which actions they may perform and who may change those permissions.
Planning also covers minimum quantities, pack sizes, available warehouses and contractual restrictions. These are not decorative profile fields: they determine whether an order can be accepted. If the rules exist only in a manager’s memory, the interface cannot reliably tell partners what to do next.
Customer-specific pricing needs an authority and validation
Decide where prices are calculated: in the portal, ERP or another system. Agree currency, rounding, discounts and how long an offer remains valid. A buyer may open a cart in the morning and submit it in the evening after terms have changed. Before confirming the order, the system should revalidate prices and clearly explain any changes.
Displaying the right number in a browser is not enough. The server checks the organisation, product access and applicable terms. A user should not be able to obtain another partner’s price list or documents simply by changing a number in a link.
Learning scenario: a repeat order
Consider a distributor whose partner buys the same consumables each week. The buyer opens a previous order and repeats it. Some items are available, while others are expected at the warehouse. The portal should offer an agreed option: split the delivery, reduce the quantity or refer the issue to a manager. Silently removing unavailable items would change what the buyer requested.
After approval, the order receives a shared identifier in the portal and accounting system. If the exchange is interrupted, retrying should continue the same operation. The partner needs a clear awaiting-confirmation state, while the supplier’s team needs a log that explains the delay.
How we define requirements for this solution
In ALL IT Agency’s B2B development service, roles, customer terms and accounting integration are treated as connected parts of the task. Before implementation, a useful matrix records the role, action, data and validation. It separately describes actions that are forbidden or require approval. This matrix becomes the basis for the interface, server checks and acceptance scenarios.
-
Partners see only their own prices, orders and documents.
-
Resubmitting does not create a duplicate order.
-
Price and availability changes are shown before final confirmation.
-
The approval outcome is represented consistently in the portal and accounting system.
What to hand over after launch
The portal needs accompanying procedures for creating partner accounts, assigning roles and revoking access. Assign responsibility for reference data and a contact for exchange failures. A useful portal does not eliminate the need for a manager: it reduces repetitive work and leaves unusual agreements, disputes and exceptions to people.
Sources and further reading
