Most product data problems get reported as storefront bugs. A variant shows as out of stock when the warehouse has forty. A UPC is missing from the shopping feed. A price changed in one market and not another. Someone opens the theme to look for the cause, and the cause is two systems upstream.

This work starts from the other end. Where does each field come from, which system is allowed to change it, and what happens to it on the way to Shopify.

ERP, PIM, Shopify: who owns what

The usual arrangement, and the one that holds up best, gives each system one job.

The ERP owns operational truth. SKUs, cost, stock by location, and usually the base price. It is the system finance trusts, and it should not be edited from anywhere else.

The PIM owns the product as the customer sees it. Titles, descriptions, attributes, imagery, compliance data, category structure, and the relationships between products. It enriches what the ERP creates and syndicates the result to every channel, of which Shopify is one.

Shopify owns presentation and commerce. How the product appears, which market sees it at what price, what the cart and checkout do with it.

Problems start when those lines blur. A merchandiser edits a title in Shopify because it is quicker, the next PIM sync overwrites it, and the fix gets made twice more before someone asks why. Writing down which system owns which field, and enforcing it in the integration, prevents most of this.

Modelling the product properly

Identifiers. SKU, UPC or GTIN, MPN, and the ERP's own item number are not the same thing and should not share a field. The shopping feed, the marketplace listing and the AI assistant all want a GTIN. The warehouse wants the SKU. Getting these into the right Shopify fields and metafields, at variant level, is dull and it matters.

Variants and options. An ERP thinks in items. Shopify thinks in products with up to three options, now extended by combined listings. Deciding how a range of blade lengths, handle materials and finishes becomes products and variants is a merchandising decision with technical consequences, and it is best made once, deliberately, before the sync is built around it.

Attributes as metafields. Materials, dimensions, weights, specifications and care information belong in typed metafields and metaobjects, not in the description. Structured, they drive filtering, comparison, structured data and search. Buried in copy, they do none of those.

Pricing and inventory. Base prices from the ERP, market prices from Shopify Markets or a price list, and stock by location. Each needs a clear direction of travel and a known sync frequency, so that nobody is surprised when a price change takes an hour to appear.

When it goes wrong

The troubleshooting method is the same whatever the systems are. Take the one product that is wrong, and follow it from the ERP record to the PIM to the Shopify API to the rendered page, comparing the value at each step. The step where it changes is the step with the problem. It sounds obvious, and it is faster than reading integration code in the hope of spotting the bug.

At catalogue scale the same comparison runs as a script: export each system, join on the identifier, and list every product where the systems disagree. That report is usually the most useful single document in a data clean-up, because it turns "the data is a bit messy" into a list with a length.

The integrations around the store

A Plus store at scale usually carries a handful of integrations that each hold their own data and their own assumptions. The common ones:

Cross-border. Shopify Markets, Managed Markets or Global-e, depending on where the brand sells and who should be merchant of record. Each changes how prices, duties and returns flow, and each has to agree with the catalogue and pricing coming from upstream.

Site search and merchandising. A search platform indexes the catalogue and ranks it. It is only as good as the attributes it is fed, which puts it downstream of the same product data work.

Tracking and analytics. Server-side tracking so that conversion data reaches the ad platforms intact, with product identifiers that match the feed. When the IDs in the pixel do not match the IDs in the catalogue, attribution quietly breaks.

Configurators and 3D. Product customisers need option data, pricing rules and inventory that agree with the cart. The configurator and the checkout have to reach the same price.

AI assistants and chat. On-site shopping assistants answer from the catalogue. Gaps in the product data become wrong answers in front of customers.

The specific tools vary by brand. The method does not: find out which system owns each field, check the data where it crosses between systems, and make sure every sync reports when it fails.

Knowing when something stops

Integrations fail quietly. A sync that stopped on Tuesday shows up as a stock complaint on Friday. Every integration built here reports its own failures to someone who will act on them, and has a written note of what it does, what it depends on and how to restart it. That note is written for whoever maintains it next, including the in-house team.

What this is not

It is not an ERP or PIM implementation. Choosing and configuring the ERP is a different specialism. This is the work of making the systems you already have agree with each other and with the storefront, and of building the Shopify side of the integration properly.

How it works

01