Integration·Deep dive·11 min·Updated 11 Apr 2026

The ERP → PIM → storefront data contract, drawn out

The fight about whether the SKU master lives in the ERP or the PIM is the fight that determines 80% of your integration architecture. The honest answer is: it depends on what kind of SKU attribute it is.

§ 01 — three systems, one product

The boundary is the attribute, not the SKU.

In a mature stack, one product record is split across three systems of record. Not because anyone likes it — because each system is authoritative for a different shape of attribute.

ERP owns the finance-grade attributes: SKU identifier, supplier, cost, stock, tax class, lifecycle state. Every change is audit-trailed and ties to a GL.

PIM owns the channel-facing content: marketing copy, feature attributes, variants, localized values, media references. Every change is workflow-tracked and ties to a publish event.

Storefront is usually authoritative for nothing — it's the consumer of PIM + ERP data plus its own commerce layer (pricing rules, promotions, availability).

§ 02 — the flow

ERP → PIM → storefront, in that order.

The minimum viable data contract:

ERP publishes
SKU master
id, supplier, status, cost, tax
PIM enriches
content + media
copy, attributes, variants, assets
PIM publishes
channel feeds
per-channel JSON / XML / API
Storefront layers
price + stock
real-time, from ERP or OMS
§ 03 — the contract

What the PIM must guarantee to the storefront.

  • Stable SKU identifiers. Once a SKU is published, its ID doesn't change. Rename is a new SKU.
  • Per-channel completeness. If a SKU is in the channel feed, it meets that channel's required-attribute threshold.
  • Versioning. Every publish is tagged; storefront can always ask 'what changed since t'.
  • Delete semantics. De-listing is explicit; absence from a feed is ambiguous and storefronts get it wrong.
§ 04 — the anti-pattern

Storefront as source of truth.

Commerce teams under deadline pressure often add an attribute directly to Shopify or BigCommerce metadata. Two weeks later the same attribute has to appear on Amazon, on the print catalog, on the B2B portal. Now the storefront is authoritative and every other channel has to poll it.

This is the pattern that burns the most budget in year 2. A PIM implementation is partly a cultural decision: new attributes only land in PIM, and propagate outward.

The governance questionIf a merchandiser wants to add one new attribute, where does the work start? If the answer is 'in Shopify', you don't have a PIM — you have a spreadsheet with an authoring UI.
§ 05 — MDM and the ERP question

When the ERP isn't the SKU master.

Large enterprises often have an MDM layer between ERP and PIM. The MDM (see Stibo Systems, Precisely Enterworks, Syndigo) owns the SKU master, including cross-domain references (product ↔ supplier ↔ location).

In that stack: MDM owns identity, PIM owns content, ERP owns transactions. It's more boxes to wire up, but it resolves the 'which system is authoritative' argument definitively. See PIM vs MDM vs DAM for the lines.