Calculated and Global Key Figures: Formulas, Operators, and Cross-Planning-Area Reuse

Explanation

Once a planning model has basic stored key figures (demand, supply, inventory), most real projects need derived values: safety stock coverage in days, forecast error percentages, days of supply, or gross-to-net calculations. SAP IBP supports this through calculated key figures, which are defined using formulas that reference other key figures, planning level attributes, and time offsets, evaluated at runtime rather than stored as static values (in most configurations). A calculated key figure formula can use standard operators (+, -, *, /), conditional logic (IF/THEN style expressions supported by the formula editor), and functions for time-shifting (referencing prior or future periods) and aggregation overrides. For example, a 'Forecast Accuracy %' key figure might be defined as 1 - (ABS(Actual - Forecast) / Actual), with safeguards for division by zero. Because these formulas execute at query or calculation time, performance matters: overly complex nested formulas referencing many time offsets can slow down planning views, especially on large planning areas with many key figures and combinations. A critical design decision is where the calculation happens: as a calculated key figure (planning-area-specific, defined in the key figure configuration) versus a global key figure (reusable across multiple planning areas, defined once and referenced wherever needed). Global key figures reduce duplication when an organization runs multiple planning areas for different scopes (e.g., separate areas for tactical S&OP versus detailed supply planning) but share common derived metrics like inventory turns or service level. However, global key figures must reference attributes and key figures that exist consistently across all planning areas using them, which constrains master data and planning level design; inconsistent attribute usage across planning areas is a common reason global key figure references fail validation. Designers must also decide the aggregation behavior of calculated key figures independently from their input key figures. A calculated key figure is not simply 'summed up' from lower levels unless explicitly configured to behave that way; often the correct approach is to calculate at the base planning level and then aggregate the result, rather than aggregating inputs first and calculating at a higher level, because ratios and percentages do not aggregate linearly. Getting this wrong produces key figures that look plausible at detail level but are mathematically incorrect when viewed at aggregated levels like product family or region, a defect that is easy to miss during initial testing if reviewers only check one aggregation level. Troubleshooting calculated key figures typically involves: verifying the formula syntax and operator precedence in the configuration UI, checking that all referenced key figures are populated at the levels being tested (a calculated key figure referencing an empty stored key figure often returns blank or zero rather than an error), and testing edge cases like zero denominators, negative quantities, and missing time periods. When a calculated key figure returns unexpected values in a planning view, the standard diagnostic approach is to isolate the individual referenced key figures in the same view, at the same level and time bucket, to confirm inputs are correct before assuming the formula logic is wrong. From an S/4HANA integration perspective, calculated and global key figures are generally an IBP-side construct; the values feeding them (actuals, orders, stock) typically originate from S/4HANA or other source systems via integration, but the calculation formulas themselves execute within IBP. Consultants should avoid recreating S/4HANA-side calculation logic redundantly in IBP unless there is a clear planning-specific reason, to prevent maintaining the same business logic in two places with risk of divergence.

Code example

# Illustrative formula pattern for a calculated key figure (conceptual, not exact IBP syntax)# Forecast Accuracy % at base planning level# IF(Actual = 0, NULL, 1 - (ABS(Actual - Forecast) / Actual)) # Days of Supply (calculated at base level, then aggregated as a weighted measure downstream)# IF(Average_Daily_Demand = 0, NULL, Ending_Inventory / Average_Daily_Demand) # Design note:# - Calculate DOS at product-location-day level first# - Aggregate using a weighted average (e.g., inventory-weighted) rather than simple average#   when rolling up to product-location-month or higher

Real project scenario

A consumer goods client had two planning areas: one for monthly S&OP and one for weekly supply planning. Both needed an 'Inventory Turns' metric. Initially, two teams independently built separate calculated key figures with slightly different formulas (one used average inventory, the other used ending inventory), causing the S&OP and supply teams to report different turns numbers for the same products in governance meetings. The resolution was to define Inventory Turns as a single global key figure with an agreed formula and denominator convention, then reference it in both planning areas, eliminating the discrepancy and giving both teams a single source of truth for that metric.

Common mistakes

• Aggregating input key figures first and calculating ratios afterward, producing mathematically incorrect aggregated percentages or rates • Building duplicate calculated key figures with slightly different formulas across planning areas instead of using a shared global key figure • Not handling division-by-zero or null cases in formulas, causing blank or error values in planning views • Creating overly complex nested formulas with many time offsets that degrade planning view performance • Assuming a calculated key figure is stored and can be used as a filter or input the same way as a stored key figure, when it is only evaluated at runtime • Failing to validate that all planning areas referencing a global key figure share consistent attributes and key figure structures

Best practices

• Calculate ratios and percentages at the lowest meaningful planning level, then aggregate the result rather than the inputs • Use global key figures for metrics shared across multiple planning areas to enforce a single formula definition • Explicitly handle zero/null denominators in every formula to avoid blank or misleading values • Keep formulas as simple as possible; split complex logic into intermediate calculated key figures for readability and performance • Document the aggregation behavior and calculation level of every calculated key figure alongside its formula • Test calculated key figures at multiple aggregation levels, not just the level used during initial development, before releasing to planners

Interview angle

Interviewers assess whether candidates understand the difference between calculating at base level then aggregating versus aggregating then calculating, since this is a frequent source of real defects; strong candidates can explain why ratios and percentages require base-level calculation. Candidates should also be able to articulate the trade-off between calculated key figures (planning-area-specific, simpler to manage) and global key figures (reusable, but requiring consistent design across planning areas), and describe a realistic troubleshooting approach for an incorrect calculated value.