Distributor ecommerce is simpler than everyone makes it sound.
You have products. Customers want to buy them. The complexity isn’t in the storefront, the checkout flow, or the user experience. The complexity is in two things: showing accurate inventory across locations and showing the right price to the right customer.
Get those two things right, and the rest is execution. Get them wrong, and no amount of UX polish will save you. Customers who see “In Stock” and then get backorder notifications don’t come back. Customers who see the wrong price lose trust or, worse, you lose margin.
Every other feature, every platform comparison, every agency pitch deck should be evaluated against this reality: does it help you show accurate inventory and correct pricing? If not, it’s a distraction.
The Inventory Problem
Your customers don’t care about your warehouse topology. They care about one question: can I get this product when I need it?
Answering that question is harder than it looks.
The simple version: Sync inventory quantities from your ERP to your ecommerce platform. Display the number. Done.
The real version: You have inventory in three warehouses. One is your main DC, one is a regional facility, and one is a slow-moving overflow location. Some SKUs are available from all three. Some are only in the main DC. Some are allocated to specific customers. Some are reserved for backorders. Some are physically present but on quality hold.
The “quantity available” number that matters to a customer in Ohio is different from the number that matters to a customer in California. And both numbers are different from what your ERP shows as “on hand.”
What “Available” Actually Means
Most inventory sync implementations get this wrong because they sync the wrong number.
Your ERP tracks multiple inventory states: on hand, allocated, reserved, on order, in transit, on hold. “Available to sell” is a calculation, not a field. That calculation might differ by customer (some have reserved stock), by location (shipping costs affect which warehouse to pull from), and by product (some items can’t ship from certain locations).
The ecommerce platform needs the result of that calculation, not raw inventory counts.
The Virtual Inventory Calculation
Available to Web = [On-Hand Quantity] - [Allocated to Open Orders] - [Quality Hold] - [Safety Stock Buffer] - [Reserved for Contract Customers]The safety stock buffer prevents race conditions: a counter sale and a web sale hitting the same last unit simultaneously. The web customer sees “1 Available,” adds to cart, and by checkout it’s gone. A buffer of 1-5 units (depending on velocity) keeps a cushion invisible to the web channel.
Inventory allocation logic determines which warehouse fills which order. Simple implementations use “closest to zip code.” Real implementations consider:
- Shipping cost (not always the closest warehouse)
- Inventory depth (don’t drain a location to zero)
- Delivery SLA (can this warehouse meet the promised date?)
- Split shipment cost (is it cheaper to split or ship from farther?)
If your ERP handles allocation logic, expose the result to the platform. Don’t try to replicate this logic in the ecommerce layer.
The latency question: How stale can inventory data be before it causes problems?
For slow-moving products, hourly sync is fine. For fast-moving products, hourly sync means overselling. A distributor selling electrical components told us they were overselling 15-20 SKUs per day because their hot items would sell out between sync cycles. They moved to 5-minute sync for their top 500 SKUs. Problem solved.
Real-time isn’t always necessary, but understanding your inventory velocity by category is.
Multi-Warehouse Display
Customers increasingly expect to see inventory by location, not just a single “available” number. This serves two purposes: it sets delivery expectations, and it lets customers choose based on shipping speed.
The decision: do you show warehouse-level inventory, or do you show “ships from nearest location” and hide the complexity?
Showing warehouse-level detail adds transparency but creates cognitive load. Hiding it simplifies the experience but removes customer control. The right answer depends on your customers. If they’re sophisticated buyers who care about freight costs and lead times, show them the detail. If they just want to know “can I get it tomorrow,” simplify.
The Split Shipment Dilemma
Customer orders 100 units. Warehouse A has 60. Warehouse B has 40. Now what?
This is where most ecommerce platforms punt to “Contact Us” because the logic is genuinely complex.
Option 1: Ship from both locations. Customer gets everything faster, but pays higher freight (two shipments). Some customers want this. Some will be angry about the shipping cost.
Option 2: Wait for consolidated shipment. Transfer 40 units from B to A, ship as one package. Lower freight, but adds 2-5 days to lead time. Some customers prefer this. Some can’t wait.
Option 3: Partial ship now, backorder the rest. Ship 60 immediately from A, backorder 40 from B. Customer gets most of their order fast. But now you’re managing backorder expectations and potentially two invoices.
Option 4: Let the customer choose. Display the options with costs and lead times. Most sophisticated buyers want this control. But it adds UX complexity and requires real-time freight calculation.
The implementation reality: Most platforms don’t handle this natively. You need either custom logic or integration with your ERP’s available-to-promise (ATP) engine that already handles split shipment decisions. Don’t build this from scratch in the ecommerce layer if your ERP already solves it.
The split shipment problem is why “inventory availability” is harder than a single number. The answer to “can I get 100 units?” might be “yes, but here are four ways to get them with different costs and timelines.”
The Pricing Problem
Distributor pricing is not complex because you have many prices. It’s complex because you have many rules for determining which price applies.
Customer tiers. Negotiated contracts. Volume breaks. Job-specific pricing. Cost-plus arrangements. Promotional pricing. Rebate-eligible pricing. Matrix pricing based on quantity and customer level.
Every distributor thinks their pricing is uniquely complicated. It usually isn’t. But the specific combination of rules, and where those rules live, determines how hard ecommerce pricing will be.
Where Does Pricing Logic Live?
This is the only question that matters for pricing implementation.
Scenario 1: Platform can own pricing. Your pricing rules are simple enough to express in the ecommerce platform’s native pricing engine. Customer groups with assigned price lists. Volume break tables. Maybe some promotional rules. If this describes you, pricing is straightforward. Sync price lists, configure rules, done.
Scenario 2: ERP must own pricing. Your pricing logic is too complex or too dynamic for the platform to replicate. Cost-plus with daily cost updates. Matrix pricing with dozens of variables. Contract pricing that references external documents. If this describes you, the platform must call your ERP for prices.
Most distributors fall somewhere between. Standard pricing for 80% of customers can live in the platform. The 20% with negotiated contracts or complex arrangements require ERP calls.
The worst outcome is trying to replicate ERP pricing logic in the platform. You end up with two systems that calculate prices differently, and debugging “why did this customer see this price?” becomes a nightmare.
Solving ERP Price Fetch Latency
When the ERP owns pricing, every price display requires an API call. A product listing page with 50 items means 50 price calls. If each call takes 200ms, your page takes 10 seconds to load. Google’s Core Web Vitals will bury you, and customers will leave.
The Stale-While-Revalidate Pattern
1. Customer loads product page 2. Platform checks price cache 3. If cache exists (even if stale): display immediately 4. Fire async request to ERP for fresh price 5. When fresh price returns: update cache + display via AJAX 6. At checkout: always fetch fresh (accuracy trumps speed)This delivers sub-500ms page loads while maintaining pricing accuracy where it matters. Stale prices on browse pages are acceptable. Stale prices at checkout are not.
Cache TTL recommendations:
| Pricing Type | Cache Duration | Rationale |
|---|---|---|
| Stable contract pricing | 24 hours | Rarely changes mid-day |
| Standard price lists | 4-6 hours | Balance freshness vs. performance |
| Cost-plus or volatile pricing | 15-60 minutes | Tracks commodity fluctuations |
| Checkout/cart | Never cache | Accuracy is mandatory |
The key insight: design your caching strategy around the asymmetry between browsing (speed matters) and buying (accuracy matters).
The Price Display Problem
B2C shows prices on the product page. B2B often can’t.
If prices are customer-specific, you can’t show a price until you know who’s looking. This creates a UX challenge: anonymous browsing shows no prices (frustrating for researchers) or shows list prices (potentially misleading).
Common approaches:
“Login to see pricing” – Honest but creates friction. Works when your customers expect it.
Show list price, show customer price after login – Transparent but can highlight discount levels you’d rather not emphasize.
Show price ranges – “Starting at $X” gives information without commitment.
Request quote – Appropriate for highly variable or negotiated pricing.
There’s no universally correct answer. Match the approach to customer expectations in your market.
The Sales Rep Conflict
Here’s what platform vendors won’t tell you: most distributor ecommerce projects fail because of internal resistance, not technical problems.
Your sales reps see ecommerce as a threat to their commissions and their relationships. They’ve spent years building customer trust. Now you’re asking customers to bypass them. Of course they’ll resist. They’ll badmouth the platform to customers. They’ll offer to “handle it for you” to keep orders in their pipeline. They’ll find every flaw and broadcast it.
The solution isn’t forcing adoption. It’s incentive alignment.
Commission on digital orders: Reps should earn commission on orders from their accounts regardless of channel. If a customer orders online at 2am, the rep gets credit. This eliminates the incentive to steer customers away from the platform.
Sales rep portal: Give reps tools that make their jobs easier. They should be able to:
- Place orders on behalf of customers (faster than phone/email)
- See customer-specific pricing without asking the pricing desk
- Configure quotes and send for customer approval
- Track order status for their accounts
- Access customer order history instantly
When the platform makes reps more productive, they become advocates instead of saboteurs.
The adoption metric: One distributor we worked with tracked “rep-assisted digital orders” separately from pure self-service. Within a year, reps were placing 35% of orders through the platform on behalf of customers. The customers got faster service. The reps kept their relationships. The distributor got structured data and fewer order entry errors.
KPIs for Rep-Driven Digital Growth:
| Metric | What It Measures | Target |
|---|---|---|
| % of reps using “Login as Customer” | Portal adoption by sales team | >80% within 6 months |
| Manual order entry hours per rep | Efficiency gain from digital tools | 50% reduction in year 1 |
| Long-tail SKU sales via digital search | Customers finding products reps wouldn’t suggest | 15-25% increase |
| Rep-assisted digital orders | Orders placed by reps through platform | 30-40% of total digital volume |
| Quote-to-order conversion (rep-generated) | Effectiveness of rep quoting tools | >60% conversion rate |
These metrics matter because they prove ROI to the sales organization, not just to operations. When reps see their own productivity numbers improve, resistance fades.
Ignore the sales rep problem and your ecommerce project will technically succeed and operationally fail.
Logic Ownership: The Decision That Determines Everything
Before selecting a platform, decide where business logic lives. This single decision drives integration complexity more than any feature list.
| Business Logic | Platform-Owned | ERP-Owned |
|---|---|---|
| Quantity discounts | Best for UX performance (instant calculation) | Required for complex multi-buy rules or ERP-managed promos |
| Warehouse routing | Simple “closest to zip” works | Required for freight optimization, split-ship logic |
| Contract pricing | Manageable up to ~500 price lists | Mandatory above 5,000 price lists |
| Customer-part-number mapping | Simple alias tables | Required for complex cross-references or customer-specific BOMs |
| Credit checking | Basic credit limit holds | Required for real-time AR integration and dynamic credit |
| Inventory allocation | First-come-first-served | Required for customer reserves, safety stock, branch transfers |
The honest assessment:
If you can answer “platform” for most rows, you have flexibility in platform selection and simpler integration. If you answer “ERP” for most rows, your platform choice matters less than your integration architecture. The platform becomes a presentation layer.
Most distributors land in the middle. Standard pricing for house accounts lives in the platform. Contract pricing for top accounts calls the ERP. Inventory syncs from ERP, but allocation logic is simple enough to handle in the platform.
The mistake is not deciding upfront. Teams discover mid-project that they need ERP pricing, and the architecture doesn’t support it.
Everything Else Is Secondary
Once inventory and pricing work correctly, the remaining features are genuine improvements but not existential.
Quick order / order pad – Lets repeat buyers enter SKUs and quantities directly. High value for customers who know what they want. Easy to implement on any platform.
Requisition lists / saved carts – Customers save frequent orders for repeat purchase. Valuable for MRO purchasing patterns. Standard feature on most B2B platforms.
Customer-specific catalogs – Some customers should only see products they’re authorized to buy. Important for compliance in some industries. Adds complexity to product and category management.
Order approval workflows – Junior buyers submit, senior buyers approve. Necessary for some enterprise customers. Can be platform-native or integrated with customer’s procurement system.
Punch-out / procurement integration – Customers shop on your site but checkout through their procurement system (SAP Ariba, Coupa, etc.). Required for some enterprise accounts. Integration complexity varies widely.
These features matter. But if your inventory is wrong or your pricing is wrong, none of them save the project.
Platform Selection for Distributors
The honest truth: platform vendors want you to believe platform selection is the most important decision. It isn’t. Integration architecture is.
That said, platforms have real limitations that matter for distributors.
Shopify Plus / B2B on Shopify – The ceiling is low. Works for distributors with simple pricing (tier-based, under 100 price lists) and straightforward inventory (single warehouse or simple multi-warehouse). Fast to launch, but you’ll hit walls. No native ERP pricing API support. Limited inventory allocation logic. When you outgrow it, migration is painful because you’ve built processes around Shopify’s limitations.
BigCommerce B2B – Middle ground with real constraints. Better B2B features than Shopify, but still a ceiling. The API is capable but not designed for high-frequency ERP pricing calls. Works for distributors who want SaaS simplicity and can live within its guardrails.
Adobe Commerce (Magento) – No ceiling, but you pay for that flexibility in complexity and cost. Makes sense when you need heavy customization, complex ERP integration, or have requirements that SaaS platforms simply can’t accommodate. Budget 2-3x what SaaS platforms cost. Expect longer timelines.
Shopware – The sleeper option. Strong B2B features, modern architecture, genuine API-first design that handles ERP pricing integration well. Smaller US agency ecosystem is the real risk. If your agency can execute it, Shopware often delivers better TCO than Adobe Commerce for similar capability.
The skeptic’s test: Ask the platform vendor for three references doing real-time ERP pricing with 5,000+ customer price lists. If they can’t produce them, their “B2B capability” is marketing, not reality.
The Integration Architecture
For distributors, ecommerce integration is simpler than manufacturing but still requires planning.
Inventory sync: Push from ERP/WMS to platform. Not pull. The source system should push updates when inventory changes, with a scheduled full sync as a safety net. Avoid having the platform poll for inventory. It creates unnecessary load and is prone to timing issues.
Pricing sync: If platform owns pricing, push price lists from ERP on a schedule. If ERP owns pricing, build an API that the platform calls for customer-specific prices. Cache aggressively. A slow price lookup kills conversion.
Order flow: Orders from platform to ERP via message queue. Not synchronous API calls. Orders should be queued, transmitted, and confirmed asynchronously. This handles ERP downtime gracefully and provides a retry mechanism.
Customer sync: Bidirectional. New customers can register on the platform (pending approval) and then sync to ERP. Existing customers and their pricing agreements should sync from ERP to platform.
Keep the integration layer outside the platform when possible. A lightweight middleware service that handles data transformation and error handling is easier to maintain than custom code embedded in the ecommerce platform.
Getting Started
Distributor ecommerce projects fail when teams get distracted by features before fundamentals are solid.
Start with inventory. Map every inventory status in your ERP. Define what “available” means for your business. Determine acceptable sync latency by product category. Build inventory sync first and validate it thoroughly.
Then pricing. Document every pricing rule and exception. Decide what lives in the platform versus what requires ERP integration. Build pricing integration and test with real customer accounts.
Then everything else. Features, UX improvements, additional integrations. All the things that make the platform better but don’t make it functional.
The sequence matters. We’ve seen distributors launch with beautiful storefronts and broken inventory. Customers don’t forgive “In Stock” that isn’t.
Building ecommerce for distribution? The platform question is usually the wrong first question. Start with: where does inventory truth live, and how does pricing work for your top 20% of customers? Those answers determine integration complexity more than any feature list. We’re happy to walk through your specific situation.
B2B Distribution Ecommerce: Strategic FAQ
Accurate inventory is a virtual calculation, not a raw field. To find the ‘Available to Web’ number, you must take your ERP’s On-Hand quantity and subtract quality holds, safety stock buffers, and quantities already allocated to open orders. This protects your warehouse operations from web-driven race conditions.
This pattern solves ERP latency by serving a cached price immediately to satisfy Google’s Core Web Vitals, while simultaneously firing an async API request to the ERP to refresh the price in the background. This ensures sub-500ms page loads without sacrificing 100% accuracy in the cart.
The best practice is to defer to your ERP’s Available-to-Promise (ATP) logic. This allows you to offer customers choices: shipping from multiple locations for speed, consolidating at one warehouse to save on freight, or partial-shipping immediate stock while backordering the rest.
The solution is incentive alignment. Reps must earn full commission on digital orders for their accounts. Additionally, providing them with a ‘Rep Portal’ that allows them to log in as the customer and manage quotes turns the platform into a tool that increases their personal productivity.
If you have complex, real-time negotiated contracts, the ERP must remain the source of truth. While simpler tier-based pricing can live in the platform, trying to replicate matrix pricing or cost-plus logic in a commerce engine creates massive technical debt and data inconsistencies.
Is your distribution business struggling with inventory accuracy or pricing latency? Getting these fundamentals right is the difference between an ecommerce asset and an operational liability. Let’s spend 20 minutes mapping your data flow and identifying the architectural bottlenecks preventing your platform from scaling.