Syncing B2B prices between Shopify and an ERP

In the overview article on pricing I described why prices are a special case and how responsibility can be divided in principle: the ERP calculates, Shopify modulates. How much modulation is allowed depends on the business model. This article covers the case where the answer is "as little as possible" — but where price determination itself is the most complicated: B2B.

Pricing architecture can't be assessed in the abstract, so let me set out the conditions. For the B2B case I'm assuming the following:

As soon as the marketing team is supposed to set its own prices at short notice, the architecture tips toward shared responsibility — with all the conflicts I described in the previous article. If any one of these assumptions drops away, the solution changes.

That leaves discount codes out of scope. They aren't a price but a deviation from a price, which is why they belong in the B2C case.

The requirements list stays manageable:

"Display and calculate" is deliberately stated twice. Showing the customer a tiered price in the storefront isn't enough. The checkout has to apply it as well. This is exactly where many solutions fall apart, because the display is solved via metafields and the calculation then no longer takes effect.

I covered the fact that the displayed price and the invoiced price can diverge in the overview article. In B2B this gets worse, because the customer knows their own terms. A discrepancy of a few cents gets noticed here, while in B2C nobody would ever spot it.

The shop therefore has to replicate the ERP's price determination exactly rather than approximately — including rounding and tier thresholds. That does presuppose that there is something unambiguous to replicate in the first place. Where terms exist in the ERP only as historical accretion and not as an articulated rule, no integration can transfer them reliably either. The groundwork then belongs in the ERP, not in the shop.

If price determination stays too complex to replicate in the shop, the path leads to a live query against the ERP. That has two consequences: every product page depends on the ERP's availability and response time, and caching is only possible to a limited extent, because the price is customer-specific. It isn't always avoidable.

Whichever route you choose, the transferred order should be checked against the ERP's own price determination and every discrepancy should be logged. Anyone who overwrites without comment learns about a broken sync from a customer complaint. Anyone who logs usually finds it the same day.

With Shopify Plus this is now possible natively. But there are ways forward on the other plans too.

The B2B features in Shopify Plus cover the requirements listed above natively. Catalogs are assigned to company locations, contain price lists with fixed or percentage-adjusted prices, and support quantity rules and tiered pricing. The catalog price takes effect on both levels — storefront and checkout — without having to be recalculated in the theme. That satisfies the "display and calculate" requirement without developing any pricing logic of your own.

What you do have to watch is keeping it updated. A price change in the ERP doesn't affect one field, it affects every catalog the item appears in. Update only the base price and the old values stay behind in the catalogs — and those are exactly what the customer sees. With percentage adjustments the change carries through automatically; with fixed prices it doesn't. So the integration has to know which item sits in which catalog with which kind of price.

The same applies to assignment. New items don't automatically land in every catalog, and new customers don't automatically land in the right one. Catalog maintenance therefore belongs in the integration just as much as the price itself, including the question of what should happen when a new customer or a new price list is created in the ERP.

That goes for compare-at prices too. The compare-at price is part of the price list, can be read, edited and displayed, and therefore needs no special handling in the theme. For the integration, though, it means it has to be treated like the price: if the list price changes in the ERP, the update belongs in every affected catalog — otherwise the shop shows a discount that no longer exists.

Catalogs exist without Plus as well, though in limited number and via customer segments rather than company locations. For companies with a few clearly delineated pricing tiers, that's enough. This route then avoids an additional platform, an additional license and an additional point of failure.

The limit lies in the number of pricing terms. As soon as the ERP maintains more price lists than can be represented in Shopify, the mapping begins: customers get rounded to the nearest matching segment. That works for a while, and becomes a problem the moment the first customer compares their invoice with the shop. This rounding should therefore be a deliberate decision, not a quiet workaround inside the integration.

Apps are the obvious route, but they differ fundamentally when it comes to ERP integration. What matters isn't the feature set in the frontend, but the question of where the app stores its prices.

Metafield-based apps write prices, tiers and customer assignments into metafields. That isn't true of every app, but where it is, the integration becomes simple: the ERP writes to the metafields via the Shopify API and doesn't need to know anything about the app itself. If the app instead keeps its data in its own database with no outside access, things get difficult. Then all that's left is manual maintenance or switching apps.

The second variant is external portals that take over the B2B side entirely. Here an API of their own is required. If one exists and is documented, the integration can be built — though the ERP is then talking to two systems instead of one. Without an API the route is barely viable. This question therefore belongs before the choice of app, not in the implementation phase.

That leaves custom development. Here you define your own API, build an integration on top of it, and connect the ERP through it. The advantage is obvious: the ERP's pricing model doesn't have to be forced into someone else's schema — it sets the structure.

The cost is equally obvious. Pricing logic, cart calculation and operations are then your own responsibility, including updates when Shopify evolves its APIs. In practice this pays off where the pricing terms are so company-specific that no off-the-shelf product can represent them. For everything else, Plus is the cleaner route, provided the license cost is justifiable relative to development and operating effort. That calculation doesn't work out at every revenue level.

Whichever route you choose, the scope of the integration stays the same. The ERP supplies resolved prices, not rules, because resolution should happen where the rulebook lives. What gets transferred is the price, its validity, the customer or catalog assignment, and the tier thresholds.

Two points are decisive here. Price changes need a trigger, not a nightly batch run across the entire assortment. A full reconciliation makes sense as a safety net, but in day-to-day operation it's too slow and too expensive. And new items, new customers and new price lists are events in their own right with their own logic. Treat them as a special case of the price sync and you'll find them later as a gap in the assortment.

That covers the B2B case for a single market. How the split looks in B2C is in the overview article and the accompanying deep dive. Separate posts on multiple countries, currencies and tax logic, as well as on bundles and variant logic, will follow.