Data Professionals Blog posts
cancel
Showing results for 
Search instead for 
Did you mean: 
GregBotticchio
Product and Topic Expert
Product and Topic Expert
2,437

GregBotticchio_0-1778684484075.png

What is Asymmetric Reporting?

It is our pleasure to announce the introduction of a new innovation in SAP Analytics Cloud, delivered as part of the 2026 Q2 QRC release.

Asymmetric Reporting introduces a new way to design tables in SAP Analytics Cloud, enabling greater flexibility in how data is structured and presented within a single table.

Instead of relying on a strictly uniform layout, where all rows and columns follow the same dimensions, hierarchies, and granularity, Asymmetric Reporting enables selected aspects of a table layout such as measures, time ranges, and visible hierarchy levels, to vary across different sections of the same table.

In practice, this means that a single table can combine multiple perspectives. For example, one part of the table may focus on actuals at a detailed monthly level, while another section presents forecasts or budgets at a higher level of aggregation. These views coexist within the same table, without requiring separate reporting objects or duplicated structures.

This capability helps users design more expressive and context-aware tables directly in SAP Analytics Cloud, better reflecting the way business questions are actually asked and answered.

 

Why it matters: Real-world reporting is not symmetric

Traditional table structures in BI and planning tools are typically symmetric by design. This means that the same dimensions, hierarchies, and filters are applied consistently across all rows and columns of a report.

While this approach ensures simplicity and consistency, it often does not reflect the reality of business reporting, especially in financial planning and analysis scenarios.

In practice, different parts of the same report frequently require different levels of detail or different analytical perspectives. For example:

  • Actuals are often analyzed at a monthly or even daily level of granularity
  • Forecasts may start from a specific cut-off date
  • Budgets are frequently reviewed at a quarterly or yearly level

Bringing all of these perspectives into a single symmetric table often leads to compromises: duplicated reports, complex workarounds, or loss of clarity in how data is presented.

From a planning perspective, this limitation becomes even more visible. An additional challenge comes from “unbooked” combinations that must remain visible for data entry and forecast collection, even when no transactional data exists yet. Business users want to compare actuals, forecasts, and budgets side by side, but each of these elements naturally follows a different logic and time structure. Forcing them into a single rigid model can reduce both usability and analytical accuracy.

Asymmetric Reporting in SAP Analytics Cloud addresses this challenge by allowing different parts of a table to reflect different structures and levels of detail, while still being part of a single, coherent model. This makes it possible to align table design more closely with real business processes, rather than adapting business logic to technical constraints.

 

Example and typical use cases

A typical example is a rolling forecast table.

In this scenario:

  • Accounts are displayed in the rows
  • Actuals are shown from January up to a selected cut-off date
  • Rest of Year Forecast starts after the cut-off date through the end of the period
  • Full Year Actuals plus Forecast provides a consolidated yearly view
  • Full Year Budget is displayed at a quarterly level
  • A Delta highlights the difference between Budget and Actuals plus Forecast

Each column represents a different perspective, with its own logic and level of detail. This is what makes the table asymmetric.

This approach is especially useful for:

  • Rolling forecasts
  • Budget vs Actual vs Forecast analysis
  • Financial statements such as P&L or Balance Sheet
  • Management reporting dashboards

 

See it in action

To see how this comes together in practice, watch the following demo:

 

In this example, notice how:

  • Time ranges adjust dynamically
  • Different measures display different levels of granularity
  • The table adapts based on user input

 

How it works: The building blocks behind Asymmetric Reporting

Asymmetric Reporting is enabled by a combination of three key innovations that work together.

First, Measure Input Control in Restricted Measures and Cross Calculations allows input controls, such as date, version, or measure selection, to dynamically drive calculations within the table.

Second, Dynamic Time Filters for “Rest of Period” automatically adjust time ranges based on the current context, enabling scenarios like “Actuals up to a selected date” and “Forecast for the remaining period.”

Third, Visibility Filters for Table Widgets control which dimension members or hierarchy levels are displayed for each measure, allowing different parts of the table to present different views.

Combined, these capabilities enable each column or row to behave independently while remaining part of a single, consistent table.

With these building blocks, you can:

  • Combine multiple reporting perspectives in a single table
  • Mix different levels of granularity (monthly, quarterly, yearly)
  • Dynamically adapt time ranges and calculations
  • Reduce the need for multiple tables or manual workarounds
  • Create reports that better reflect real business logic

 

Share your feedback

Asymmetric Reporting introduces a more flexible way to design tables in SAP Analytics Cloud.

By combining dynamic calculations, adaptive time filtering, and flexible display control, it enables reporting structures that better align with real-world business needs. This results in more intuitive reports, improved analysis, and a more efficient BI and Planning experience.

That being said, we now want to hear from you. Your feedback directly helps us improve both the product and its documentation.

Please let us know your thoughts. Your input is highly appreciated and will actively influence future enhancements to SAP Analytics Cloud.

 

9 Comments
thomaselit
Explorer
0 Likes

Reference is being made to planning and forecasting scenarios. But not for actual data entry it seems (i.e. the planning and forecasting activity). It’s really just about reporting, correct?

GregBotticchio
Product and Topic Expert
Product and Topic Expert
0 Likes

@thomaselit Hi, 

Data entry scenario are fully compatible with this asymmetric reporting layout, if it is the question. 

Best regards, GB. 

thomaselit
Explorer
0 Likes

I’m curious to understand how planning would work with restricted or calculated measures 🙂

William_Yu1
Product and Topic Expert
Product and Topic Expert
0 Likes

Restricted measure allows data entry by itself.  Calculated measure also allows data entry if there is inverse formula defined. 

Tano_B
Participant
0 Likes

Thank you for this blog post. It's a very nice innovation! The asymmetric reporting feature is great for flexible table layouts and the new "rest of year" reduces complexity/scripting aswell.

Just for curiosity: how did you get those black and semi transparent bars in the monthly grid? When I try to build it, I need to add the version to the layout.. Or is it a styling rule in the table design panel?

GregBotticchio
Product and Topic Expert
Product and Topic Expert

@Tano_B Hi, 

It is ad-hoc styling rules for the restricted measures "Actuals" and "Forecast".  
And,  we are also considering an enhancement in order to avoid the creation of the styling rules. 

Regards,

GB

 

JefB
SAP Champion
SAP Champion
0 Likes

Is there a way users can compare the FY values (AC+FC) of 2 different rolling forecast versions?
which are based on 2 different cutover dates? because only 1 custom CurrentDate input control can be set now in a SAC story... for example to compare Forecast March 2026 (cutover date = 202603) vs Forecast June 2026 (cutover date = 202606)

Hi, thanks for the great article! In the screenshot showing the months as columns (Jan, Feb, Mar), the year is not displayed in the month headers. How exactly did you achieve this? Whenever I set up my table, it always shows the full format like 'Jan (2026)'. Is there a specific display option or workaround to hide the year?

elias_stolpfa6314_0-1779261856232.png

 

mholiveira
Explorer

Hi all,
Unfortunately, this solution reveals a significant struggle for SAC. It forces the use of restricted and calculated measures.
In high-volume scenarios, I can see that it does not work because the system will crash during the intermediate calculations. Even if you push the filters into the measures, it becomes high-maintenance and tedious, and it can still crash.
Today, you can have a lot more data visible simply via Advanced filter + Version + 1 measure. This is not the case with restricted and calculated measures (the SAC engine was designed to have as few measures as possible).
I still don't get why we couldn't implement this directly in the version dimension or via an advanced filter. My only guess is that SAP tried to make it flexible, but at the cost of an architectural decision and report design. Many companies try to simplify for quick input by using only versions + 1 measure, rather than many measures (especially due to intermediate calculation issues and maintenance).
In real-world use cases, we need to change versions, and while input controls seem flexible, the SAC architecture suffers from performance issues and kills any calendar task that sends the versions to the layout.
An obvious limitation of this is that if you want to do Actuals Year PYTD + Actuals Month CY, you will need 3 measures to have a simple total. Another is currency conversion: to have Local and Group, simply because you cannot change the measure on the restriction dynamically, which leads to a calculation measure on top to do a simple IF, or we need to multiply everything by 2 or use JavaScript to dynamically change it.
Lastly, styling rules should have been considered because, with multiple granularities, this forces multiple rules, which will end up replicating the measures definition/logic.
BR,
Miguel