B2B Customer Portal Development: Architecture, Costs & How We Build Them

Your distributors are calling your customer service team to ask what they paid last time. Your reps are emailing PDF price sheets that are wrong the day after your ERP team updates a contract. Your biggest account wants their purchasing manager to approve orders before they ship, and right now that approval happens over text message. These are the problems a B2B customer portal exists to solve, and they are the problems we have been solving for manufacturers, distributors, and wholesalers since 2007.

This page covers what a B2B customer portal actually includes, the four realistic ways to build one, what each path costs, and the part almost nobody writes about honestly: how customer-specific pricing actually gets from your ERP to a browser. We build portals on Adobe Commerce (Magento) and Shopware, integrated with NetSuite, SAP, Microsoft Dynamics, Acumatica, Sage, and Epicor P21, and everything below comes from 50+ B2B implementations, not from platform marketing pages.

B2B Customer Portal in 60 Seconds

A B2B customer portal is a logged-in commerce environment where your business customers see their own negotiated prices, place and approve orders, request quotes, view invoices and credit status, and reorder without calling a rep. It differs from a B2C store in one fundamental way: almost everything in it is account-specific, and the source of truth for that account data is your ERP, not the ecommerce platform. The four ways to build one are Adobe Commerce with the native B2B module, Shopware 6 with its B2B components, a headless or fully custom build, and SaaS portal tools layered on your ERP. Custom portal builds typically run $75K to $250K+ depending mostly on ERP complexity, and take 4 to 9 months to launch. The single biggest predictor of success is not the platform you pick. It is how well the pricing and account data sync between the ERP and the portal is designed.

What a B2B Customer Portal Actually Includes

“Portal” is a vague word, and vague words produce vague scopes. When a distributor or manufacturer says they need a customer portal, they almost always mean some combination of seven capabilities. Knowing which ones you need, and which ERP objects feed each one, is the real scoping exercise.

Account-specific pricing

Every B2B account sees its own prices: contract pricing, customer price levels, volume tiers, category discounts, and negotiated line-item rates. This data lives in your ERP as price levels and customer item pricing in NetSuite, condition records in SAP, price lists and trade agreements in Dynamics, price worksheets in Acumatica, or price codes in Sage. The portal does not own this data. It displays it. Getting that display accurate and fast is the hardest technical problem on this page, which is why it gets its own section below.

Order history and status

Buyers expect to see every order they have placed, regardless of channel. That means the portal shows orders that came in by phone, email, EDI, and rep entry, not just web orders. This is an ERP-driven view: the order master lives in NetSuite or SAP, and the portal reads from it. Portals that only show web orders get ignored, because for most mid-market B2B companies, web orders start out as 10-30% of volume.

Reorder and quick order

The fastest-growing share of portal revenue is repeat purchasing: one-click reorder from history, saved shopping lists by job or location, CSV upload of SKU and quantity, and SKU-autocomplete quick order pads. A purchasing manager who buys the same 40 SKUs monthly should complete that order in under two minutes. This is where portals earn adoption, because it is measurably faster than emailing a rep.

Quotes and RFQ workflows

Configured products, large quantities, and special-pricing requests flow through a request-for-quote process: buyer submits, sales reviews and prices, buyer accepts, quote converts to an order with its negotiated pricing preserved. Response time is the metric that matters here. In our experience, buyers who get quotes back within 4 hours convert at multiples of those who wait a day or more. We covered the full workflow design, including where Magento’s and Shopware’s native quoting tools hit their limits, in our guide to B2B quoting and RFQ workflows.

Invoices, payments, and statements

Accounts payable teams want to see open invoices, due dates, and statements, and increasingly want to pay invoices online by ACH or card. Invoice data is purely ERP-side, so this feature is an integration feature, not an ecommerce feature. It is also one of the highest-ROI items in any portal: invoice and payment self-service is usually the single biggest reducer of inbound calls to customer service.

Credit limits and terms

B2B orders are mostly placed on terms, not credit cards. The portal needs to know each account’s credit limit, current exposure, and hold status, and decide what to do at checkout: allow the order, route it for approval, or block it with a useful message. Credit data changes constantly as invoices post and payments clear, so this is one of the few data points that genuinely needs near-real-time treatment.

Multi-user company accounts

A B2B “customer” is a company, not a person. One account might have twelve buyers across four locations, a purchasing manager who approves anything over $5,000, and an AP contact who only needs invoice access. The portal needs company hierarchies, roles and permissions, per-user spending limits, and approval workflows that mirror how the customer’s organization actually works. Both Adobe Commerce B2B and Shopware’s B2B components handle this natively, and it is consistently the feature that closes adoption with larger accounts.

Why Most Portal Projects Get Scoped Wrong

Portal RFPs usually list features. Feature lists are the easy part. The scope items that actually drive cost and risk are almost never in the RFP:

• Where does each piece of data live, and who wins on conflict? Pricing, inventory, credit, and order status each need a declared source of truth. In practice the ERP wins on all four, and the portal that pretends otherwise creates reconciliation work forever.
• How fresh does each data type need to be? Real-time everything sounds good and costs a fortune. Prices can usually be hours old. Credit exposure cannot.
• What happens when the ERP is unreachable? Every ERP has maintenance windows and outages. A portal with no degradation plan goes down with it.
• How many pricing records are we actually moving? 500 customers times 20,000 SKUs times tiered quantity breaks is not a configuration question, it is a data engineering question.
• Who maintains it after launch? Pricing rules change, ERPs get upgraded, APIs get versioned. The total cost of a portal is mostly post-launch.

If your implementation partner is not asking these questions in the first meeting, they are planning to discover them during the build, at your expense.

Your Four Build Options, Compared

There are four realistic ways to build a B2B customer portal in 2026. We implement two of them (Adobe Commerce and Shopware, plus headless builds on both), so we will be specific about where each one wins and loses, including the options we do not sell.

Adobe Commerce (Magento) native B2B module

• Best for: Mid-market and enterprise with complex catalogs already on or moving to Magento
• Typical all-in cost: $100K-$250K+
• Time to launch: 5-9 months
• Biggest strength: Deepest native B2B feature set: company accounts, shared catalogs, negotiable quotes, requisition lists
• Biggest weakness: License cost, indexing overhead at large price-record volumes, heavier DevOps footprint

Shopware 6 B2B components

• Best for: Mid-market B2B wanting modern architecture and lower TCO
• Typical all-in cost: $75K-$200K
• Time to launch: 4-7 months
• Biggest strength: Rule-based pricing engine, Flow Builder automation, clean Store API for ERP integration
• Biggest weakness: Smaller US partner ecosystem, some B2B features require commercial plans

Headless / fully custom portal

• Best for: Enterprises with unusual workflows or an existing commerce stack to integrate against
• Typical all-in cost: $150K-$400K+
• Time to launch: 6-12 months
• Biggest strength: Exact fit to your workflows, no platform constraints, any frontend
• Biggest weakness: You own every feature forever; highest build and maintenance cost

SaaS portal tools (k-ecommerce, OroCommerce, Salesforce Experience Cloud, ERP-vendor portals)

• Best for: Smaller B2B operations that want speed over fit
• Typical all-in cost: $20K-$75K setup plus recurring SaaS fees
• Time to launch: 2-4 months
• Biggest strength: Fast launch, prebuilt ERP connectors, vendor-managed hosting
• Biggest weakness: You adapt your workflows to the tool; customization ceilings appear fast; per-user or revenue-share pricing compounds

Adobe Commerce native B2B module

Adobe Commerce ships the most complete native B2B feature set of any major platform: company accounts with hierarchies and roles, shared catalogs for account-specific pricing and assortment, negotiable quotes, requisition lists, purchase approvals, and purchase orders on terms. If your catalog is large and your pricing is complicated, the shared catalog model maps cleanly onto ERP price levels. The honest downsides: licensing is a real line item, the price indexer becomes an operational concern once you are syncing hundreds of thousands of customer-specific price records (covered in our Magento ERP integration guide), and quoting in the admin is workable but not built for high-volume quote desks. We say the same thing in our RFQ guide: the native quoting UI is fine under roughly 100 quotes a day, and needs supplementing past that.

Shopware 6 B2B components

Shopware 6 was built with B2B operational complexity in mind, and it shows in the pricing architecture: the rule builder evaluates account context (customer group, contract flags, volume tiers) at runtime, which makes ERP-driven pricing cleaner to implement than bolting customer logic onto a B2C engine. Company accounts, role-based permissions, quote negotiation, and quick order are available through Shopware’s B2B components on commercial plans. For mid-market manufacturers and distributors, it is usually the best cost-to-capability ratio on the market right now, and it is where we have done some of our strongest work, including replacing 24-48 hour manual quoting cycles with real-time configurator-driven quoting for an industrial manufacturer. Full platform breakdown on our Shopware B2B ecommerce page.

Headless and fully custom builds

Headless means a custom frontend (typically React or Vue) consuming commerce and ERP APIs. It is the right call when your portal workflows genuinely do not exist in any platform: dealer networks with territory logic, configure-price-quote with engineering review steps, or portals that are more “operations cockpit” than store. It is the wrong call when a platform covers 90% of your needs, because every feature a platform would have given you for free becomes a line item you build and maintain. We have rescued more than one over-built headless portal whose owners were paying agency rates to reimplement features Magento ships natively.

SaaS portal tools

Tools like k-ecommerce (ERP-integrated storefront for Dynamics, Acumatica, and SAP Business One), OroCommerce, and Salesforce Experience Cloud get you live fast with prebuilt connectors. For a $5M wholesaler with simple pricing, that speed is worth more than fit, and we will tell you so. The ceiling arrives when your workflows stop matching the tool: custom approval chains, unusual pricing logic, or frontend experiences the vendor’s templates cannot express. At that point you are paying SaaS fees and customization costs, which is the worst of both worlds. Treat SaaS portals as a 2-4 year bridge, not a terminal architecture, and you will make a clean decision either way.

The Part Nobody Covers: How ERP Pricing Actually Reaches the Portal

Every portal vendor’s website says “real-time ERP integration.” Almost none of them explain what that means, because the honest answer is complicated and depends on which ERP you run. This is the section we wish every buyer read before signing a portal contract, because pricing sync design is where portal projects succeed or die.

Where account pricing lives in each ERP

• NetSuite: price levels (per-currency price books on each item), customer-specific item pricing, quantity pricing schedules, and promotions. A customer’s effective price is resolved from their assigned price level plus any item-level overrides.
• SAP (ECC / S/4HANA): the condition technique. Prices are condition records resolved through access sequences and pricing procedures: customer/material combinations, customer hierarchy discounts, scales for quantity breaks. The most expressive pricing model in any ERP, and the hardest to replicate outside SAP.
• Microsoft Dynamics: Business Central uses sales price lists with customer and customer-price-group scoping plus line discounts; Finance & Operations uses trade agreements. Both resolve a price from a precedence hierarchy at order time.
• Acumatica: sales price worksheets with price types scoped to base, customer price class, or specific customer, with effective dates and volume breaks.
• Sage (100 / X3): price codes and customer price levels in Sage 100; structured price lists with reason codes in X3.

The pattern across all five: the ERP does not store “the price.” It stores rules that resolve to a price for a given customer, item, quantity, date, and unit of measure. That distinction drives the entire architecture decision below.

Real-time pull vs scheduled batch vs cached hybrid

There are three ways to get those resolved prices into a browser, and the right answer is usually a combination:

Real-time API pull

• How it works: Portal calls the ERP (or middleware) to resolve prices on page load, cart, or checkout
• Price freshness: Seconds
• Risk profile: ERP API rate limits, added page latency, hard dependency on ERP uptime
• Where we use it: Checkout-time validation, credit checks, quote pricing

Scheduled batch

• How it works: Resolved price records are exported nightly or hourly into the platform’s native price tables
• Price freshness: Hours
• Risk profile: Stale prices between runs; large imports stress platform indexers
• Where we use it: Catalog browsing prices for the full account base

Cached hybrid

• How it works: Batch sync feeds a price cache; targeted real-time calls revalidate at high-stakes moments; webhooks or change-triggered events refresh hot records
• Price freshness: Minutes for changed records, seconds at checkout
• Risk profile: Most moving parts; needs monitoring and a declared reconciliation process
• Where we use it: Our default for portals on NetSuite, Dynamics, and Acumatica

Pure real-time fails in production more often than buyers expect. NetSuite enforces account-level concurrency governance, so a portal hammering SuiteTalk on every product page will hit limits during your own peak traffic. Business Central throttles API traffic per environment and returns 429s under sustained load. SAP teams almost never allow an external storefront to call pricing BAPIs synchronously at browse time. We went deep on the NetSuite version of this in our Magento NetSuite integration guide: real-time sounds better than batch, and it usually is not worth the complexity except at the moments that matter.

The architecture we deploy most often: batch-sync resolved prices for browsing (nightly, or every 1-4 hours for volatile catalogs), real-time revalidation at quote and checkout, and event-driven refresh when a contract price changes in the ERP. Customers see correct prices instantly while browsing, the order is always priced against live ERP data at the moment of commitment, and an ERP outage degrades the experience instead of destroying it. We wrote a full technical breakdown of this pattern, including per-ERP API specifics and failure modes, in our companion post on how account-specific pricing sync actually works.

The questions that expose a weak integration plan

• How many resolved price records exist for our customer base, and how long does a full sync take?
• What is the propagation time from a price change in the ERP to the portal, and is it the same for all customers?
• What does the buyer see at checkout if the real-time price check times out?
• How are ERP API limits monitored, and what backs off when we approach them?
• When portal price and ERP price disagree on an order, which one invoices, and who gets alerted?

Any vendor who answers all five specifically has done this before. Any vendor who answers “the connector handles it” has not.

Architecture That Holds Up in Production

Beyond pricing, a production-grade portal architecture has a few non-negotiables we apply on every build:

• The ERP wins. Pricing, credit, inventory, and order status are ERP-owned. The portal reads, displays, and submits. Two-way editing of master data from the portal is how reconciliation nightmares start.
• Queue and alert, never log and pray. Every sync failure lands in a visible queue with retry logic and an alert to a named human. When an order fails to sync at 2am, someone needs to know by 2:05.
• Middleware where it earns its keep. For one platform and one ERP, direct integration is often fine. Add EDI, a 3PL, or a second storefront, and an integration layer (Celigo, Boomi, or a purpose-built service) stops being overhead and starts being the system of record for data movement.
• Degrade, don’t die. Cached prices with a freshness timestamp, checkout rules for ERP-down scenarios, and order queuing so nothing is lost during an outage.
• Idempotent everything. Retried syncs must not create duplicate orders, duplicate customers, or doubled credit exposure.

Implementation Timeline: What Actually Happens Month by Month

A realistic mid-market portal build on Adobe Commerce or Shopware, integrated to one ERP, runs 4 to 9 months. Here is the shape of a typical seven-month engagement:

Phase	Duration	What happens
Discovery and data audit	3-5 weeks	Workflow mapping with sales, CS, and AP teams; ERP data audit (price record volumes, customer hierarchy, credit logic); field-level mapping document; sync cadence decisions
Integration foundation	4-8 weeks	ERP connectivity, customer and pricing sync pipelines, order submission flow, error queue and alerting; this starts first because it carries the most risk
Portal build	8-12 weeks	Company accounts, catalog and pricing display, quick order and reorder, RFQ workflows, invoice and credit views; runs in parallel with integration hardening
Pilot with real accounts	3-6 weeks	5-15 friendly accounts on production data; this is where pricing edge cases surface, every single time
Launch and rollout	2-4 weeks	Phased account migration, rep enablement (reps are your adoption channel, treat them as users), hypercare

The phase buyers most want to compress is discovery, and it is the one phase where compression reliably backfires. Every week saved on the data audit costs two to three weeks in pilot, because pricing edge cases that a price-record audit would have caught instead surface as live customer complaints.

What a B2B Customer Portal Costs

Custom portal builds typically land between $75K and $250K+, and the spread is driven by a short list of factors, with ERP complexity at the top. Honest ranges by scenario:

Scenario	Typical range	What pushes it up or down
Shopware or Magento portal, one ERP, standard pricing (price levels or price lists, no heavy contract logic)	$75K-$130K	Catalog size, number of custom workflows, payment and credit features
Same, plus complex pricing (contract pricing, SAP condition logic, heavy customer-specific records)	$120K-$200K	Price record volumes, sync cadence requirements, quoting complexity
Enterprise build: multiple channels or brands, EDI alongside the portal, approval workflows, punchout	$180K-$250K+	Middleware build-out, multi-ERP or multi-entity structures, cXML punchout for procurement customers
Headless / fully custom	$150K-$400K+	Everything above plus owning the entire frontend feature set

Ongoing costs are real and should be planned, not discovered: platform licensing where applicable, hosting, integration platform fees if middleware is used, and a maintenance retainer. Budget 15-25% of build cost annually. The portals that compound in value are the ones with a roadmap after launch; the ones treated as one-time projects decay as the ERP and the business move underneath them.

One framing that helps CFOs: price the portal against the cost of the manual work it replaces. A CS team spending 40% of its time on “what did I pay last time,” “resend invoice,” and “where is my order” calls is a quantifiable line item. So is rep time spent keying phone orders. Most mid-market portals we have built pay back inside 18-30 months on service-cost reduction alone, before counting the revenue effect of being easier to buy from than your competitor.

What We Have Learned From 50+ B2B Implementations

Patterns that show up over and over across manufacturers, distributors, and wholesalers:

• Adoption is earned in the first session. If a buyer’s first login shows wrong pricing or missing order history, they go back to emailing their rep and they do not return. We gate launch on pricing accuracy for pilot accounts, not on feature completeness.
• Reps decide whether your portal succeeds. Portals positioned as rep replacement get quietly sabotaged. Portals positioned as rep leverage (reps see customer carts, share quotes through it, stop doing data entry) get actively promoted by the sales team.
• Invoice access is the sleeper feature. Buyers come for reordering. AP teams come for invoices and statements, log in more often than buyers, and pull the whole account into the portal habit.
• The long tail of pricing edge cases is longer than anyone believes. Unit-of-measure conversions, effective-dated contracts, customer-specific part numbers, and legacy “handshake” pricing that exists in a rep’s head and nowhere in the ERP. The data audit always finds pricing the customer did not know they had.
• Distributors have a distinct playbook. Massive SKU counts, thin margins, and customers who buy weekly make quick-order speed and inventory visibility matter more than merchandising. We wrote up the distributor-specific patterns in our guide to B2B ecommerce for distributors.
• Boring is the goal. A working portal integration is invisible. Orders flow, prices match, nobody talks about it. Every project decision should move you toward boring.

When NOT to Build a Custom Portal

We sell portal development, so take this section as the most useful thing on the page. Do not commission a custom portal build if:

• Your pricing is simple and your catalog is small. One price list, a few hundred SKUs, under roughly $5M online-addressable revenue: a SaaS portal or your ERP vendor’s own customer portal will get you 80% of the value at 20% of the cost. Revisit when your pricing complexity outgrows it.
• Your ERP data is not ready. If customer records are duplicated, pricing lives in spreadsheets, and item data is inconsistent, a portal will put your data problems in front of your customers. Fix the data first; it is cheaper than fixing it mid-project.
• Nobody owns it internally. A portal without an internal owner for pricing accuracy, content, and adoption is shelfware with a maintenance bill.
• You are buying it to avoid fixing your sales process. A portal amplifies a working order-to-cash process. It does not repair a broken one.
• Your top 10 accounts demand punchout, not portals. If your largest customers buy through Ariba or Coupa, cXML punchout integration may matter more than a portal UI, and it is a different (and smaller) project.

When prospects fit one of these profiles, we say so on the first call. A portal that should not have been built is bad for the client and worse for the agency that built it.

How We Build Them

Web Solutions NYC has been building enterprise ecommerce since 2007. We are official partners of both Adobe Commerce and Shopware, which means we recommend between them based on your operation, not our certification list. Our integration practice covers NetSuite, SAP, Microsoft Dynamics, Acumatica, Sage, and Epicor P21, and the integration team and the portal team are the same team: the people designing your pricing sync are in the room when the checkout flow is designed, which is exactly where the two disciplines have to meet.

Every engagement starts with discovery and a data audit, because that is where we learn whether your project is the $90K version or the $200K version, and you deserve to know that before you commit to either. We work with mid-market and enterprise B2B companies across manufacturing, distribution, and wholesale. We are not the right fit for template builds or early-stage startups, and we will tell you that quickly too.

Talk to Us About Your Portal

If you are scoping a B2B customer portal, the most valuable first step is a working session on your ERP data and pricing model, not a demo. Bring your ERP, your customer count, and your ugliest pricing edge case. We will tell you which build path fits, what it should cost, and whether you should build at all. Request a consultation and we will respond within one business day.

Frequently Asked Questions