For B2B merchants, the price displayed online is part of a commercial relationship that may have taken years to establish.
A trade customer might receive a standard discount across most products, negotiated prices on selected items and additional savings when ordering in volume. A national account might have different arrangements for individual branches. Another customer might buy under a contract with agreed prices and an expiry date.
When those customers log in, they expect the website to understand their agreement.
If it displays the wrong price, asks them to enter a discount code or forces them to contact their account manager, the online channel becomes harder to use. Customers return to phone calls and emails, and the merchant loses the efficiency that B2B eCommerce should deliver.
Getting pricing right requires a clear commercial model, a reliable connection to the ERP and a commerce platform capable of applying the rules consistently.
Contract pricing, price groups and volume pricing
These terms describe different parts of a B2B pricing model. Understanding the distinction helps merchants avoid oversimplifying their requirements.
Contract pricing reflects an agreement with a particular customer. It might specify fixed prices for selected products, discounts against a published price list, or conditions tied to dates, quantities and purchasing locations.
Price groups allow customers with similar arrangements to share a pricing structure. A merchant might maintain separate groups for trade customers, resellers, distributors and preferred accounts. Updating a group can change pricing for every customer assigned to it.
Volume pricing adjusts the unit price according to the quantity purchased. A product might cost $12 per unit for smaller orders and $10.50 when a customer purchases 100 or more.
These arrangements can overlap. A distributor might belong to a standard price group while also holding a contract for specific products.
The challenge is deciding which rule applies when more than one is eligible.
Define which price takes priority
Before connecting systems, merchants should document how their business determines the final selling price.
Consider a product with a standard price of $100. A customer’s trade group gives them a price of $85, while their contract specifies $80. A temporary promotion reduces the product to $75.
Should the customer pay the contract price or the promotional price? Can an additional volume discount apply? Does the answer change for a particular branch?
There is no universal answer. Some businesses honour the lowest eligible price. Others treat contract prices as fixed agreements that exclude further discounts.
This order of precedence needs to be explicit. Otherwise, the ERP, commerce platform and sales team can each arrive at a different answer.
A useful starting point is to document representative scenarios, including exceptions, and agree on the expected price with the people responsible for sales and finance.
Establish the ERP’s role in pricing
Where the ERP already manages customer agreements and selling prices, it generally makes sense for it to remain the authoritative source for those records.
The commerce platform then needs access to enough information to present and charge the correct price.
Depending on the business, that information can include:
- Customer account and purchasing-location identifiers.
- Price-group membership and contract references.
- Product codes, variants and units of measure.
- Fixed prices, discounts and quantity breaks.
- Currency, tax basis and effective dates.
- Rules governing eligibility and price precedence.
The integration may transfer resolved prices or the rules required to calculate them. That choice matters: copying a price is different from reproducing the logic that generated it.
If a dedicated pricing system owns these decisions instead of the ERP, the architecture should reflect that. The essential requirement is clear ownership, so competing systems do not independently change the same commercial agreement.
How ERP pricing reaches the commerce platform
There are three common architectural approaches.
Synchronised pricing transfers prices into the commerce platform on a schedule or when relevant records change. The storefront then uses its local pricing data.
This can provide a responsive shopping experience and reduce dependence on ERP availability. However, merchants need to define an acceptable delay between a pricing change and its appearance online.
Live pricing requests a price from the ERP or a dedicated pricing service during the buying journey. This can suit arrangements that depend on changing costs, complex formulas or information that would be difficult to replicate.
It also introduces dependencies. Response times, service availability and the commerce platform’s ability to enforce the returned price must all be addressed.
A hybrid approach synchronises prices for browsing and validates them again at an agreed stage, such as cart review or order submission.
These are architecture choices, not interchangeable features available automatically on every platform. The implementation must support the chosen approach throughout checkout and order creation.
Integration must preserve the meaning of the price
A successful integration does more than move numbers between databases.
A price of $120 could mean $120 per item, per carton or per hundred units. A contract might apply to a billing account but exclude some delivery locations. A discount could expire at midnight in a particular time zone.
Without that context, a technically successful update can still produce a commercially incorrect result.
Merchants should also plan how contracts end. When an agreement expires, its prices must be removed or replaced, and the correct fallback must become available. Transferring new prices without retiring old ones leaves outdated agreements active.
Monitoring is equally important. Failed updates, missing products and unmatched customer accounts need visible alerts and a process for correction.
Why Adobe Commerce is a strong option for complex B2B pricing
Adobe Commerce is particularly compelling when pricing is closely connected to customer-specific product access and established B2B purchasing workflows.
With the Adobe Commerce B2B extension, merchants can create shared catalogues containing selected products and custom prices, then assign them to company accounts. This supports arrangements where different businesses should see different assortments as well as different prices.
A distributor, for example, might receive access to a broad product range, while a contracted account sees a selected assortment negotiated for its business. Adobe’s shared-catalogue model provides a foundation for both experiences.
Within shared catalogues, merchants can configure fixed prices, percentage discounts and quantity-based tier pricing. Adobe also exposes APIs for shared-catalogue integration and updates to tier prices, providing building blocks for ERP-driven pricing.
For merchants with complex requirements, the strength is the combination of these capabilities and the scope to extend the implementation around their commercial processes.
That makes Adobe Commerce a strong candidate when platform selection is driven by detailed account arrangements, restricted catalogues and pricing exceptions.
Adobe’s strengths still require careful implementation
Adobe Commerce does not automatically reproduce every ERP pricing model.
Its documented shared-catalogue model assigns one shared catalogue to a company. Where an ERP combines several overlapping agreements, the integration may need to resolve them into the effective catalogue and prices for that company.
Native price behaviour also deserves attention. Adobe documents that a shared-catalogue fixed price is compared with the base price, with the lower value used. Merchants should therefore test their actual contract rules rather than assume an imported amount always takes precedence.
Adobe’s negotiable quotes provide another useful capability: buyers and sellers can discuss an order, adjust quantities and negotiate discounts before purchase. This complements ongoing account pricing, although an individual quote and a long-term contract remain different commercial records.
The case for Adobe is strongest when a merchant needs this depth and is prepared to invest in integration, testing and ongoing maintenance.
What Shopify Plus offers B2B merchants
Shopify Plus also provides meaningful native capabilities for B2B pricing.
Its B2B catalogues control product availability and pricing, with direct assignment to companies and company locations. Merchants can apply overall percentage adjustments, set fixed prices for individual products or variants, and configure quantity rules and volume pricing.
This supports familiar wholesale arrangements: shared trade pricing, account-specific prices and different terms for different purchasing locations.
Shopify also supports ERP integration through direct connectors, integration platforms and custom APIs. Its developer tools allow integrations to manage catalogues and associated price lists.
Connector selection requires care. Shopify explicitly notes that some integrations do not fully support B2B companies and catalogues. A connector that transfers products and orders may still need additional work to support the merchant’s pricing model.
For merchants whose agreements map cleanly to catalogue prices and quantity breaks, Shopify Plus can provide a practical foundation.
Where Shopify’s pricing rules need closer attention
Shopify has defined rules for resolving overlapping catalogue prices.
When multiple catalogues are assigned directly to the same company location, the lowest applicable product price is displayed, with quantity rules and volume breaks taken from the selected catalogue. When a location-specific catalogue overlaps with a B2B market catalogue, Shopify documents that the more specific location price takes precedence.
Fixed product prices also override a catalogue’s overall percentage adjustment.
These behaviours may align with a merchant’s agreements, but they should be tested.
A business that requires different precedence, formula-based pricing or live ERP calculations needs to establish how those requirements will work within Shopify’s supported capabilities. Displaying a custom price on a product page is insufficient unless the same amount is correctly applied through checkout and order creation.
Choose the platform against real customer agreements
Based on these capabilities, Adobe Commerce deserves particular consideration when complex pricing and purchasing processes are central to the business. Its shared catalogues, tier pricing, negotiable quotes and extensibility provide a substantial B2B foundation.
Shopify Plus is a credible option when the merchant’s requirements fit its catalogue and company-location model, supported by an appropriate ERP integration.
The most useful comparison is a demonstration using actual commercial scenarios.
Ask each implementation team to show a standard trade customer, an account with product-specific contract prices, a customer with multiple branches and an agreement approaching expiry. Add a promotion that overlaps with a contract and an order that crosses a quantity threshold.
Then follow each example from login through to the order received by the ERP.
Make pricing consistency the measure of success
Before launch, verify prices across product listings, product pages, carts, checkout, reorders and ERP order records. Include currency, tax treatment, units of measure and rounding in those checks.
Also test what happens when an update fails or a pricing service becomes unavailable. The business should decide whether to honour a previously validated price, pause purchasing or request a quote.
The outcome customers care about is simple: they log in, see the products and prices available to their account, and place an order with confidence.
When that experience reliably reflects their agreement, the online store becomes a dependable way to do business—and sales teams can spend more time developing accounts instead of correcting orders.