JinJin48

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

July 16, 2026 · 13 min read

SAP IBP Planning Version

A Version — commonly called a Planning Version, and referred to simply as “Version” throughout the SAP IBP UI and this article — is a full, independently-stored copy or snapshot of an activated Planning Area’s data. It is not a filter, a view, or a live pointer into a shared set of numbers: it is a genuinely separate data instance that must be explicitly created (copied) and, to reflect later changes to its source, explicitly re-copied. A single Planning Area (IBP-A03-03) routinely holds several Versions side by side — typically Baseline, Working, Simulation, and Consensus. This article assumes the reader already understands what a Planning Area is and how it is activated (see IBP-A03-03) and goes deep on the Version object itself: the four Version Types, the Version-vs-Scenario distinction every consultant gets asked about, version-specific vs. version-independent data, and how Versions are created, copied, and deleted.

Part 1: Version — Core Concepts (All Modules)#

1.1 What Is the Version?#

A Version holds no data of its own until it is created — it is a full copy of its source Planning Area’s data (master data and/or key-figure values, depending on configuration), frozen at the point of creation or last copy. It is a downstream dependent of Planning Area, not a peer configuration object: a Planning Area must already exist and be activated before any Version of it can be created.

1.2 The Four Version Types#

The four Version Types are not four different technical mechanisms — every Version is built and copied the same way under the hood. They are a process-driven typology: naming and usage conventions for how an organization applies the identical Version mechanism at different stages of its planning cycle. Getting the typology right matters because it sets expectations about who edits which Version, and when a Version’s numbers are safe to treat as “official.”

Design principle: These four names are conventions, not enforced technical categories — nothing stops a customer from creating additional Versions with other names for other purposes. The internal source’s own Notes-row caveat (“formulate a version strategy before go-live”) exists precisely because this naming/purpose design is a deliberate up-front decision, not something to grow organically after a Planning Area is already live with real data.

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                    (IBP-A03-01)
          │
          ├── Planning Level "PL-PROD-LOC" — Product x Location            (IBP-A03-02)
          │
          ├── Version "VER-BASELINE" — Approved plan (baseline)            [this article's object]
          │
          └── Planning View "PV-DP-WEEKLY" — Weekly Demand Planning View   (IBP-A03-05)

Design principle: All Versions hang directly off the same activated Planning Area (1:N) as independent, sibling copies alongside Key Figure and Planning Level — none nests inside another, and none is “the real one” that others are variants of at the data-model level (Baseline is only the conventional source of truth, not a structurally privileged Version). The landscape’s Zone C shows only VER-BASELINE as the representative Version instance; the four Version Types (Baseline, Working, Simulation, Consensus) and the ad-hoc Scenario concept are covered in this article’s later sections (2.1-2.2), not in the org-hierarchy position shown here.

1.4 Integration with Other Master Data Objects#

A Version does not stand alone — it exists only because a Planning Area was already activated, and everything a planner actually touches (Planning Views, Scenarios) is built on top of a specific Version.

Part 2: IBP-Specific Field Details#

2.0 Scope of IBP Ownership#

Legend: ◎ = Owner / Critical

2.1 Version Configuration#

These are the four settings the internal knowledge base’s Version settings table lists — set when a Version is created inside the Manage Versions and Scenarios app.

Notes-row caveat (internal source): “Formulate a version strategy before go-live.” Version design — how many Versions, what each represents, who can write to which — is something to plan deliberately up front. Retrofitting version structure (especially enabling Version-Specific Master Data, Section 2.3) after a Planning Area has gone live and accumulated data carries real, documented risk.

2.2 Version vs. Scenario#

This distinction is not covered in the internal knowledge base at all, but it is one of the most-asked, most practically relevant questions about this object in public SAP IBP documentation and community discussion — a consultant will be asked about it constantly. Versions and Scenarios can both serve “what-if” purposes, but they are architecturally very different mechanisms.

In short: Versions are heavyweight, administrator-governed, copy-based, long-lived plans; Scenarios are lightweight, user-created, delta-based, short-lived what-ifs layered on top of a Version. Both can answer “what if,” but a Simulation-type Version and an ad hoc Scenario are not the same mechanism and should not be conflated when scoping or explaining this object to a client.

2.3 Version-Specific Master Data (VSMD)#

By default, master data is version-independent — every Version of a Planning Area shares the same Product, Location, and Customer master (and Attributes). Key-figure (transactional/planning) data, by contrast, is inherently version-specific by design: this is the entire point of having multiple Versions, since each one stores its own distinct key-figure values. VSMD is an optional configuration that changes the master-data side of this default — presented here as an advanced, caution-flagged option, not the default behavior.

2.4 Copy & Delete Operations#

Significant Version-data operations in SAP IBP are implemented as auditable, schedulable Planning Operator jobs — not instant, one-click UI actions. No public source found this session documents a distinctly-named “merge” feature for Versions; what gets colloquially called “merging” two Versions’ data is better understood as a Copy Operator run with an overlay of multiple source copies onto one target Version.

Prerequisite: All three operators (Copy Operator, Copy Version Operator, Delete Version Operator) execute as Planning Operator jobs — full execution mechanics (scheduling, monitoring, job chains) are covered in IBP-A05-01 (Planning Operator, Phase 4).

What to Read Next#

L1) Big Picture

L2-A) Master Data

L2-B) Transaction