System of Record for Product Data: ERP, Shopify, or PIM?

From an operational perspective, choosing the system of record is a question about the team doing the work. It determines who works in which system day in, day out. A marketing specialist shouldn't have to despair in the ERP, and a logistics manager shouldn't have to run the annual inventory count off five different Shopify reports with incomplete data.

With this article I want to give an overview of what different setups can look like and how they affect costs, everyday working life, and employee satisfaction. Alongside pure master data, I'll also touch on inventory and prices, because they provide the necessary context.

What happens when no deliberate decision is made about the system of record? Responsibilities end up split across different teams and systems. Operationally, nobody really feels accountable, and technically you get data conflicts.

Dividing things up by responsibility is entirely correct — and it's the subject of this article — but the split has to be made deliberately, along topic lines.

In practice, though, this mixed approach is often chosen unconsciously: by not using automated interfaces at all, or by having bidirectional interfaces write to the same fields.

What happens when the price is lower in one system? Does the lower one win? Or the most recently updated one? Does every interface then have to attach a timestamp to every piece of information, which then gets evaluated in a middleware layer? What happens when fields get repurposed over time and are updated for different reasons? Do notes attached to orders in the shop get overwritten? Can the ERP then no longer attach notes at all? The knock-on effects should be obvious.

In the rest of this article I'll examine various alternatives along with their pros and cons. In almost every case, all of the approaches discussed here — despite their drawbacks — are preferable to mixed responsibility within a single topic.

In many companies the ERP already owns the data for historical reasons. As soon as new channels are added, conflicts arise over who should be accountable for the data, why the marketing team has to work in awkward rich-text fields on the product page, and why the product still isn't showing up in the shop when the launch was scheduled a week ago.

The UX for maintaining the emotive, distribution-facing values (marketing copy, images, attributes) is in most cases so poor that it measurably increases employees' digital stress. That isn't a design flaw in the ERP — it simply wasn't optimized for these tasks. Digital stress has far-reaching consequences and shouldn't be downplayed.

Inventory data, on the other hand, is consolidated in one place in the ERP and therefore carries a lot of meaning. Additional channels can be connected as well, and manual or offline orders are accounted for. One important detail: transmit available inventory, not physical inventory.

Financial data — such as part costs and machine operating costs in production — is also correctly linked to the product through the ERP's data. That enables accurate calculation of COGS, shipping, and profitability.

Bulk editing tools in most ERPs are decent too, for example via a direct Excel connection.

If the interface to the shop goes down, however, several problems appear: the shop has no current data on prices or inventory. In a B2B context, it can also mean new customers can no longer place orders at all.

Over the past few years, Shopify's data model has become so flexible — through the continuous expansion of metaobjects and metafields — that it can represent almost all of the data on an ERP product record. That doesn't mean it can create, validate, and evaluate that data.

The UX for maintaining products in Shopify is well optimized for marketing teams. Publishing a product to the right market takes a few clicks, or can be partially automated, with immediate effect and in sync with current campaigns. The ERP can (where technically supported) react to events like products/update or product_listings/update.

Inventory is calculated in real time for shop orders. Some additional channels, such as Amazon, can also be connected without much trouble. Syncing offline orders, by contrast, is difficult. It requires either complex custom development, manual entry, or accepting incomplete inventory in the shop.

Reconciling inventory movements between Shopify and the ERP is complex. Here I'd recommend the ERP as the system of record, with continuous updates. And rather than sending inventory figures from the shop to the ERP, send the inputs for the calculation: orders, returns, freebies, and so on. This is a case where a real-time interface really does pay off, in order to avoid overselling or wrongly rejected orders.

Shopify's bulk editing tools offer limited options, or require additional dependencies on apps like Matrixify.

If the interface fails, orders placed outside the shop can lead to severe overselling.

Neither of the previous options sounds particularly convincing to me. Which is why there's of course another candidate for managing product data: the PIM (Product Information Management system)!

It brings an additional platform along with it, and therefore extra fees, maintenance effort, and all the other downsides. Even so, it deserves honest consideration at least beyond a certain operational size (more than two sales channels or languages, more than ten products that need explaining).

The UX for managing product data is excellent — that's what it was built for, after all. And when the PIM acts as the system of record feeding both the shop and the ERP, both systems are always up to date. Because it's deliberately positioned as a data management tool for other systems, the standard interfaces are often solid too. That makes it easier to expand to additional channels.

Ideally, the tooling for bulk editing, product rules, commercial terms, and smaller automations is well developed too.

Publishing usually happens in several steps, with the PIM mainly holding a veto over incomplete product data, while either the ERP or Shopify handles the actual go-live.

If the interface goes down, product data updates stop coming through. But since this isn't inventory or price data, a short outage is bearable.

In conversations about interfaces, product data is often treated as a single topic. That's too simplistic, and it causes problems operationally.

What works better is a technical split of the data that follows operational responsibility. As soon as individual roles have to operate across multiple systems, responsibilities blur — and the suitability of the split should be questioned.

Inventory should be held in the system that genuinely brings together all orders and purchases: the ERP. Outflows from the shop and other channels should ideally be derived logically, not by simply adjusting the stock figure. In practice, that means: transmit orders and returns, not snapshots of inventory levels. Those snapshots serve at most to validate that an interface is working correctly.

Following the same logic, prices should be held where they can be calculated and decided: in the ERP. That's where prices and inventory come together, so the SKU should also originate here and be pushed out to the other systems.

Emotive product data (images, marketing copy, attributes), on the other hand, should be held in Shopify — or in the PIM, where there's capacity and multiple (multilingual) channels. That reduces employees' digital stress, avoids shared responsibilities, and offers greater agility for campaigns and promotions.

This article has looked at the split of article and product data from a high altitude. Further deep dives into the technical specifics of prices, bundles, Shopify Markets, and variant logic will follow.