JinJin48

SAP Consultant | BTP · S/4HANA · US Global Rollout

July 16, 2026 · 11 min read

SAP IBP Master Data Types

Master Data Types are the predefined internal technical objects that SAP IBP uses to represent categories of information — product, location, customer, and the combinations and references between them — and to segment planning data accordingly. Every Attribute, every Product/Location/Customer Master record, and every Planning Area in an SAP IBP model is ultimately built on top of a Master Data Type definition, which is why it is the first object a consultant designs when standing up a new planning model. This article maps the three official Master Data Type categories, their placement in the model’s data hierarchy, and the field-level detail of the Master Data Types app used to configure them.

Part 1: Master Data Types — Core Concepts (All Modules)#

1.1 What Are Master Data Types?#

A Master Data Type is not business data itself — it is the schema definition that tells SAP IBP what kind of data a category represents and which Attributes belong to it. Conceptually it plays the same role that a table/entity definition plays in a data model: Product, Location, and Customer are examples of Master Data Types, while an actual product such as “PROD-001” is an instance (a master data record) that conforms to that type. Every planning model must have its Master Data Types designed and activated before any master data records, Key Figures, or Planning Areas can be built on top of them.

1.2 Master Data Type Categories#

SAP IBP recognizes exactly three Master Data Type categories, selected explicitly when a type is created in the Master Data Types app (New → Simple / Compound / Reference). Picking the wrong category is a structural design error — a type’s category cannot be changed after creation, only deleted and recreated, which cascades to every Attribute, Planning Level, and master record built on it. This decision belongs in model design, before any master data load.

Design principle: Reference types exist specifically to avoid loading duplicate data for the same underlying master (a currency or location playing two roles in one model) — model a Reference type before considering a second Simple type for the same real-world object.

1.3 Organizational Levels and Data Hierarchy#

Data hierarchy with a concrete example

Client (SAP IBP tenant / Model)
   │
   ├── Master Data Type "MDT-PROD" — Simple · Product
   │      └── Attribute "ATTR-PRODID" — Product ID (Character, key attribute)
   │
   ├── Master Data Type "MDT-LOC" — Simple · Location
   │      └── Attribute "ATTR-REGION" — Region (Character)
   │
   ├── Master Data Type "MDT-CUST" — Simple · Customer
   │      └── Attribute "ATTR-COUNTRY" — Country/Region (Character)
   │
   └── Master Data Type "MDT-LOCPROD" — Compound · Location × Product
          MDT-LOCPROD ── compound of ──> MDT-LOC
          MDT-LOCPROD ── compound of ──> MDT-PROD

Design principle: Master Data Types sit at the top of the model hierarchy — they exist independently of any single Planning Area and are typically defined once per model, then reused across every Planning Area built in that model (see Section 1.4).

1.4 Integration with Other Master Data Objects#

A Master Data Type never stands alone — it is the schema that every downstream planning object depends on. Attributes, master data records, Key Figures, Planning Levels, and Planning Areas all carry an explicit reference back to the Master Data Type(s) they are built from, and that reference cannot be changed once significant master data or planning data exists without a model redesign.

Part 2: IBP-Specific Field Details#

2.0 Scope of IBP Ownership#

Legend: ◎ = Owner / Critical, ○ = Direct involvement

2.1 General Type Definition#

Every Master Data Type — regardless of category — starts from the same short identification screen in the Master Data Types app. These fields are entered once at creation and are the foundation every later configuration step (attribute assignment, compounding, referencing) is layered on top of.

2.2 Simple Master Data Type Configuration#

Simple types are where actual attribute data is assigned. Configuration here defines both what the type stores and which single attribute uniquely identifies each record.

2.3 Compound Master Data Type Configuration#

A Compound type stores attribute values that only make sense for a specific combination of two or more Simple types — for example, an MRP type that differs by Location and Product together, not by either alone.

Prerequisite: Component Simple types must exist with their key attribute already assigned before a Compound type referencing them can be created — the compound key derivation reads that assignment at creation time.

2.4 Reference Master Data Type Configuration#

A Reference type is deliberately empty of its own data — it exists to let the same underlying values play a second semantic role without a duplicate load.

2.5 Naming Convention & Prefix Governance#

Because Master Data Type IDs are referenced throughout the model — by Attributes, Planning Levels, Key Figures, and every Planning Area — SAP enforces, and best practice reinforces, a strict, model-wide naming discipline from the very first type created.

What to Read Next#

L1) Big Picture

L2-A) Master Data

L2-B) Transaction