SAP S/4HANA Product Data Architecture: Where PIM, MDM and PLM Fit

In a company that runs SAP S/4HANA, the ERP holds the operational and financial record of every product, and the commercial version of that product needs its own home. S/4HANA was built to run orders, stock, production and accounting correctly. Selling a product in several languages, channels and markets needs descriptions, attributes, media and feeds that the material master was not designed to manage. A workable product data architecture gives each kind of product data one owning system and defines how the systems pass data to each other. This guide maps that split for S/4HANA: what stays in SAP, where PIM, MDM, PLM and DAM fit, what clean core changes, the common reference setups and how product data moves between the systems. It is the SAP-specific companion to where ERP stops and PIM starts, which explains the general split between ERP and PIM for any ERP.

S/4HANA runs the operational product record

The S/4HANA material master is organized around operations. In the classic material master, general data such as the material number, material type and base unit of measure sits at client level (table MARA). Plant-specific data for purchasing, MRP and storage sits per plant (table MARC). Short descriptions per language sit in their own table (MAKT), and valuation and cost drive inventory accounting. Alternative units of measure, such as box and pallet, convert quantities for purchasing, sales and the warehouse.

That record has to stay in SAP, because orders, stock movements and the books depend on it. It also explains why SAP is a poor place for commercial content. A short description of one line per language serves a picking list and a purchase order. A product page, a marketplace listing and a distributor catalog each need longer copy, channel-specific attributes, images and documents, and they change for reasons that have nothing to do with production or accounting.

S/4HANA Cloud Public Edition customers do not open these tables. They reach the same material data through released APIs and CDS views. The table names still help in a conversation with an SAP team on Private Edition or on premise, where the classic structure is what the team works with. Public Edition extends the system through key-user tools and released objects, which the clean core section below covers.

Each product data domain needs one home

The practical way to split the data is by domain, with one system of record for each and an agreed direction of flow between them.

• Financial and logistic identity: material number, units, plant data, cost and price conditions stay in S/4HANA.
• Sellable content: marketing descriptions, channel attributes, taxonomies, translations and channel feeds live in the PIM.
• Engineering data: designs, specifications and the engineering bill of materials live in PLM, and reach S/4HANA for production and the PIM for technical attributes that buyers need.
• Media: images, manuals and data sheets live in a DAM or in the PIM's own asset module.
• Inventory and availability: stock levels come from S/4HANA or from a warehouse or order management system, and flow to the channels directly or through the PIM.
• Cross-domain master record: companies that govern product, supplier and customer data together add multidomain MDM as the authority for the shared record.

S/4HANA next to PIM, MDM, PLM and DAM: what each system owns

System	What it owns	Who works in it	The question it answers
ERPEnterprise resource planningERP guide	Transactions and operations: orders, stock, purchasing, pricing and finance.	Finance, supply chain, purchasing and sales operations.	What did we buy, make, sell, ship and invoice?
PIMProduct information managementPIM guide	Sellable product content: attributes, descriptions, asset links, translations and channel versions.	E-commerce, marketing, category and product content teams.	Is this product complete and ready to sell on this channel?
MDMMaster data managementMDM guide	Golden records across domains: customers, suppliers, locations and products, matched and governed.	Data governance, data stewards and IT.	Which version of this record is the true one, in every system?
PLMProduct lifecycle managementPLM guide	The product while it is designed and engineered: specifications, bills of materials, changes and compliance.	R&D, engineering, quality and sourcing.	What exactly are we making, and which version is released?
DAMDigital asset managementDAM guide	Files and media: images, video, documents, renditions and usage rights.	Brand, creative and marketing teams.	Where is the approved file, and where may we use it?

Three neighbouring topics have their own guides. Products with a bill of materials need a rule for which structure lives where, which BoM in PIM and ERP covers. The PLM and PIM integration guide explains how engineering and commercial lifecycles connect. The MDM guide separates master data management from PIM, which matters when an SAP company is deciding whether it needs one, the other or both.

Clean core allows the field, and the content question stays open

SAP's clean core approach asks customers to extend S/4HANA in ways that survive upgrades. For the product master that is more open than many buyers assume. Key user extensibility, including the Custom Fields app, adds fields, logic and other upgrade-stable extensions without developer changes to SAP objects. SAP's clean core learning material says the Custom Fields app is available for all S/4HANA deployments, and that teams should check the SAP Fiori apps reference library when an app differs by edition (SAP Learning). Classic ABAP extensions that modify SAP objects are only possible in Private Edition and on premise, and SAP does not recommend them.

So a marketing description field in the material master does not have to break an upgrade. The case for a PIM rests on function. A custom field stores a value. It brings no enrichment workflow, no completeness check per channel, no media library, no versions per market and no feed to a marketplace. Teams that run content in SAP tend to rebuild those functions around the ERP in spreadsheets.

Three reference setups

Three setups cover the SAP companies we see most often. That is our experience from selection work, not a market statistic. They differ in how many systems share the product record and in who governs it.

• S/4HANA with a PIM. S/4HANA creates the material and owns operational data. The PIM receives the material, adds content and media, and publishes to channels. This is the setup we see most often for manufacturers and wholesalers with one ERP. PIM vendors that serve it include inRiver, Akeneo, Pimcore and Bluestone PIM.
• S/4HANA with multidomain MDM and a PIM layer. A multidomain MDM platform governs the shared record for product, supplier and customer data across several ERP instances or business units. Product content and syndication run in the same platform or in a PIM. Stibo Systems and Viamedici combine MDM and PIM functions in one platform.
• S/4HANA with PLM, a PIM and SAP Commerce Cloud. Engineering data starts in PLM, S/4HANA runs production and finance, the PIM holds the sellable product, and SAP Commerce Cloud is one of several channels the PIM feeds. SAP Commerce Cloud (Hybris) alternatives covers the content side of that storefront, and the SAP Commerce Cloud profile summarises the product.

How product data moves between S/4HANA and the PIM

Integration is an important evaluation point in every setup, because it decides how current the PIM's data is and who carries the work when SAP or the PIM changes. It sits next to data-model fit, the team that will use the system and the channels it has to feed. It is not the whole decision. SAP offers three mechanisms for getting material data out of S/4HANA.

• MATMAS IDocs with change pointers. SAP's ALE documentation for material master distribution describes change pointers and the MATMAS message type. The program that processes change pointers builds a master IDoc with the segments whose fields changed, plus the mandatory segments, and those segments are sent complete (SAP Help, IDoc interface and ALE). That page is the classic ALE description, not a current S/4HANA Cloud guide, so confirm the same behavior on your release.
• The OData product API. S/4HANA exposes the material master as the Product Master (A2X) API, API_PRODUCT_SRV, with an OData V4 product API beside it. Workato's SAP OData documentation names API_PRODUCT_SRV as an example service (Workato). On S/4HANA Cloud Public Edition, SAP knowledge base article 3626726 says a GET on these Product Master APIs returns 100 records by default, for API_PRODUCT_SRV (OData V2) and the OData V4 product API. An initial load of a large material master has to page through the API (SAP KBA 3626726).
• Business events. Some designs use an SAP business event as the signal that a product changed, then read the record through the API. Akeneo's accelerator architecture lists change pointers, IDocs and event mechanisms, including SAP Event Mesh, as patterns a customer can add, and says that part sits outside the accelerator package (Akeneo Help Center). Confirm the event name and the fields in the message for your release before you design the flow around events.

PIM vendors package these mechanisms in different ways. inRiver offers an S/4HANA Cloud Connector that it describes as built with SAP BTP, for companies running S/4HANA Public Cloud, and that inRiver maintains (inRiver). The same release also says SAP's Integration and Certification Center certified inRiver's SAP Commerce Cloud Connector as built with SAP BTP and integrated with S/4HANA Cloud Public Edition. The two sentences do not name the same product, which the connector comparison spells out. Akeneo provides prebuilt integration flows that the customer imports into its own SAP Integration Suite and maintains (Akeneo). Stibo Systems connects through MATMAS IDocs (Stibo Systems) and Viamedici through SAP's RFC interface (Viamedici). Pimcore works through partners (Pimcore), and Bluestone PIM builds a tailored integration per customer (Bluestone PIM). The SAP S/4HANA PIM connector comparison describes each option on the same points: who builds it, who maintains it and which S/4HANA editions are documented.

An iPaaS between S/4HANA and the PIM

An integration platform as a service (iPaaS) is hosted middleware between S/4HANA, the PIM and the other systems. It connects to each system through its own connectors, maps and converts the data, routes it, retries failed messages and shows the flows in one monitoring view. The PIM and SAP then each connect once to the platform, instead of to each other and to every channel separately.

The benefit grows with the number of systems. A company that exchanges product data between S/4HANA, a PIM, a webshop, marketplaces, a warehouse system and a CRM can reuse connections, mappings and error handling, and can replace one system without rebuilding every connection. Our guide to PIM costs makes a related point from the contract side: a headless shop front and an iPaaS decouple the shop from one back end, which keeps a later switch possible. That is one reason to look at an iPaaS. It is not a recommendation to buy one.

For one S/4HANA system and one PIM, the balance is different. An iPaaS adds a subscription, a platform that someone has to run, and another party between the ERP and the PIM when data does not arrive. A vendor connector or a direct integration has fewer moving parts in that case.

The options SAP companies ask about fall into two groups. Neither group is a PIM, so they are named here with their documentation, not with a profile in our directory.

• SAP Integration Suite. SAP's own iPaaS, delivered as a cloud service with hybrid connectivity to on-premise and private cloud systems. SAP's product page says it covers application integration, API management, event-driven integration and B2B (SAP). Several PIM integrations already run on it: Akeneo's S/4HANA accelerators, inRiver's connector is built with SAP BTP, and diva-e's Pimcore SAP Connector runs on SAP Cloud Integration (diva-e).
• Third-party iPaaS. Boomi (docs), MuleSoft (docs), Workato (docs), Celigo (docs) and Alumio (docs) each document an S/4HANA connector based on SAP's OData APIs. Workato, Celigo and Alumio also document an Akeneo connector, and Alumio documents an inRiver connector. Workato publishes an inRiver integrations page rather than connector documentation. The connector comparison lists the documented S/4HANA and PIM connectivity we could verify for each platform.

Ownership of the mappings changes in an iPaaS setup. Alumio states that its connectors handle authentication and API communication, and that mappings, data conversions and workflows are configured separately in the platform (Alumio). On that description, the mapping sits with whoever builds and runs the flows: the customer's integration team or an integration partner. The PIM vendor maintains its API and SAP maintains its APIs. Neither maintains the mapping between them. A change to the material master or the PIM data model therefore lands with the team that owns the iPaaS flows.

The S/4HANA program is the moment to settle product data

An S/4HANA migration is one of the few moments when master data gets budget and a sponsor. The general reason is in the ERP guide, in the section on migrating the ERP. For SAP companies, the practical step is to decide the domain split inside the migration, before the new material master is built. Every content attribute that moves to the PIM then does not have to be migrated into SAP, cleaned there and moved out again.

1. Assign every attribute to a domain and a system

   List the attributes in the material master and in the spreadsheets around it, and mark each one by domain: operational, commercial, engineering, media or inventory. Each domain gets one system of record. An attribute that is edited in two places gets a rule for which side wins.

2. Choose the reference setup

   The number of ERP instances, the need for a governed cross-domain record and the channels to feed decide between S/4HANA with a PIM, with MDM and a PIM layer, or with PLM, a PIM and SAP Commerce Cloud.

3. Define the flows and the integration route

   For each flow, record the direction, the SAP mechanism (IDoc, API or event) and the route: a vendor connector, a partner integration or an iPaaS. The connector comparison describes the options per vendor.

4. Test with real material data

   An export of one product group, with variants, units and two languages, shows in a demo whether the data model and the flows hold up before the contract is signed.

Fitting vendors into the architecture

With the domains, the setup and the flows defined, vendor selection compares like with like. The PIM RFP guide uses a named stack, "We run SAP S/4HANA with custom extensions for inventory allocation", as its example of a requirement a vendor can price. A vague "we use an ERP" does not. Integration is usually the largest part of an implementation. Our PIM costs guide says implementation can be up to half of total cost of ownership in the first years, and that the biggest part of that is usually the connections to systems such as the ERP. That is why integration deserves a place in the evaluation, next to data-model fit, the team that will use the system and the channels it has to feed. Manufacturers will find SAP-relevant vendors in PIM for manufacturing. Every PIM vendor named on this page has a profile in the PIM solutions directory.

Where to go from here

Both tools are free and independent of any vendor.

Not sure you need a PIM yet?

A short check that shows whether a dedicated PIM helps your catalog, or whether spreadsheets and ERP still do the job.

Check if a PIM fits

Ready to compare vendors?

Answer questions about your scale, sector and must-haves and get a ranked shortlist.

Build my vendor shortlist