Pricing between Shopify and ERP: which system owns what?

In the previous post we sorted item data by how it is maintained operationally. Prices ended up in the ERP, with a note that they deserve their own deep dive. Here it is — in two steps, though. This article settles the basic split; the two follow-up articles then cover the concrete implementation for B2B and B2C.

There are many ways to synchronise prices between Shopify and an ERP. Some are more wrong than others. Which one fits depends less on the technology than on who is supposed to decide about prices day to day.

Both Shopify and the ERP can define prices. An item without a price effectively does not exist in Shopify — the field is mandatory. At the same time, pricing is one of the ERP's core tasks. So there is no side here that you can simply leave empty.

Prices are also rules and logic, not just fixed values. A sales price is rarely a number in the master record. It results from price list, customer group, volume tier, promotional period, currency and occasionally a special approval.

Finally, the available rule sets differ from each other. The ERP can model conditions for which there is no equivalent in Shopify. Conversely, Shopify has constructs such as catalogs, discount codes and automatic discounts that do not exist in the ERP in that form. So the interface does not just translate values, it translates two different mental models into one another.

The split becomes easier if you ask not about systems but about the type of intervention. The ERP calculates prices from costs, conditions and procurement. Shopify modifies existing prices through mechanics that act on the moment of sale.

The actual architectural question is therefore not which system owns prices, but how much may be modulated. Anyone who fails to answer that question ends up with blurred responsibilities — and with prices those are particularly unpleasant, because they only show up on the invoice.

As soon as the order is processed in the ERP, there are inevitably two price instances: the one displayed in the shop and the one billed in the ERP. The two should be identical, but that cannot be guaranteed, because time passes between the price being retrieved and the order being processed.

So what happens when the transferred order contains a different price than the ERP-side pricing? Is the shop price adopted, because it was promised to the customer? Or the ERP price, because it is the calculated one? Who decides that in the case of a three-cent deviation, and who in the case of thirty percent? And how does anyone even find out about it? The knock-on effects are the same as with blurred responsibilities.

In practice, it works well to check the order in the ERP against your own pricing and to treat deviations as an event rather than as a silent correction. Whoever overwrites without comment learns about the broken sync from the customer's complaint. Whoever logs it usually finds it the same day.

How strongly the two sides are weighted depends on the business model. In B2B, pricing authority lies almost entirely with the ERP, because conditions are agreed contractually and are rarely spontaneous. In B2C, by contrast, the competitive advantage lies precisely in the ability to react at short notice to demand, stock levels and competitors. A shop team that has to wait for an ERP slot for every campaign is not a shop team capable of acting.

By way of example, here is how the requirements on the systems differ:

An addition on the guardrails: in B2B they follow from the conditions model and do not need to be defined separately. In B2C, by contrast, they are the prerequisite for the shop team to be able to work independently without endangering the margin. In practice they are nevertheless often missing, because they belong to nobody: the ERP team considers them a marketing question, the marketing team a controlling question.

In the B2B case, the shop is written to by the ERP. Prices are customer-specific, volume discounts are the rule and discount codes the exception. That article describes how base prices, volume tiers, customer prices and compare-at prices can be modelled with and without Shopify Plus, and what the interface has to deliver for that.

In the B2C case, the ERP supplies the base price and the costing basis, while the shop works with bundles, campaigns and discounts. What matters there are the guardrails and the question of how the ERP processes orders whose prices it did not calculate itself.

Both deep dives look at a single market to begin with. As soon as several countries, currencies and tax logics come into play, the picture shifts again. Separate posts will follow on that, as well as on discount logic, bundles and variant logic.