---
title: "B2B Portal Development: A Practical Roadmap"
source: https://refact.co/insights/digital-product/b2b-portal-development
author: "Masoud Golchin"
date: "2026-10-07"
---

# B2B Portal Development: A Practical Roadmap

Ask the developers who build B2B portals where the hard work is, and few of them say the screens. One custom-software developer on r/manufacturing called the front end “fairly conventional.” The same developer said they knew of no plug-and-play way to connect a portal to each customer’s ERP. That gap is where most **B2B portal development** budgets go, and where most timelines slip.

This roadmap is for manufacturers, distributors, wholesalers, and the teams scoping portals for them. It covers what a portal has to do, where integration and security go wrong, how to pick a first release customers will use, and why launch day is the start of adoption work, not the end of the project. The timing matters because buyers now expect to order online. They also notice fast when the portal and the sales rep give them different answers.

## A B2B Portal Is an Integration Product With a Web Front End

A password-protected catalog is not a B2B portal. It is a website that hides products from the public. A real portal is an account-aware channel. It shows each customer their negotiated prices, their approved products, their open orders and invoices, and their credit terms. Every one of those facts lives in a system the portal does not own.

Digital B2B commerce already carries real revenue. In 2024, e-sales made up 19.49% of total turnover across EU enterprises, according to [Eurostat’s enterprise e-sales data](https://ec.europa.eu/eurostat/statistics-explained/SEPDF/cache/14386.pdf). EDI-type messages contributed 11.07% and website and app orders 8.39%. Web sales to businesses and public authorities were 4.34% of turnover, slightly more than web sales to consumers. EDI still moves more value than web orders. So a portal has to sit next to the machine-to-machine ordering many customers already use, not replace it.

The model itself is old. EDI began in the 1960s and was standardized in the 1970s. By the 1980s and 1990s it was an important supply chain layer, even though cost and compatibility problems limited who could use it. This [history of EDI and value-added networks](https://blog.axway.com/learning-center/edi-b2b-integration/history-value-added-networks) shows how long the same compatibility problems have followed B2B integration. Modern portals add search, dashboards, and self-service on top. The underlying job has not changed: exchange reliable data between companies with different systems and rules.

That is also why B2B is not B2C with a login. Shopify models B2B buyers as companies with locations and contacts. A buyer with access to several locations picks which one they are ordering for. Adobe Commerce makes the company account the foundation for users and purchasing permissions. On Reddit, practitioners list what their B2B customers expect: sub-users with different permissions, customer-specific prices, credit limits, bank transfer, scheduled payment, RFQs, and invoicing on fulfillment. A consumer checkout handles none of that.

The word “portal” covers several shapes. A customer ordering portal, a post-purchase service portal, a supplier portal, and a partner portal share most of their plumbing but serve different jobs. If your users are resellers or referral partners, this [practical partner portal advice](https://refport.co/blogs/partner-portal-software) covers that variant. For the supplier side, see [how vendor portal software works](https://refact.co/insights/digital-product/vendor-portal-software). For customer-facing portals specifically, our guide to [B2B customer portal planning](https://refact.co/insights/digital-product/b2b-customer-portal) goes deeper on feature priorities.

## Start With the Smallest Release Customers Will Actually Use

The most common scoping mistake is trying to build the full feature set at once. One account on X described an eight-month portal build that almost nobody used. The team had built dashboards, reports, and settings. The one task customers wanted took six clicks.

Start from the questions your customers already ask your staff every day. In a 2024 Sapio Research survey for DynamicWeb, the self-service features companies rated most important were order and reorder (44%), customer support (42%), and product or parts lookup (38%). SAP’s B2B Self-Service Portal, released in 2025, starts with post-purchase visibility: orders, invoices, and deliveries. It does not try to replace the whole sales process on day one.

A sensible first release for a distributor might include:

-   **Order status and shipment tracking**, so buyers stop emailing customer service to ask where their order is.
-   **Reorder from history**, with SKU search and quantity edits for large baskets.
-   **Invoice and document retrieval**, including statements, packing slips, and spec sheets.
-   **Account-specific pricing**, resolved before checkout and never shown as a generic list price.
-   **Basic user roles**, so a company admin can add buyers without calling you.

Quote configuration, advanced analytics, and AI recommendations can wait until the core data is trusted. A narrow scope only works if the data behind it is accurate, though. A portal that shows the wrong order status loses buyers faster than one that shows no status at all.

Collect what customers and internal teams ask for, but do not let every request become a build commitment. [A public feature request board](https://convot.io/portal/) lets customers vote on requests while you decide what ships and when.

## Integration Is Where B2B Portal Development Gets Hard

When practitioners were asked about integration challenges in the [2025 State of B2B eCommerce report](https://www.masterb2b.com/research/2025-state-of-b2b-ecommerce/), 67% cited system compatibility and 63% cited data consistency across tools. Implementation cost (46%) and limited internal expertise (43%) came next. The report does not publish its sample size, so treat the exact numbers as directional. The pattern matches what builders describe, though. One ERP-commerce vendor on r/webdev said its average go-live took six months with a dedicated team of four or five people. Some clients were still not functional after two years.

Other practitioners say their integration “wasn’t too difficult.” Both accounts can be true. Difficulty depends on how clean your ERP’s API is, how messy your data is, and how many business rules the portal must enforce. You will not know which group you fall into until someone maps the integration in detail.

Get that map before anyone quotes the build. Ask for an integration matrix that lists every system, every object, the direction of sync, and the edge cases. Check that the connector you plan to use supports your platform’s B2B edition, not just its retail version. In one BigCommerce discussion, a commenter flagged a possible backorder gap in the Epicor Prophet 21 connector. That is the kind of gap that turns into weeks of custom work after the contract is signed. If your ERP is itself in question, our guide to [custom ERP development](https://refact.co/insights/digital-product/custom-erp-development) covers that decision.

### Decide which system owns each field

Your ERP may hold contract pricing. Your commerce platform may hold catalog content. The CRM holds the account relationship, the warehouse system reports stock, and customer service may have placed a manual hold that none of them know about. If nobody defines which system wins for each field, buyers see information that looks reliable and isn’t.

Write a data contract before development. For each important field, name the system of record, the sync direction, how stale the data may get before it is unusable, and who owns fixing it.

| Data area | Decide before development | Typical freshness need |
| --- | --- | --- |
| Price | Which system controls contract rates, discounts, and promotions | Revalidate at checkout |
| Inventory | Whether the portal shows live stock, reserved stock, or an availability band | Minutes, revalidate at order submission |
| Product content | Whether the ERP or a PIM owns descriptions, attributes, and documents | Daily batch is often fine |
| Customer and location | How companies, subsidiaries, ship-to addresses, and billing accounts relate | On change |
| Credit and terms | Which system holds credit limits, holds, and payment terms | Revalidate at checkout |
| Orders and status | Which system creates the official order record and which events update it | Event-driven, with reconciliation |

“The ERP is the source of truth” often falls short, because the portal needs content the ERP never stored. In a 2020 project for LAPP Russia, the group’s shared product-information repository was closed to the team. They used a local Akeneo PIM and a partial data export to connect SAP to the portal. In the DynamicWeb survey, 61% of companies already used a PIM. Budget for data cleanup either way. Most teams find their product data is messier than they thought once a customer can see it.

This matters commercially. In a 2025 Sana Commerce survey of 750 buyers, 85% reported frustrations with online ordering. The problems they named were missing or unreliable product, stock, delivery-time, and pricing information. Three quarters said they would switch suppliers for a better experience. That is stated intent from a vendor survey, not observed behavior. It still shows where buyers lose trust.

### Design around API limits, not unlimited live data

Many teams assume an API connection gives them unlimited real-time reads. It doesn’t. Microsoft Business Central returns HTTP 429 when it throttles requests, enforces a 10-minute execution limit, and can return 504 timeouts. Microsoft recommends backoff, filtering, pagination, sized batches, and webhooks over frequent polling. BigCommerce B2B Edition allows 150 requests per minute store-wide, plus endpoint-specific and concurrency limits. It also offers no custom webhooks for some B2B events.

ERPs also go down. One BigCommerce commenter described a client whose ERP API was available about 80% of the time, which left customers unable to buy when it was offline. That is one anecdote, but it shows the design question clearly. What does the portal do when the ERP is unreachable?

Not everything needs real-time sync. Price, stock, and credit need to be fresh at the moment of commitment. Product descriptions and order history can sync in batches. When live data is stale, say so. Show a freshness time on availability, or route the buyer to a quote request instead of displaying a plausible but unconfirmed price. Handling the failure openly keeps more trust than showing a wrong number with confidence.

### Make every order safe to retry

Here is the failure that creates duplicate orders. A buyer clicks submit, the ERP accepts the order, and the response times out on the way back. The portal shows an error, the buyer clicks again, and your warehouse ships two pallets.

Webhooks have the same problem in reverse. Shopify’s documentation says deliveries may be duplicated, and failed deliveries are retried eight times over four hours. An Admin API subscription can be deleted after eight consecutive failures, and Shopify expects a response within five seconds. Its guidance is to verify signatures, process events idempotently, queue the work, and reconcile against the API.

In practice, that means:

-   Persist a transaction ID with every order submission so a retry returns the original result instead of creating a second order.
-   Deduplicate incoming events and process them from a durable queue, not inside the webhook request.
-   Monitor webhook subscriptions so a silently deleted one gets caught within hours.
-   Run scheduled reconciliation against the source system to catch missed events.
-   Show explicit order states such as pending, accepted, rejected, and needs attention, instead of a success message the system cannot back up.
-   Give support staff a lookup that confirms whether an ambiguous submission actually reached the ERP.

## Platform “B2B Support” Comes With Fine Print

Every major commerce platform says it supports B2B. That does not mean it supports your B2B model. Check the details against your real account structure before you commit:

-   **Shopify:** direct company catalogs and deposits or partial payments require Shopify Plus. Lower plans cap B2B markets at three catalogs.
-   **BigCommerce B2B Edition:** company hierarchies go up to five layers, with a maximum of 500 companies. The older V2 API is deprecated and lacks many newer features, and an authentication migration took effect on September 30, 2025.
-   **Adobe Commerce:** the backend supports company structures, but the storefront CompanyHierarchy container supports only one parent and direct-child level. Nested hierarchies are not supported in that component.

Adobe’s case shows a gap that often surfaces late. What the backend can store and what the storefront can display are separate questions. A distributor with regional parents, branch locations, and job-site accounts needs both answered.

Practitioner opinions on platforms are split. One product owner said their pricing was too complex for Shopify. Another moved from Shopify to Zoey because Plus cost too much for the features they needed. They liked Zoey’s back office but called its page builder “a bit of a nightmare.” A Magento user pointed out that flexibility comes with code ownership and the maintenance that goes with it. Nobody agrees on a ranking, and you don’t need one. You need a platform that fits one real transaction from your business, tested end to end.

We have seen the same pattern outside B2B. When we [rebuilt Fiore Designs’ platform](https://refact.co/work/fiore-designs), the problem was that Shopify’s checkout could not be customized for zone-based delivery checks and fees. The platform’s feature list looked fine. The business rules did not fit. B2B rules like credit holds, approval thresholds, and ship-to restrictions hit that limit much sooner.

![B2B company account settings with locations and contacts in a commerce platform admin](https://cdn.refact.co/uploads/2026/10/image_placeholder_2-20.avif)

Managing parent and child company accounts directly within the platform backend ensures catalog access and buying permissions reflect how corporate clients are actually organized. · Source: amasty.com

If your workflows match a platform’s model closely, buying is faster. If your approvals, hierarchies, or integrations are unusual, you will pay for apps and customization either way, and a custom build may cost less over time. Our guide to [custom web portal development](https://refact.co/insights/digital-product/custom-web-portal-development) walks through that tradeoff. For smaller wholesale operations already on WordPress, [WooCommerce wholesale store setup](https://refact.co/insights/ecommerce/woocommerce-b2b-store-setup) may cover the first release.

## Security in a Multi-Company Portal Happens Per Request

A B2B portal holds many companies’ data in one system. One organization may have buyers, approvers, finance users, regional managers, and admins. Some users belong to several companies with different permissions in each. The most dangerous bug is checking access at login and nowhere else.

OWASP ranks Broken Object Level Authorization as the top API security risk (API1:2023). The failure is simple. An API accepts an order ID, invoice ID, or company ID and returns the record without checking that this user may see it. If a buyer can change an ID in a request and see another company’s invoices, the portal is not tenant-safe, however good the login screen looks.

Treat authentication and authorization as separate jobs. Single sign-on confirms who the user is. It does not decide what that person may view, approve, edit, export, or buy. Model company and location scope as a security boundary enforced on the server for every protected operation. Never rely on a hidden button or a frontend route to protect it. Then write tests for cross-company access, cross-location access, role changes, approver workflows, and field-level exposure.

Enterprise customers will often want to sign in through their own identity provider. [NIST’s digital identity guidance](https://csrc.nist.rip/external/nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63-3.pdf) defines federation assurance levels for those connections. When personal information appears in a federation assertion, it requires FAL2 or higher. Validate signed assertions, restrict accepted issuers and audiences, keep assertion lifetimes short, and block replays. Map only the claims the portal needs, such as company, role, and account identifiers.

Two smaller items get missed often. First, sanitize every CSV or spreadsheet export against formula injection: prefix any cell that starts with `=`, `+`, `-`, or `@` with a single quote, and strip leading whitespace. Second, log authorization decisions, role changes, invitations, exports, and approvals. Each audit record should show who acted, which company they acted for, and what changed. For related patterns, see this piece on [audit logs and access expirations](https://linkship.net/blog/file-access-control).

One Reddit commenter put the AI-code question plainly. AI-generated code is fine for prototypes. It is not a security architecture for a system that exposes customer data. Our [secure client portal guide](https://refact.co/insights/digital-product/secure-portal-for-clients) covers the controls to require from whoever builds yours.

## Performance Problems Show Up in Dense Workflows

A portal can pass a homepage speed test and still feel broken. Business users filter thousands of order lines, switch accounts, edit quantities in large tables, and export invoices. A click that freezes the screen for two seconds hurts task completion even when the page loaded quickly.

[Google’s Core Web Vitals guidance](https://support.google.com/webmasters/answer/9205520?hl=en) sets the good thresholds at LCP of 2.5 seconds or less, INP of 200 milliseconds or less, and CLS of 0.1 or less, measured at the 75th percentile of real users. For portals, INP matters most, because it measures how fast the interface responds to clicks and typing. Measure it by workflow and device, not only by page. A procurement user on an older laptop will feel slow validation code long before anyone in the office notices.

![Core Web Vitals report used to track B2B portal performance and INP](https://cdn.refact.co/uploads/2026/10/image_placeholder_3-17.avif)

Google Search Console categorizes real-world page health into poor, needs improvement, and good URL groupings, highlighting how subtle interaction delays drag down user experience long after initial page load. · Source: www.searchenginejournal.com

The fixes are mostly backend work. In one detailed practitioner thread about a partner portal built on Lovable and Postgres, screens slowed down because the browser was joining tables, re-checking permissions on every row, and downloading whole tables of around 19,000 rows. Resolving permission scope once per query, indexing the match fields, and moving work into database functions cut one count query from 4.63 seconds to 130 milliseconds. That is a single account, but the pattern holds widely. Filtering, sorting, and aggregation belong in the database. Large lists should paginate or virtualize, and JavaScript should be split by role so a finance user does not download the admin console.

Load-test realistic usage before launch, and do not overcorrect. Practitioners describe failures at both extremes. One small business paid about $2,000 for a three-month build that crashed at around ten users. Another team spent heavily on architecture for a 12,000-line portal that still failed at 30 requests per second. Test the traffic you actually expect, on the workflows people actually use.

## Self-Service Works Best With a Clear Path to a Person

Gartner’s 2025 survey of 632 buyers found that 61% prefer an overall rep-free buying experience. The same survey found buyers still want seller input on context-dependent questions, such as whether an offering fits their company. And 69% had seen inconsistencies between a supplier’s website and what its sellers told them, according to [Gartner’s B2B buyer survey](https://www.gartner.com/en/newsroom/press-releases/2025-06-25-gartner-sales-survey-finds-61-percent-of-b2b-buyers-prefer-a-rep-free-buying-experience).

McKinsey’s 2024 B2B Pulse, drawn from nearly 4,000 decision makers, found buyers use an average of ten channels. Preferences split roughly into thirds across in-person, remote human, and digital self-service at each stage of buying. More than half said they might switch suppliers after a poor cross-channel experience. A rep-free preference for reorders does not mean buyers want no human help with a new product line.

Design the portal as a graduated service model:

-   **Full self-service** for routine reorders, order tracking, documents, and standard questions.
-   **Assisted buying** for quote requests, configuration help, and approval questions.
-   **Named representation** for strategic accounts, with a rep who can see the buyer’s portal activity.

The handoff has to carry context: the company, account pricing, products viewed, cart contents, past orders, and approval status. The bigger fix is a single source of commercial truth that both the portal and the sales team read from. In the Master B2B report, 43% of companies said they lost sales because their website and salespeople were disconnected. A portal that disagrees with your reps creates a new version of the problem it was built to solve. The same thinking applies to the public storefront, which we cover in [B2B ecommerce website design](https://refact.co/insights/ecommerce/b2b-ecommerce-website-design).

## Plan Adoption as Its Own Workstream

Launching a portal does not mean customers will use it. Practitioners on X and Reddit describe portals nobody logged into, and customers who went back to phoning in orders. A 2026 study in _Electronic Markets_ interviewed 30 people across five early-stage B2B platform initiatives inside one industrial group. All five struggled to attract enough participants, and some were cancelled. The causes were not technical. The researchers found nine challenges, including control, existing buyer-supplier relationships, competing local and group goals, and influential “keystone” actors who could block adoption.

That study covers multi-party platforms, not single-supplier portals, so the lesson transfers only in part. It still matches what portal teams see. A sales rep who thinks the portal threatens their accounts can quietly steer customers back to email. A customer’s procurement lead who never asked for the portal can ignore it. A study by Marzi and colleagues in 2023 adds that smaller firms adopt for flexible networks and supplier relationships, while large firms care about efficiency and transaction security. The pitch to each should differ.

The success stories in the research share a sequence. They come from vendor-published case studies, so read the numbers as directional:

-   **Lactalis** piloted in 3 markets with test groups of 100 customers, then expanded to 12 markets and 15,000 customers over two years (OroCommerce).
-   **Workwear Group** did extensive customer research, rolled out to selected customers, and cleaned up more than 30 years of service processes. It reported over 70% fewer customer-service enquiries (SAP).
-   **Movora** merged seven platforms into one catalog connected to regional ERPs, with sales and service teams helping onboard customers (BigCommerce).
-   **RelaDyne** used ERP order history to drive reorder and substitution suggestions that its own reps also used. Regular portal users rose 67% (Proton).

The common thread is research first, a bounded pilot, internal teams involved in onboarding, and measurement after launch. Track task completion, repeat ordering, failed transactions, and support volume by channel. If phone orders from pilot customers are not falling, find out why before you invite the next group.

## What B2B Portal Development Costs and How Long It Takes

No reliable benchmark exists for either. Agency guides put custom portals at roughly $75,000 to $250,000 or more. Those figures come from firms selling the work. On the other end, a manufacturer and agency owner on Reddit judged a $15,000 to $20,000 proposal for a distributor’s requirements too low and advised cutting scope. The six-month average from the ERP-commerce vendor above is one company’s experience, not a standard.

What moves the number is mostly invisible in a screen-based quote:

-   ERP integration, connector fit, and the custom work for edge cases
-   Data cleanup and migration, including product content the ERP does not hold
-   Failure handling, monitoring, and reconciliation
-   Security testing for multi-company access
-   Running old and new ordering systems in parallel during cutover
-   Post-launch support, API version updates, and data quality ownership

Ask for itemized quotes that price discovery, integration, parallel operations, failure handling, and support separately, then compare what each vendor actually includes. A proposal that talks only about frameworks and page counts has skipped the hard part. Our guide to [choosing a portal development company](https://refact.co/insights/digital-product/portal-development-company) lists the questions that expose that gap.

## A Build and Launch Plan That Retires Risk Early

Lamb Weston’s 2024 ERP transition is a useful warning, even though it was not a portal project. Impaired inventory visibility and order processing cut net sales by about $135 million in one quarter. A portal depends on those same order, stock, and fulfillment processes. Order the work so the riskiest assumptions get tested first.

### 1\. Discovery

Interview buyers, approvers, sales, customer service, operations, and finance. Map one order end to end: the buyer, company, location, price, approval, submission, ERP response, and the exception path. Mark every manual handoff and every place two systems disagree. Write the first release in business terms, and name what you are deliberately leaving out.

### 2\. Account model and design

Define companies, locations, roles, and approval rules before polishing screens. Decide how users switch between companies, what an approver sees, and what the screen shows when a price or stock call fails. Then test the hardest workflow with a real buyer. Ask them to find a product, change quantities, submit for approval, and come back later to check status.

### 3\. A vertical integration slice

Build one thin path that proves the portal can authenticate a user, load the right company’s terms, create an order in the ERP, and return its status. Validate platform limits against your real hierarchy at this stage, while switching is still cheap.

### 4\. Failure-mode testing

Go beyond the happy path. Test throttling, timeouts, duplicate and missed webhooks, ERP downtime, retries after ambiguous submissions, cross-company access, role changes, and large tables with production-sized data. Have operations staff run the recovery paths for a stuck order, a withdrawn approval, or an upstream outage.

### 5\. Pilot, then expand in waves

Launch to a bounded group of customers with sales and service involved in onboarding. Keep a fallback for urgent orders. Review adoption and data-accuracy signals with sales and operations, then widen access in stages.

### 6\. Fund the operating model

Before launch, assign owners for integration monitoring, data quality, reconciliation, API version changes, and customer support. Portals decay when nobody owns those jobs. Prices drift and webhooks die quietly, and customers go back to the phone.

A B2B portal pays off when it is a trustworthy extension of how you already sell. That means accurate prices and stock, permissions that hold under every request, and a reason for customers and reps to use it instead of email. Most of that work is decided before design starts, in the integration map, the data contract, and the choice of first release. If you are trying to scope that work before committing to a platform or a build, our [portal and dashboard development](https://refact.co/services/portals) team starts with discovery for exactly that reason, and our [product design work](https://refact.co/services/product-design) turns those decisions into a first release customers will use.

## FAQ

### What is the difference between a B2B portal and a B2B ecommerce website?

A B2B ecommerce site may sell to business buyers through a fairly standard storefront. A portal is account-aware: it shows each company its own catalog, negotiated pricing, credit terms, order history, invoices, and multi-user roles, usually pulled from an ERP. Some portals are transactional, and others focus only on post-purchase service such as order tracking and invoice retrieval.

### How much does B2B portal development cost?

There is no reliable benchmark without scope. Agency guides put custom portals at roughly $75,000 to $250,000 or more, while practitioners have called $15,000 to $20,000 too low for a typical distributor's requirements. The biggest cost drivers are ERP integration, data cleanup, failure handling, security testing, parallel running during cutover, and post-launch support, so ask for quotes that price those separately.

### How long does it take to build a B2B portal?

It depends mostly on integration complexity and data quality. One ERP-commerce vendor reported an average of six months to go live with a dedicated team of four or five, while some clients took far longer. A narrow first release covering order status, reorder, and invoices can launch sooner, and a phased rollout like Lactalis's 3-to-12-market expansion can run over two years.

### Does a B2B portal need real-time ERP sync?

Not for everything. Price, stock, and credit should be revalidated at the moment of checkout or order submission, while product content and order history can often sync in batches. ERPs throttle requests and time out, so syncing everything in real time adds load and creates new failure points without making the data more accurate.

### Should we build a custom B2B portal or use a platform like Shopify Plus or BigCommerce B2B?

Use a platform if your account structure, pricing, and approvals fit its model closely. Check plan gates, hierarchy depth in both the backend and the storefront, catalog limits, and API coverage against one real transaction from your business. If your workflows are unusual, the cost of apps and customization can make a custom build the better long-term choice.

### Will a B2B portal replace our sales reps?

The evidence says no. Gartner found 61% of buyers prefer a rep-free experience overall but still want seller input on context-dependent decisions, and McKinsey found preferences split roughly in thirds across in-person, remote, and self-service channels. The best portals take routine reorders and status checks off reps' plates and give them the same data the buyer sees.