A SKU source of truth is not simply the database with the most product fields. It is the operating agreement that says which system owns each decision, which identifiers never change, and how an approved change reaches every dependent channel.
Without that agreement, a correction made in a marketplace portal may be overwritten by the next feed. A warehouse may receive a new pack under an old identifier. Reporting may combine two products that operations must keep separate.
Separate identity from description
Start with the fields that identify what is sold: internal SKU, GTIN where applicable, variant relationship, unit of measure, pack quantity and lifecycle status. Treat those as controlled records. Titles, bullets and imagery may be localized by channel, but they should still have a declared owner and an approved source.
An internal SKU can remain the stable key for systems that your organization controls. A channel listing ID is an external reference, not a replacement for that key. GS1’s GTIN Management Standard defines when a trade-item change requires a new GTIN; use the current standard for products that carry GTINs rather than inventing local reuse rules.
The practical rule is: do not change an identifier merely to make a listing look cleaner, and do not reuse a retired identifier for a different sellable item.
Build a field-level ownership map
For each important field, record:
- the authoritative system;
- the accountable role, not only a person’s name;
- who may propose and approve a change;
- the downstream destinations;
- validation rules and required evidence;
- the rollback or correction path.
For example, merchandising might own the consumer title, product operations might own the variant structure, finance might approve tax classification, and warehouse operations might own case-pack handling. One PXM can distribute all of those fields without becoming the business owner of every value.
Use the downloadable catalog source-of-truth workbook to document this map. Pair it with the connected PXM, OMS and WMS overview when defining system boundaries.
Put changes through a controlled workflow
A workable change path has five stages: request, validate, approve, publish and verify. The request should name affected SKUs and the business reason. Validation checks identifier rules, required attributes, pack math and dependencies. Approval comes from the named owner. Publication carries a version or change ID. Verification confirms the intended values at each destination.
Consider a hypothetical brand that changes a 12-count case to an 18-count case. The each may be unchanged, but the higher packaging level, dimensions, weight and replenishment settings are not. The team creates the appropriate new package identity, updates the hierarchy, validates warehouse handling, then activates channel mappings. Editing only the display title would leave fulfillment using the wrong quantity.
Handle failures without creating a second truth
If a destination rejects a change, keep the approved source record and mark that destination out of sync. Do not quietly modify the master to satisfy one channel if doing so would make the value wrong elsewhere. Route the rejection to the field owner, correct the channel transformation, and resubmit only the failed scope.
If an urgent portal edit is unavoidable, record it as a temporary exception with an owner and expiration. Reconcile it back into the source before the next automated publication. Otherwise the next feed may reverse it.
Choose the right governance tradeoff
Central control improves consistency but can slow urgent corrections. Distributed editing increases speed but raises overwrite and audit risk. A sensible middle ground is centralized identity and validation, with controlled channel-specific enrichment where the channel genuinely needs a different expression.
Measure the process using rejected changes, destinations out of sync, unapproved portal edits and time to verified publication. Do not treat raw field count as a quality metric.
A useful next step
Select ten commercially important SKUs. Trace five identity fields and five descriptive fields from their owner through every active channel. Record conflicts and decide which system should win before changing data.
1Commerce can help teams connect catalog ownership to marketplace and fulfillment workflows without assuming that every integration or optional service is configured the same way. Explore the multi-channel platform or ask 1Commerce to review your catalog controls.