A B2B ecommerce portal is a logged-in ordering system, not a website with a login screen attached. Its job is to let a company account see contracted pricing, order history, saved lists, and credit terms using data that lives in the ERP, not in the storefront. When any of its nine capabilities returns the wrong number, the account picks up the phone, and the portal has failed at its only job.
For an ecommerce director weighing where to spend the next development budget, that distinction matters more than any feature list a vendor will hand you. Every B2B ecommerce portal capability is really a question about where a piece of data comes from, who owns it, and what breaks if that ownership isn’t respected. Vendor pages will tell you what the portal does. They won’t tell you what it depends on or what it costs to build, and that’s the information that actually determines how you sequence a project.
This guide breaks down the nine capabilities your accounts expect, what each one depends on, and a realistic effort band in developer days for building it on Adobe Commerce, Shopify Plus, and BigCommerce. We’ve built these systems for manufacturers and distributors across North America, and the capability that always gets underestimated is the one most vendor demos skip entirely: what happens when the ERP and the storefront disagree.
A storefront with a login screen shows the same catalog and the same price to everyone, then remembers a name and an address once someone signs in. A B2B ecommerce portal does something structurally different: it reads pricing, inventory, credit terms, and order history from a system of record, typically the ERP, and presents a version of the catalog that is specific to that one company account.
That distinction is the whole argument of this piece. A storefront personalizes the experience. A portal personalizes the data. If your team describes the project as “adding B2B features to the site,” the scope conversation is starting in the wrong place, because the hard part isn’t the frontend. It’s the data pipeline behind it.
Every B2B ecommerce portal we’ve built ends up answering the same nine expectations from buyers, regardless of industry or platform. Each one follows the same four-part shape: what the buyer does, which system holds the authoritative data, what has to be true before the capability works, and a build effort band in developer days.
Contract pricing is the foundation the other eight capabilities sit on, because almost everything else, from reorder to invoicing, assumes the buyer is already seeing the right price. Get this wrong and every downstream capability inherits the error.
On Adobe Commerce B2B, this lives in company accounts and shared catalogs: a company account is assigned a shared catalog with its own pricing, and that structure is native to the platform. Shopify Plus handles it through company profiles and B2B catalogs, which support custom pricing per company but still need a sync layer to stay current with the ERP. BigCommerce uses customer groups tied to price lists, with the same ERP dependency.
Here’s the failure mode we see most often, and it’s worth naming concretely: a price change lands in Epicor Prophet 21, nobody triggers the sync to the storefront, and the portal keeps quoting the old rate for another billing cycle. The buyer orders at the price they see, the invoice reflects the new rate, and your inside sales team spends the next call explaining a discrepancy instead of taking an order. This is why we treat ERP integration as its own project phase, not a line item inside the portal build. Our breakdown of ERP integration architecture patterns and sync frequency covers the sync architecture in more depth, and our breakdown of the Epicor Prophet 21 integration specifically walks through what that pricing sync requires on the ERP side.
If contract pricing is the foundation, reorder, order history, and saved lists are what determine whether an account keeps coming back to the logged-in experience instead of calling your inside sales team out of habit. These three capabilities are related but distinct, and teams often build one and assume the other two follow automatically. They don’t.
Order history is the data. Reorder is the action taken on that data. Saved lists are a third structure entirely, built for buyers who order the same 20 SKUs every month and don’t want to search for them each time. All three depend on a search experience that can handle a SKU-heavy catalog without forcing the buyer to scroll through irrelevant results, which is where a platform’s search infrastructure, such as OpenSearch on Adobe Commerce, starts to matter more than most teams expect. We cover that dependency in more detail in our post on how B2B ecommerce search handles large SKU catalogs.
Adobe Commerce B2B supports all three natively through requisition lists and quick order. BigCommerce B2B Edition also covers all three natively through shopping lists, a quick order pad, and buy again. Shopify supports quick order lists and reorders from customer accounts natively, but saved lists still require an app or a custom build, since it has no native equivalent to requisition lists.
These three capabilities rarely show up in a sales demo because they’re built for friction, not speed. A B2B ordering portal that skips them still looks complete in a walkthrough. It just doesn’t survive contact with an actual purchasing department.
Quote to order exists because B2B pricing is negotiated, not fixed. A buyer requests a rate on a large quantity, someone on the sales side approves or counters it, and the accepted quote becomes an order. Approval chains exist because the person placing the order and the person authorized to spend the money are often different people, and a B2B ordering portal that can’t route an order for sign-off will get bypassed the first time a purchasing manager notices. PO number capture is the simplest of the three, but it’s non-negotiable for any account that runs its own internal procurement tracking: the field has to exist at checkout, and the ERP has to accept what’s typed into it.
Adobe Commerce B2B supports negotiable quotes and purchase order approvals natively, which is one of the clearer differentiators in its favour for accounts running formal procurement processes. BigCommerce B2B Edition includes native quoting, and Shopify can approximate it by submitting orders as drafts for review. Both support PO numbers at checkout, but manager approval chains with spending limits generally require an app or custom development on both.
Credit and invoicing are the capabilities most likely to get pushed to a later phase, and they’re also the ones finance teams care about most. A B2B customer portal that shows accurate pricing but hides the account’s credit position is only solving half the problem for a buyer who’s used to calling accounts receivable to check their balance.
None of the three platforms we build on surfaces ERP credit data natively. That data (credit limits, outstanding balances, available credit) lives in the ERP by design, and a B2B customer portal has to request it through integration rather than storing a copy locally. Adobe Commerce B2B’s Payment on Account feature manages the terms side of this well, letting a company account purchase against a credit line, but the live invoice list still requires a sync from systems like NetSuite OneWorld, SAP Business One, or Sage Intacct. Get the sync frequency wrong, and the B2B customer portal shows a balance that’s already out of date by the time the buyer checks it.
Cost is where most conversations about a B2B self service portal go vague, because “it depends” isn’t a number an ecommerce director can put in a budget request. Here’s how the nine capabilities actually break down across the three platforms we build on:
| Capability | Adobe Commerce | Shopify Plus | BigCommerce | Caveat |
| Contract pricing & catalogs | Native | Native | Native | All three still need ERP sync built separately |
| Order history | Native | Native | Native | Online orders only; ERP-sourced history needs custom sync on all three |
| Reorder | Native | Native | Native | Shopify via customer accounts; BigCommerce via B2B Edition (buy again) |
| Saved lists | Native (requisition lists) | Custom | Native | No native equivalent on Shopify Plus |
| Quote to order | Native (negotiable quotes) | Custom | Native (B2B Edition) | BigCommerce quoting requires the B2B Edition app specifically |
| Approval chains | Native (purchase orders) | Custom | Custom | Adobe is the only native option among the three |
| PO number capture | Native | Native | Native | Native on all three; making the field required on Shopify needs customization |
| Credit & balance visibility | Custom | Custom | Custom | An ERP integration build regardless of platform |
| Invoice access & payment on account | Native (Payment on Account) + custom ERP sync | Custom | Custom | Even Adobe’s native feature needs ERP-side invoice sync |
A B2B self service portal’s real cost lives in the “custom” cells, not the license or the theme. Frontend choices matter too: teams building on Adobe Commerce often pair it with Hyvä to keep frontend performance manageable at scale, and the ERP sync layer itself is frequently built on an iPaaS platform like Alumio rather than a fully custom connector, which shortens the timeline for the capabilities in that credit and invoice row. For a fuller side-by-side of what each platform brings to a B2B build, see our B2B ecommerce platform comparison.
Not every capability belongs in a launch scope, and the honest answer for three of them is: do not build these yet.
Launch with contract pricing, order history, reorder, saved lists, and PO number capture. Everything else earns its place in phase two based on what phase one’s usage data actually shows.
A launched B2B ecommerce portal that nobody uses is worse than no portal at all, because it’s a sunk cost that still requires maintenance. Three metrics tell you whether the portal is actually displacing phone and email orders, not just sitting alongside them.
If you want the underlying cost model behind these targets, including how per-order handling cost factors into the ROI case, our post on the B2B self service portal walks through that calculation in more detail.
If your accounts are still emailing purchase orders to an inbox someone checks manually, the honest first move isn’t a full B2B portal build. It’s a capability audit against the nine items in this guide: which ones do your accounts already expect from other suppliers, which ones does your ERP actually support today, and which one is generating the most phone calls right now.
That audit usually surfaces the same pattern: contract pricing and order history are the two capabilities accounts notice fastest when they’re missing, and they’re also the two with the shortest path to build. A B2B portal earns its budget by removing the calls your team is fielding today, not by matching a competitor’s feature list. We run this kind of audit with manufacturers and distributors before we scope anything, because it tells us which of the nine capabilities to sequence first, and it usually changes the plan.
A launch scope covering contract pricing, order history, reorder, saved lists, and PO number capture typically runs 40 to 90 developer days combined, depending on ERP complexity and platform. Adobe Commerce tends to reduce cost on the native capabilities; Shopify Plus and BigCommerce shift more of that budget into custom development.
Most launch-scope builds run 12 to 20 weeks from discovery to go-live, driven primarily by how clean the ERP’s pricing and product data are before the project starts.
Duplicating pricing data into the storefront instead of syncing it live from the ERP. Static or infrequently synced pricing is the single most common source of the invoice-versus-quote mismatches that erode buyer trust.
Whoever owns the relationship between the ERP and the storefront, whether that’s the ecommerce director or an operations lead, since every sequencing decision comes back to what the ERP can reliably sync on day one.
