ERP should own the operational product data that transactions depend on: item numbers, units of measure, costs, prices, stock and logistics data. PIM should own the descriptive and commercial content that channels need: marketing copy, detailed specifications, translations, classifications and media links. One system of record per attribute, with ERP feeding PIM, prevents conflicts.
ERP should own the product data that transactions depend on, and PIM should own the product data that customers and channels depend on. In practice that means item numbers, units, costs, prices, stock and logistics live in ERP, while marketing copy, detailed specifications, translations, classifications and media links live in PIM. Each attribute gets one system of record, and ERP usually feeds the PIM.
Why can't ERP handle product content on its own?
Gartner defines ERP (enterprise resource planning) as "the ability to deliver an integrated suite of business applications" that share "a common process and data model" across finance, HR, distribution, manufacturing, service and the supply chain. That data model is built for orders, invoices and stock movements. It is optimised for accuracy and control of transactions.
Product content has different needs. A power tool sold through a web shop, two marketplaces and a dealer portal may need 60 attributes on one channel and 120 on another, descriptions in eight languages, and different image sets per retailer. ERP item masters rarely offer flexible attribute sets per product type, rich text, translation workflows or completeness scoring by channel. Customising ERP to add them is possible, but changes to ERP are usually slow and expensive because every modification affects core business processes.
A PIM (product information management) system is built for that variability. The What is PIM article describes its core functions.
Who should own which attributes?
The table below shows a typical split. Exact boundaries vary by industry, so treat it as a starting template for your own ownership matrix.
| Attribute group | Typical system of record | Reason |
|---|---|---|
| Item number, SKU, status | ERP | Required for purchasing, sales orders and invoicing |
| GTIN (barcode number) | ERP or MDM | Assigned once and used in logistics and point of sale |
| Units of measure, pack sizes, weights for shipping | ERP | Drive warehouse, transport and customs processes |
| Cost, transactional price, discounts | ERP or pricing system | Determine margin and invoicing |
| Stock and availability | ERP or warehouse system | Change continuously with transactions |
| Marketing names, descriptions, bullet points | PIM | Written and approved by commercial teams |
| Detailed technical specifications | PIM (sometimes PLM) | Extensive, product-type specific, channel facing |
| Translations and localised content | PIM | Managed through translation workflows |
| Channel classifications (ETIM, GS1 GPC, marketplace categories) | PIM | Differ per channel and change often |
| Product relationships, accessories, spare parts | PIM | Commercial logic for cross-sell and service |
| Image and document links | PIM with DAM | Assets stored in DAM, roles assigned in PIM |
How should data flow between ERP and PIM?
Most implementations use a one-way core flow with tightly controlled exceptions.
- ERP creates the item with identifiers, units and logistics data once the product is approved for purchase.
- PIM receives the item through an API or scheduled interface and assigns it to a product family.
- Teams enrich in PIM and the PIM validates completeness per channel.
- PIM publishes to channels, combining its content with price and stock references from ERP at publication time.
- Selected attributes return to ERP only where a process needs them, such as a short description on invoices or customs codes.
Two-way synchronisation of the same attribute creates conflicts, so avoid it. The integration architecture article covers interface patterns, and the governance article covers who approves changes to the matrix.
What are the common mistakes?
Four errors recur in PIM and ERP projects:
- Copying every ERP field into PIM. Import only what enrichment or publishing needs; extra fields create noise and confusion about ownership.
- Editing ERP data in PIM. If users can change a weight in PIM, the warehouse and the web shop will soon disagree.
- Ignoring product lifecycle status. PIM must respect ERP status codes so discontinued items leave channels on time.
- Leaving the matrix undocumented. An ownership decision that lives only in an integration specification will be lost when the team changes.
Key takeaways
- ERP owns transactional product data: identifiers, units, logistics, costs, prices and stock.
- PIM owns commercial and descriptive content: copy, specifications, translations, classifications, relationships and asset links.
- Document one system of record per attribute in an ownership matrix and review it when channels or systems change.
- Use a one-way core flow from ERP to PIM and return only the few attributes ERP processes require.
- Respect ERP lifecycle status in PIM so products enter and leave channels at the right time.
Frequently asked questions
Can ERP be used as a PIM?
ERP systems can store extra product fields, and some include basic catalogue functions. They are designed for transactions, so they typically lack flexible attribute models per product type, per-channel completeness rules, rich text, translation workflows and syndication to marketplaces. Businesses with small ranges and one channel can manage in ERP; most others find the effort of customising ERP exceeds the cost of a PIM.
Which system creates a new product?
In most organisations ERP or PLM creates the item, because purchasing, costing and logistics need the record before goods can be ordered. The PIM then receives the item and adds commercial content. Some retailers and brands reverse this, creating products in PIM first for early range planning and pushing a minimal record to ERP once the product is approved.
Should prices be managed in the PIM?
Transactional prices, discounts and customer-specific pricing should stay in ERP or a dedicated pricing system, because they drive invoicing and margin. A PIM may hold reference prices such as recommended retail price for catalogues or feeds, but it should receive them from the pricing system of record and avoid editing them locally.
For a PIM vendor overview and market commentary, see the independent resource PIMvendors.com.