techone --guide=b2b-portal
B2B Portal: When Customers Stop Wanting to Send Orders by Email
A practical guide to B2B portals connected to ERP. What to address during design, how to integrate, common pitfalls from real projects.
Last updated:
TL;DR
- What this is about
- B2B portal for self-service business customers: a corporate buyer logs in, sees their assortment, contracted prices, open orders and invoicing. Mid-market scenario where EDI only fits part of the partner base.
- Core layers
- Roles and permissions, parallel order state management, data model (reference / configuration / transactional), REST API integration with ERP, validation layers, audit and monitoring.
- Three paths
- Off-the-shelf B2B platform with ERP connector, custom development via REST API, or portal as a module of an existing ERP. The choice depends on customization needs, time to production, and team capacity.
- Timeline
- Analysis phase 4-8 weeks. Off-the-shelf platform: 2-4 months to production. Custom development: 4-6 months. ERP module: depends on the vendor roadmap.
- Cost
- Depends on the path (platform vs. development), number of users, customization scope, and ERP. We will give you a concrete estimate after the initial call.
Anatomy of a B2B Portal: Six Architectural Layers
A B2B portal is not a single app with a few screens. It is a layered architecture, where each layer can fail independently. Understanding these layers determines whether the portal will work in 6 months, or become yet another system that gets retyped manually.
If you handle automated B2B communication with large partners (OEMs, retailers, EDIFACT messages), see EDI integration for manufacturers. This guide focuses on portals for self-service customers.
1. Roles and permissions
External roles: customer user, their approver for larger orders. Internal roles: account manager (manages contract, pricing, availability), validator (verifies feasibility of the order), administrator (parameters, users). Each role has a different workflow and different view of the data. Poorly designed permissions are the most common reason portals fall out of use after 3 months.
2. Parallel order state management
An order does not have a single linear state. It has multiple axes that do not move in sync. Process flow (received → in validation → confirmed → in dispatch → delivered) runs differently from validation status (pending check → approved → rejected with reason) and from payment cycle (proforma → partial payment → fully paid). An order can be process-confirmed but not yet validator-approved. Validated but unpaid. States need to be modeled as three axes with defined relationships, not as one linear path.
3. Data model: reference, configuration, transactional
Three data types, each with a different authority. <strong>Reference data</strong> (items, price lists, customer contracts, stock) comes from ERP and is mirrored in the portal, never edited. <strong>Configuration data</strong> (user roles, approval rules, portal parameters) is maintained in the portal, not in ERP. <strong>Transactional data</strong> (orders, audit log, history) originates in the portal and flows to ERP after validation. Mixing these three types is the root cause of most portal projects that get rewritten within a year.
4. ERP integration via REST API
The portal communicates with ERP through defined endpoints: GET for reference data (catalog, price, stock, contract), POST for transactions (creating orders, state changes). The key element is <strong>error handling</strong>: when ERP does not respond, the portal must not freeze or lose data. Retry policy with exponential backoff, dead-letter queue for messages that repeatedly fail, audit log for every operation. For Microsoft Dynamics 365, we have an established integration pattern. See <a href="/en/services/erp-integration">ERP integration</a>.
5. Validation layers
Validation does not run on a single level. There are four layers: <strong>data integrity</strong> (required fields, formats, VAT IDs, IBAN), <strong>business rules</strong> (customer credit limit, availability, minimum quantity, discount rules), <strong>finance</strong> (credit limit, payment history, blocks), <strong>logistics</strong> (pallet quantity, lead time, multi-warehouse picking). Each layer can stop an order for a different reason, and the customer must receive a comprehensible message, not "validation error 4032".
6. Audit and monitoring
A B2B portal is not a transactional intruder that no one watches. The audit log captures who, when, and how an order was changed. Monitoring tracks API call response times, error rates, and queue lag (how many messages are waiting for ERP write). Without monitoring, errors only surface during audits or when the customer asks where their invoice is. For operations, this is as important as the portal itself.
Three Paths to Build a B2B Portal
When a company considers a B2B portal, it typically assumes "we will build it from scratch". In reality, there are three viable paths, each with its own context. The right choice depends on customization scope, time to production, and team capacity.
Off-the-shelf B2B platform + ERP connector
For standard B2B workflow with rapid time to production. Deployment 2-4 months, vendor handles maintenance, good UX out of the box. Trade-off: monthly per-user licensing and limited customization. Examples: Shopware B2B, BigCommerce B2B, Sana Commerce, Adobe Commerce B2B. The choice depends on which ERP you run.
Custom development + REST API integration
For specific workflows, multi-vendor ERP environments, and the need for full UX control. No per-user licenses, full control, customization without compromise. Trade-off: longer time to production (4-6 months) and you own maintenance. Stack typically React/Vue + .NET or Node backend + REST API to ERP. This is the path we usually take. See <a href="/en/services/custom-applications">custom applications</a>.
Portal as a module of an existing ERP
For full data integration with limited UX requirements. No separate integration, single source of truth in ERP, simpler maintenance. Trade-off: UX is usually weaker than a dedicated portal, limited customization, dependent on ERP vendor roadmap. Works for companies where the portal is a secondary channel.
EDI or Portal: Decision Framework
A mid-market manufacturer or distributor typically uses both. EDI for large partners, portal for mid-tier and small customers. The question is not "either / or", but "where to draw the line".
Customer size
EDI: large partner (OEM, retail chain, automotive Tier 1). Portal: mid/small customer who expects UI-driven self-service.
Communication frequency
EDI: high, daily or hourly batches. Portal: irregular, seasonal, ad-hoc orders.
Standardization
EDI: rigid, defined by partner specification (EDIFACT, EANCOM, VDA). Portal: flexible, UI workflow adapts to user.
Human involvement
EDI: none, system-to-system without UI. Portal: full, user clicks, approves, fills in data.
Time to launch
EDI: 4-8 weeks per partner. Portal: 2-6 months for first deployment, then additional customers self-onboard.
Four Mistakes We See in B2B Portal Projects
These patterns recur. Some are visible at the design stage, others only surface after deployment.
1. Portal without real-time price updates from ERP
Customer-specific contract prices live in ERP. If the portal pulls prices manually or via nightly batch, they are not current. The customer sees a different price than the invoice, raises a complaint, customer service spends hours sorting it out. Real-time API calls or event-driven push from ERP is mandatory.
2. Login without SSO and 2FA
A B2B portal is not a B2C e-commerce site. The user is an employee of a company with its own directory (Active Directory, Google Workspace). SSO via SAML or OIDC is standard, not a nice-to-have. 2FA protects access that has direct impact on invoicing.
3. No audit trail
When a customer denies placing an order, the audit log is the only evidence. Who logged in, when, from which IP. Which fields they changed. What response the API returned. Without an audit trail, the portal is legally risky and incidents cannot be resolved.
4. Mobile interface as an afterthought
B2B buyers often place orders from the field or while traveling. If the portal looks like a shrunken desktop on mobile, usage drops sharply. Mobile-first design for the key scenarios (creating an order, tracking a delivery, approving a purchase) is the standard.
Frequently Asked Questions
How much does a B2B portal cost?
It depends on the chosen path (off-the-shelf platform vs custom development), number of users, customization scope, and the ERP. Off-the-shelf platforms have a monthly per-user license, custom development has an upfront cost plus maintenance. We give you a concrete budget after the initial call once the analytical design is in place.
How long does the analytical design of a B2B portal take?
The analysis phase typically runs 4-8 weeks. The deliverable is a document describing roles, permissions, use case scenarios, data model, REST API specification, and validation rules. It serves directly as input for the development team without needing to return to the business side for additional questions.
Will it work with our ERP?
Yes, if your ERP has a REST API or database access. We have an established integration pattern for Microsoft Dynamics 365 Business Central and F&O. We also work with SAP Business One, Oracle NetSuite, Infor, and legacy Microsoft systems (Dynamics NAV). For systems without an API, we use file exchange (XML, CSV) or database triggers.
How do you handle multi-warehouse picking and pallet quantities?
It depends on business rules. Picking strategies (FEFO, FIFO, nearest warehouse) are configured per requirement. Pallet quantities are checked in the logistics validation layer: if the customer orders a non-standard quantity, the portal either offers to round up to full pallets or shows a surcharge. Logic is driven by the business analysis, not by the out-of-the-box default.
What about mobile support? Is responsive web enough?
For key scenarios (placing an order, status, approval), we recommend mobile-first responsive web design. PWA (Progressive Web App) is often a better choice than a native app: it works offline, supports push notifications, and installs from the browser. A native app makes sense only when buyers need barcode scanners or deep offline use.
What does the audit trail look like in practice?
Each order change (creation, approval, rejection, line edit) has a record: timestamp, user, source IP, before/after state, correlation with API call to ERP. Logs are immutable (cannot be edited), retained for at least 5 years per accounting obligations. The audit dashboard allows filtering by user, period, customer.
Continue Reading
ERP Integration (service)
ERP integration with e-commerce, CRM, warehouse. EDI with trading partners, REST API integration.
EDI Integration for Manufacturers
Automated B2B communication with large partners. EDIFACT, ORDERS, DESADV, INVOIC.
Custom Applications (service)
B2B portals, enterprise applications, mobile solutions integrated with ERP.
Working on a B2B portal?
Analytical design, custom development, or integration with an existing portal. Based on our ERP integration work, we will tell you where this typically gets stuck.
Book a consultation