PIM or ERP catalogue: decide who owns each product field

A lighting product says 9 W in the ERP, 12 W on the website and 12 W in a marketplace template. All three records are complete. The launch dashboard is green. The retailer still cannot tell which value a customer should see.

Product information management begins with ownership of individual fields. Buying another catalogue system will not settle conflicting facts unless the team defines who approves the evidence, which record is authoritative and how corrections reach each channel.

Draw the boundary field by field

A product can need commercial, physical and customer-facing data from different teams. That does not require several systems to edit the same field independently. Assign an authoritative value and a correction process for each field group.

These are illustrative assignments. A retailer can use different systems while keeping the same principle: a consumer of a field sends corrections back to its authority instead of silently becoming another writer.

Akeneo's completeness measure checks required values by family, channel and locale. A populated but incorrect wattage can therefore pass a presence check. Keep completeness, factual approval and publication success as separate statuses.

Follow one wattage correction

Assume a product has 30 required attributes for a launch. Twenty-seven are filled, so completeness is 27 ÷ 30 × 100 = 90%. The missing fields are resolved, bringing presence completeness to 100%. That still does not validate the 12 W claim.

The product data owner checks supplier evidence and approves 9 W for this exact model. Version 7 records the previous value, corrected value, reason and evidence reference. The team sends version 7 to four channel destinations:

The result is 3 ÷ 4 = 75% verified publication, not a fully corrected launch. Marketplace B needs a unit mapping fix and a controlled retry of version 7. Changing its payload to 12 W just to satisfy an old template would conceal the defect.

If a delayed version 6 message later arrives at the website, the integration must reject the stale update or reconcile it against current authority. A timestamp alone is insufficient when clocks, imports and manual edits differ. Use the source's revision contract where available and define the conflict rule explicitly.

1. Verify the factProduct owner approves 9 W against the exact model specification.
2. Version the correctionVersion 7 supersedes 12 W; history remains available.
3. Publish by destinationThree channels confirm; one rejects the unit mapping.
4. Close the correctionRetry the rejected destination and verify its displayed value.

Exception: A channel rejection or an older update stays open; 100% field presence cannot close the correction.

When the ERP or commerce platform is sufficient

Keep the current setup when one small team owns a limited catalogue, attributes are stable and channel transformations are simple. Add controlled field permissions, a revision record and a publication exception list before adding another product database.

Assess PIM when enrichment, languages, multiple channel requirements or distributed approvals consume substantial effort. The relevant demonstration is a real launch and correction across your channels. A long feature list does not show whether the proposed product model handles your variants, units or approval boundaries.

ERP integration can connect product, order, stock and financial records; Shopify's integration overview describes those domains. It does not decide which of your systems should own a particular attribute. Put that decision in the integration contract.

A technical correction may also reveal an identity problem. A lamp with genuinely different characteristics is not necessarily a correction to the same sellable product. Apply the relevant product-identity and channel rules before overwriting historical data. The SKU mapping guide explains why variants and pack definitions must remain distinct.

Test a correction, not only a new product

Use one representative product family. Include a missing required field, a conflicting manual edit, a rejected channel update and an older message arriving late. Have a merchandising reviewer inspect the resulting listing, not just the integration response.

Accept the design when every approved field has a named authority, each destination reports its own outcome and the launch owner can reproduce the correction history. Separate “submitted”, “accepted” and “visible” if the channel exposes them differently. A successful API submission should not be described as a verified storefront change without supporting evidence.

Buy around the ownership problem

PIM is useful when it improves the work of enriching and distributing product information. Its value depends on clear authority and observable publication, not the number of databases that contain the product.

1. Select one product family and list its required fields by destination.
2. Assign fact approval, edit authority and publication responsibility.
3. Compare current-system improvements with a PIM demonstration using the same correction case.
4. Release the workflow only after rejected and stale changes remain visible and recoverable.