SAP Key Figures Tutorial (Part 1)

In SAP Integrated Business Planning, a planning model is built around two core building blocks: master data (attributes describing planning objects like products, locations, and customers) and key figures (the numeric data that gets planned, calculated, and analyzed). If master data answers 'what are we planning for', key figures answer 'what values are we planning'. Examples include Sales History, Statistical Forecast, Consensus Demand Plan, Total Supply, Projected Inventory, and Forecast Error.

Each key figure lives inside a planning area, which is the container that ties key figures to a time profile (weekly, monthly, etc.) and a set of planning levels (combinations of master data attributes such as Product/Location/Customer). A key figure's values are always attached to a specific combination of planning level members and a time bucket, which is why IBP is often described as a multidimensional planning engine.

Key figures generally fall into a few conceptual buckets, even though the underlying configuration mechanics (covered in later lessons) are more nuanced. Stored key figures hold values that planners or interfaces write directly, such as an actuals load from S/4HANA or a manual override entered in the Excel add-in. Calculated key figures derive their values from formulas that reference other key figures, master data attributes, or time-based functions, such as a Total Demand key figure computed as Consensus Demand plus Unconstrained Demand adjustments. This distinction matters immensely for planners and consultants alike: you cannot manually overwrite a purely calculated key figure in the same way you would a stored one, and doing so (or expecting to) is a very common point of confusion for new team members.

Key figures also carry an aggregation behavior that determines how their values roll up or down across planning levels. A quantity-type key figure like Sales Order Quantity typically aggregates by summation, while a ratio-type key figure like Forecast Accuracy Percentage should not simply be summed across products; it usually needs a weighted calculation or should be marked as non-aggregating in certain contexts, otherwise the aggregated number is meaningless. Understanding this early prevents a wide class of reporting errors later.

From a business perspective, key figures are what make planning actionable and visible: they let a demand planner see and adjust forecast quantities, let a supply planner see projected inventory dips, and let a Control Tower alert be defined on a threshold breach of a key figure like Days of Supply. Every planning app in the Fiori launchpad and every Excel planning view is fundamentally a lens onto key figures within a planning level context.

Because IBP is a cloud, columnar in-memory platform, key figures are also central to performance considerations: the more key figures held in a planning area, and the more granular the planning level, the larger the potential data volume and processing cost for tasks like disaggregation, forecasting jobs, or Control Tower alert calculations. This is why model design conversations always start by asking which key figures are truly needed, at what level of detail, and whether they should be stored or calculated.

During a greenfield IBP implementation for a consumer goods company, the business team initially requested over 40 key figures in the demand planning model, mirroring every column from their legacy Excel forecasting workbook. During model design workshops, the implementation team walked through each requested key figure and classified it as stored, calculated, or informational, discovering that roughly a third were redundant view-level calculations that could be derived on the fly in Excel rather than stored in the planning area. This reduced the planning area's footprint and simplified the disaggregation logic that planners had to understand, while still giving business users the same visual outputs they were used to in their legacy process.

• Assuming every key figure needs to be stored, leading to bloated planning areas with redundant calculated values persisted unnecessarily
• Treating ratio or percentage key figures the same as quantity key figures when reviewing aggregated totals, producing misleading rolled-up numbers
• Trying to manually enter values into a key figure that is purely calculated and wondering why the input does not persist
• Not distinguishing between a key figure's technical ID and its business-facing label, causing confusion when troubleshooting formulas or integration mappings
• Assuming key figure behavior in one planning area automatically applies to a similarly named key figure in another planning area

• Start model design by classifying each candidate key figure as stored, calculated, or purely presentational before adding it to the planning area
• Use clear, consistent naming and technical IDs for key figures so mappings to S/4HANA fields and formulas remain traceable
• Document the intended aggregation behavior for every key figure, especially ratios and percentages, to avoid misleading rolled-up reports
• Periodically review the key figure list with business stakeholders to retire unused or duplicate key figures as the model matures

Interviewers commonly ask candidates to explain the difference between a stored and a calculated key figure, and to describe what happens if a planner tries to overwrite a calculated key figure's value. A strong answer connects this to the planning area architecture, mentions aggregation behavior for ratio versus quantity key figures, and gives a concrete business example rather than a purely definitional answer.