Blog

What is the Extensible Dimensionality feature of OneStream? Extensible dimensionality provides the ability to create various dimensional hierarchies within an application based on the level of detail that a company requires for reporting. Extensible dimensionality in the Account dimension allows for the various reports, rules, security, etc. to integrate the lower-level detail accounts required in consolidation and statutory reporting to be compared in reports to a higher-level budgeting/forecasting management reporting. Extensibility in the Entity dimension provides the finance department with the level of detail required to run a full P&L by location, as compared to the consolidation requirements of reporting on a legal entity basis for tax and audit reports. Use of an extensible dimension can also be beneficial in the Flow and UD dimensions.

OneStream defines Extensible Dimensionality as:

“Business Units can inherit dimensions from a standard set that corporate may maintain but Extensible Dimensionality allows them to extend those dimensions to suit their own process and reporting needs. This allows the units to have operational significance for their business units yet grants control of the overall process to corporate. “

Account Dimension Extensibility Example

The consolidations team is required to report their chart of accounts at a detailed level, which includes the lowest level or base accounts that make up the P&L and Balance Sheet, as compared to the planning team, who need a higher level or summary accounts for their management reporting.

In this example, we will look at how account 60999 (Net Sales) is input and reported by the planning team, as compared to the more detailed input required by the consolidation team.

The Account dimension for this example contains the higher (less detailed) accounts in the BudgetCorpAccounts hierarchy, and includes the ActualCorpAccounts (more detailed) hierarchy.

The planning department has the ability to input their data for Net Sales directly into account 60999 – Net Sales. This is because, in this hierarchy, the account is at the lowest or base level.

For the reporting of Actuals data, the consolidations team requires that account 60999 – Net Sales be broken down further into four base-level accounts that roll up into Net Sales. The four base-level accounts in this example include 60000 – Operating Sales; 60100 – IC Sales; 60200 – Returns & Allowances; 60250 – Other Outside Sales.

As seen in the below screenshot, the four base-level accounts are in black, meaning they are base level, while the Net Sales account is greyed out, indicating it is a summary level in this hierarchy.

This is another view of how it would look when comparing Actual vs. Planning Scenarios

User-Defined Dimension Extensibility Example

An application can contain several extensible dimensions, all based on the company’s reporting requirements. In the following example, we can see extensibility in the UD3 dimension, which in this instance, contains DataType information. Below you can see where those individuals in the planning/forecasting teams who are working in a Planning scenario do not require a datatype. However, those teams using an Actual scenario do require a specific datatype breakout.

Other notes regarding extensible dimensionality:

• Extensible dimensionality can inherit dimensions and then extend them.
• When designing an extended dimension, the extended members are added below the inherited members.
• Different dimensions can be assigned to different cubes, and those dimensional assignments can be different for each scenario type.
• Note of caution: ‘Using extensible dimensionality to extend accounts used within the Intercompany Matching process is not a recommended process.