How does contract pricing actually work in B2B ecommerce, and why does it break native connectors?

Almost every mid-market distributor prices the same way, whatever the ERP is called. There is a published number, a tier the customer sits in, a deal the customer negotiated, and a discount for buying more. Those four layers stack, and the number your inside sales rep sees when they key an order is the result of resolving all four in a fixed order of precedence.

The vocabulary matters here because platform vendors use the same words for different things. When a Shopify partner says "custom pricing" they mean layer two. When your controller says "contract pricing" they usually mean layer three. Those are not the same problem and they do not cost the same to solve.

The number that actually has to appear on the product page is the fourth row of the table below, the effective price. Everything else is an input to it.

There are exactly four places the effective price can be worked out, and the whole architecture argument on a B2B commerce project is really an argument about which one you are choosing. They are not compatible with each other. Two of them running at once is how a storefront ends up quoting a different number from the order desk.

The reason only one can win is that each place holds a different set of inputs. The ERP knows the contract, the expiry date and the customer’s tier. The storefront knows the cart, the quantity and the session. Middleware knows whatever you tell it. If two of them can produce a price, then sooner or later they will produce two prices, and the business will believe whichever one is worse for you.

Pick the row below that matches how your pricing actually behaves, not the row that matches the platform you have already shortlisted. Deciding source of truthThe source of truth is the system that gets to be right when two systems disagree. For price, stock and customer terms in an ERP-run business, that is almost always the ERP. for price, field by field, removes more risk from a commerce project than the platform choice does.

Every number in this section was read from vendor documentation on 20 August 2026. Shopify in particular revises these limits, so treat the date as part of the fact.

Shopify B2B expresses pricing as catalogues. A catalogue holds a price list and is assigned to companies or company locations. Shopify documents two ways to set a price: an overall percentage adjustment across the catalogue, or fixed prices, and Shopify states that "fixed prices override any overall adjustments that you set". Volume pricing is real: "You can add up to 10 price breaks per product which are applied to each variant." There is a catch worth knowing before you design around it, in Shopify’s own words: once volume pricing applies, "the price becomes fixed. Any overall adjustment discount set on the catalog won’t apply."

The counts are the part that decides platform fit. On Basic, Grow and Advanced you can assign "up to 3 active catalogs across all your B2B markets"; on Shopify Plus you can create an unlimited number. Separately, "Each company location can have a maximum of 25 catalogs assigned to it" and a store can hold "a maximum of 10,000 total catalogs". Where a product appears in more than one catalogue for a buyer, Shopify says "the lowest price displays to the customer", which is a rule you have to design around rather than a rule you can turn off.

BigCommerce reaches customer-specific pricing through customer groups and price lists, and B2B Edition layers company accounts and negotiated quoting on top. Shopware ships an Individual Pricing component in B2B Components that Shopware describes as letting merchants "define catalog-wide discounts and special pricing based on flexible conditions". Drupal Commerce is the outlier: it has no fixed price model at all. A price is produced by a chain of price resolvers, and the resolver receives a Context carrying "The customer assigned to the cart/order" and the store and the time, which means a custom resolver can go and ask your ERP.

A native connectorA native connector is integration software published by the ERP or platform vendor themselves, configured rather than built. Acumatica ships native connectors for Shopify and BigCommerce. is a copier. It reads a field in the ERP and writes a field on the platform. That model works for a product title and it works for a stock quantity, because both of those are stored values. The effective price is not a stored value. It is the output of a calculation the ERP runs when someone asks, and there is no field to copy.

So the connector copies the nearest stored thing instead, which is the list price. Acumatica’s own community, answering a direct question about syncing the current effective sales price to Shopify rather than the Default Price, said "No. Only Default Price is supported." Cin7 has a different version of the same shape: price tiers are a fixed set of columns on the product, so the ceiling is the number of tiers rather than the calculation.

The failure is quiet, which is the dangerous part. Nothing errors. The product syncs, the order syncs, the price is simply wrong, and you find out when an account that has bought at a negotiated price for four years sees list price on the new website and phones their rep. Every contract you sign afterwards widens the gap, because the storefront has no way to learn about it.

There is a second, subtler break. Contract prices usually carry effective and expiry dates. A price list on a commerce platform generally does not, or does so only at the level of the whole list. When you flatten dated prices into an undated list, you have not just lost a feature, you have removed the mechanism that made last year’s price stop applying.

You do not need a discovery project for this. You need six numbers out of your own ERP, and any of your finance or sales operations people can pull them. Write them down before you take another platform demo, because they change which demo is relevant.

The read on the answers is blunt. If line one is small and lines three and five are zero, you are a price-list business and a native connector path is genuinely fine. If line three is large or line five is non-zero, you are a runtime-pricing business and you should stop evaluating connectors as though they will solve it.

Four situations where this whole page is somebody else’s issue, and you should go and solve something that is actually in your way.

One thing we will not call for you. Several vendors, Acumatica included, advertise that company-specific volume break rules synchronize to the storefront. We have not verified that end to end and the community thread we cite does not test it. If break quantities are how your pricing works, prove that in a sandbox with your own data before you believe anyone about it, us included.