JinJin48

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

July 16, 2026 · 13 min read

SAP IBP Key Figure

A Key Figure is the SAP IBP object type that represents a single quantitative measure flowing through a Planning Area — demand quantity, supply quantity, inventory quantity, revenue, forecast accuracy, fill rate, and similar values. It is the “value” axis of the planning data cube, complementing the master-data-driven dimension axes (Product, Location, Customer, Time) covered in the Phase 1 master data articles. Unlike Product, Location, or Customer Master, a Key Figure is not typically replicated from an ERP master record — it is defined as part of building the Planning Area’s model itself. This article covers what a Key Figure is, its core Stored-vs-Calculated data model, its position in the org/data hierarchy, and every field a consultant configures when creating one.

Part 1: Key Figure — Core Concepts (All Modules)#

1.1 What Is the Key Figure?#

A Key Figure holds the transactional/planning data in an SAP IBP model — quantities and currency amounts representing plan data (sales forecast, projected inventory, capacity plan) or actual/historical data (sales orders, shipment history). It is defined and configured inside a Planning Area, not maintained as an independent, freestanding master data object the way Product or Location Master are.

1.2 Storage Type — Stored vs. Calculated#

Every Key Figure is built on one structural axis: whether its data is physically stored, or computed at run time. Getting this distinction wrong is costly — it determines whether the figure can be manually edited by a planner and whether it can ever be used as a disaggregation target.

Design principle: Stored vs. Calculated is the structural axis — it determines whether the key figure’s data physically exists in the Planning Area’s storage, which in turn decides whether it can be edited or used as a disaggregation target. Input and Output are a separate, secondary framing layered on top: usage-role labels describing how a key figure is used in a given planning step (a planner-editable input vs. a system-generated result), not a third and fourth storage type sitting beside Stored and Calculated. A Stored key figure is typically the “Input” to a planning step; a Calculated key figure — or the result a Planning Operator writes back — is typically the “Output.” See Section 2.5 for where this usage-role framing becomes an explicit configuration setting on a Planning Operator.

1.3 Organizational Levels and Data Hierarchy#

Data hierarchy with a concrete example

Client (SAP IBP Tenant)
   │
   └── Planning Area "PA-DP01" — Demand Planning Planning Area          (IBP-A03-03)
          │
          ├── Key Figure "KF-DEMAND" — Demand Quantity                    [this article's object]
          │
          ├── Planning Level "PL-PROD-LOC" — Product x Location            (IBP-A03-02)
          │
          ├── Version "VER-BASELINE" — Approved plan (baseline)            (IBP-A03-04)
          │
          └── Planning View "PV-DP-WEEKLY" — Weekly Demand Planning View   (IBP-A03-05)

Design principle: Key Figure, Planning Level, and Version are structurally parallel children of a Planning Area — none nests inside another. A Key Figure is anchored to exactly one base planning level; every other level it is viewed or planned at is either aggregated up or disaggregated down from that anchor. The full mechanics of what a Planning Level is and how it is built are covered in sibling article IBP-A03-02; this article treats “base planning level” only as the anchor point a Key Figure’s Storage Type and Aggregation/Disaggregation settings key off of.

1.4 Integration with Other Master Data Objects#

A Key Figure does not stand alone — it exists inside a chain of Phase 2 planning-configuration objects and is consumed further downstream by execution objects.

Part 2: IBP-Specific Field Details#

2.0 Scope of IBP Ownership#

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

2.1 General Definition#

General Definition is the identity layer of the Key Figure — set once when the key figure is created, on the Planning Area’s Configuration tab.

2.2 Storage & Aggregation Configuration#

This is where the Stored-vs-Calculated axis from Section 1.2 becomes concrete configuration, along with how values roll up from the base planning level to higher levels.

2.3 Disaggregation & Proportionality#

Disaggregation is the flip side of aggregation: when a planner edits a value at a higher level, the system automatically splits it back down to the base planning level.

2.4 Currency & UOM Conversion#

Currency and UOM handling are layered on top of a Key Figure’s stored base value — neither is a fixed property of the key figure record itself.

Prerequisite: Currency conversion requires exchange-rate reference data to already exist in the model (typically a compound master data type pairing “Currency From” / “Currency To” with a rate value); UOM conversion requires the conversion factor to be maintained as a Product master attribute. Neither works out of the box without this reference data in place.

2.5 Usage Roles & Governance#

This section returns to the Input/Output usage-role framing introduced in Section 1.2, now shown as it appears operationally, alongside a few advanced key figure patterns and the governance app consultants should know before changing or deleting a live key figure.

What to Read Next#

L1) Big Picture

L2-A) Master Data

L2-B) Transaction