New publication: practical analysis of operational architecture, commerce systems, fulfillment, data governance, and AI. Subscribe for the weekly briefing. Subscribe
Skip to content
Operational Visibility

Architecture

PIM, ERP, OMS, and WMS: Who Should Own What?

Assign authority by business object and field so operational copies do not become competing masters.

By Operational Visibility Editorial Desk · July 26, 2026 · 3 min read

Modern commerce stacks usually fail at the boundaries. The individual platforms may work as designed, but the organization cannot state which one owns a fact.

A SKU exists in the PIM, ERP, commerce platform, marketplace connector, OMS, WMS, 3PL, tax engine, and reporting layer. A price may be calculated in more than one place. An order may be copied through several networks before it reaches fulfillment. Duplication is normal. Competing authority is not.

Start with business objects

The cleanest governance model assigns authority by business object and, where necessary, by field.

A PIM generally owns enriched product attributes, taxonomy, channel content, regulatory fields, and product relationships. An ERP generally owns legal entities, financial accounts, vendor records, purchase orders, landed cost, and accounting outcomes. An OMS or orchestration platform generally owns allocation and routing decisions. A WMS or 3PL owns physical execution events inside the warehouse.

A commerce platform owns the customer-facing transaction and experience, but it should not automatically become the permanent master for every product, inventory, or financial field simply because it displays them.

Copies are necessary

An OMS needs product dimensions. A WMS needs item identifiers. A marketplace needs titles and images. An ERP needs shipped quantities. These are operational copies of authoritative data.

The architecture should document how each copy is created, how quickly it must update, whether the receiving system may edit it, and what happens when the source changes.

The goal is not to eliminate duplication. It is to eliminate ambiguity.

Use a source-of-truth matrix

For each critical field or object, record:

  • Authoritative system
  • Business owner
  • Allowed write paths
  • Downstream consumers
  • Synchronization method
  • Acceptable latency
  • Validation rules
  • Conflict policy
  • Historical retention

For example, a PIM may own marketing title and dimensions, while the ERP owns standard cost and tax classification. The commerce platform may own a promotional display price for a defined period, while the ERP receives the completed financial transaction.

A ready-to-use version is available in the Source-of-Truth Matrix Template.

Separate decision authority from data storage

A platform can store data without owning the decision. Inventory may be visible in Magento, but allocation may occur in an order-routing platform. A 3PL may select a parcel carrier, while a central orchestration layer owns the promised service level. An EDI network may transmit an invoice, while the ERP owns the financial document.

This distinction is critical when replacing systems. If decision logic is buried inside a provider-specific integration, changing providers becomes a business redesign rather than a technical migration.

Define failure behavior

Ownership is tested when synchronization fails. If the PIM publish is delayed, can the commerce site keep selling the prior version? If the WMS cannot report inventory, does the channel stop sales, use a safety buffer, or accept backorders? If the ERP is unavailable, can orders still ship and reconcile later?

These policies should be deliberate. Otherwise the last system to update becomes the accidental master.

Governance is an operating practice

A source-of-truth diagram is not enough. Teams need named stewards, change control, data-quality monitoring, and a process for resolving disputed definitions.

The practical rule is simple: let systems keep the copies they need, but make authority explicit. Duplication is a technical reality. Ambiguity is an operating cost.

For a worked example of this governance in practice, see the case study Moving Product Authority from Commerce to PIM.