Cube Configuration

Entity Dimension Setup

The Entity dimension is the structural backbone of consolidation and translation. It defines the organizational hierarchy — legal entities, business units, regions — and controls how data flows from child entities to parent entities during the consolidation process. For the conceptual overview of dimensions and cube design, see The OneStream Data Model. This guide covers the practical configuration of entity members, relationships, intercompany, currencies, and parent adjustments.

Entity Member Properties

Entity members are configured at Application > Cube > Dimensions > Entity Dimensions. Select an entity member and open the Member Properties tab.

Settings

PropertyDefaultDescription
CurrencyUSDThe local currency of the entity. Determines when translation is triggered during consolidation — if the entity's currency differs from the parent's, the engine translates.
IsConsolidatedTrueWhether children of this entity consolidate into it. Set to False to use the entity strictly for grouping purposes without consolidation processing.
IsICEntityFalseEnables intercompany for this entity. Both the entity and its IC partner must have IsICEntity = True.
AllowAdjustmentsFromChildren(UseDefault)Whether child entity adjustments consolidate into this parent.
SiblingConsolidationPass(UseDefault)Controls the order in which sibling entities are consolidated. Used when one entity's consolidation depends on another's results (e.g., equity pickup).
SiblingRepeatCalcPass(UseDefault)Triggers a repeat calculation after all siblings have been consolidated. Used for iterative calculations between sibling entities.
AutoTranslationCurrencies(empty)Comma-separated list of currencies this entity should automatically translate to during consolidation, in addition to its parent's currency.
Text1–Text8(empty)Custom text attributes. Usable in Business Rules, member filters, and Transformation Rules. These act as variable placeholders activated at runtime.

VaryByScenarioType and Time

Entity settings can have different values based on Scenario Type and time period. Default settings apply from the first time period in the application until a change is recorded. This allows entity properties to evolve over time — for example, a percent consolidation that changes when an acquisition completes mid-year.

Entity Security

Entity security controls who can see and interact with each entity's data.
PropertyDescription
DisplayMemberGroupControls which security group can see the entity member in dimension lists. This affects member display only, not data access.
ReadDataGroupUsers in this group can read data for this entity
ReadDataGroup2Second read group for additional security layering
ReadAndWriteDataGroupUsers in this group can read and write data for this entity
ReadAndWriteDataGroup2Second read/write group for additional security layering

UseCubeDataAccessSecurity

ValueBehavior
TrueCube-level Data Cell Access Security rules (from the cube's Data Access tab) are applied to this entity
FalseCube-level Data Cell Access Security is not applied — only entity-level security groups control access
When UseCubeDataAccessSecurity is True, you can further refine which cube-level rules apply by entering category names in these entity properties:
  • CubeDataCellAccessCategories — Comma-separated list of Data Access categories to apply
  • CubeConditionalInputCategories — Categories for conditional input rules
  • CubeDataManagementAccessCategories — Categories for data management access rules
If these are left blank, all categories from the cube's Data Access tab apply.

How Entity Security Interacts with Cube Security

Security is evaluated in layers:
  1. Application-level — User must have access to the application
  2. Cube-level — User must belong to the cube's AccessGroup
  3. Scenario-level — User must have ReadDataGroup or ReadAndWriteDataGroup on the scenario
  4. Entity-level — User must have the appropriate security group on the entity
  5. Data Cell Access — If UseCubeDataAccessSecurity = True, cell-level rules from the Data Access tab provide additional filtering
Each layer can only restrict access — a lower layer cannot grant access that a higher layer denied.

Relationship Properties

Relationship properties define how a child entity relates to its parent in the hierarchy. These properties vary by Scenario Type and Time, which means ownership and consolidation percentages can differ between Actual and Budget, and can change period over period.

PercentConsolidation

Default: 100%
Controls what percentage of the entity's data flows to the parent during consolidation. The default Share calculation is:
plaintext
1Share = (Translated + OwnerPreAdj) × %Consolidation
A value of 50 means 50% of the entity's translated data consolidates to the parent. This applies to all accounts by default. If you need account-specific consolidation percentages, use a Stored Share algorithm with custom Business Rule logic.

PercentOwnership

Default: 100%
An informational setting that has no effect on consolidation by itself. It stores the ownership percentage for use in Business Rules — for example, calculating minority interest or equity pickup amounts. The distinction between PercentConsolidation and PercentOwnership is important: consolidation uses the former; your custom rules reference the latter.

OwnershipType

An informational setting that has no effect on consolidation by itself. It classifies the relationship for use in Business Rules:
OwnershipTypeValueTypical Use
FullConsolidation1000Normal parent-child consolidation
Holding2000Holding company relationship
Equity4000Equity method of accounting
NonControllingInterest7000Minority interest portion
Custom1–Custom511000–15000Custom relationship types for Business Rules
💡Tip
PercentOwnership and OwnershipType work together in custom consolidation rules. For example, when OwnershipType = NonControllingInterest, a Business Rule can calculate minority interest as EntityTotal × (100% - PercentOwnership) and write it to a specific account on the Share consolidation member. This requires the StandardWithStoredShare consolidation algorithm.

Accessing Relationship Properties in Code

1' Get percent consolidation for the current entity/parent
2Dim pctConsol As Decimal = api.Entity.PercentConsolidation( _
3  entityId, parentId, varyByScenarioTypeId, varyByTimeId)
4
5' Get percent ownership
6Dim pctOwnership As Decimal = api.Entity.PercentOwnership( _
7  entityId, parentId, varyByScenarioTypeId, varyByTimeId)
8
9' Get ownership type
10Dim ownerType As OwnershipType = api.Entity.OwnershipType( _
11  entityId, parentId, varyByScenarioTypeId, varyByTimeId)
12
13' Use current POV defaults (pass -6 to use context)
14Dim pctConsolCurrent As Decimal = api.Entity.PercentConsolidation()
All three methods accept optional parameters. Passing -6 (or omitting the parameter) uses the current POV context. The api.POV.Parent object is only relevant when running at a relationship-level consolidation member (Share, Elimination, etc.).

Intercompany Configuration

Intercompany elimination is the process of canceling out balances held between entities under a common parent during consolidation. OneStream uses a combination of the Entity, Account, and IC (Intercompany) dimensions to manage this.

Setup Requirements

  1. IsICEntity = True on each entity that participates in intercompany transactions. Both partners in any IC relationship must have this flag set.
  2. IC dimension auto-population — When IsICEntity is True, the entity's name appears as a member in the IC dimension for selection by other entities.
  3. IC accounts — Accounts that hold intercompany balances must have a Plug Account defined. The plug account receives any difference (out-of-balance amount) when the IC elimination runs.

How IC Elimination Works

When two entities with IsICEntity = True consolidate into a common parent, the engine:
  1. Finds all data cells where the IC dimension member references the partner entity
  2. Creates an elimination entry that reverses the intercompany balance
  3. Books any out-of-balance amount to the designated plug account
diagramIntercompany Elimination at Common Parent

Loading diagram...

⚠️Warning
Intercompany elimination only works between entities that share a common parent — it does not work between a parent and its direct child. If Entity A is a child of Entity B, they cannot be IC partners because there is no common parent above them to hold the elimination. Structure your entity hierarchy accordingly.
💡Tip
Use Conditional Input Rules on the cube's Data Access tab to limit which IC members are selectable for each entity. This prevents users from accidentally selecting an IC partner that does not make business sense and avoids orphaned IC balances that never eliminate.

Parent Currencies and Translation

Currency translation is triggered when a child entity's local currency differs from its parent entity's currency. During consolidation, the engine translates the child's Local currency data into the parent's currency, storing the result in the Translated consolidation member.

Triangulation

If the child entity's currency and the parent entity's currency are both different from the application's default currency (the cube's DefaultCurrency), translation uses triangulation — converting from the child's currency to the default currency, then from the default currency to the parent's currency. This ensures all rate conversions go through a common reference point.

Alternate Hierarchy Approach

When you need to see a parent entity in multiple currencies, one approach is to create an alternate hierarchy with a different parent currency. For example, if the primary hierarchy has parent ABC in USD but you also need EUR, create a second hierarchy with parent ABC_EUR assigned the EUR currency. All child entities are shared from the primary hierarchy.
Pros: Simple setup — only a new parent entity is needed. All existing rules and logic continue to work.
Cons: Increased maintenance (additional hierarchies to manage), lower performance (more consolidation processing), and poor user experience (users must select the correct parent based on the currency they want).

Auto Translation Currencies

The AutoTranslationCurrencies property on an entity member specifies additional currencies to translate to during consolidation, beyond the immediate parent's currency. Enter a comma-separated list of currency codes (e.g., CAD,EUR,GBP).
This approach avoids creating alternate hierarchies — users toggle currencies via the Consolidation dimension instead of switching entity members.
⚠️Warning
Auto Translation Currency limitations:
  • The translated currency amounts are not the consolidated total of the entity's children. If two child entities have AutoTranslationCurrencies = CAD, and the parent does not, you cannot view the parent in CAD. The parent must also have AutoTranslationCurrencies = CAD, and it will translate independently of the children.
  • Rules that run in translated currencies must be updated to also run on parent entities with auto translation currencies.
  • Consolidation times increase with each additional auto translation currency. The impact depends on the number of currencies, entities, and rule complexity.
Tips for Auto Translation Currencies:
  • Only assign them to entities that genuinely need translation to an alternate currency
  • If the parent entity already uses the target currency, do not add it as an auto translation currency — it is already handled by standard translation
  • For parent entities that need to be viewed in both their local currency and other currencies, set the local currency as the entity's currency (not as an auto translation currency)

Parent Adjustments

Parent adjustments are top-side entries that affect the parent entity without being booked to a specific child entity. There are two common approaches.

Origin Dimension Approach

OneStream's Origin dimension provides built-in support for parent adjustments:
  • AdjInput — Adjustment data entered directly to the parent entity (via journals or forms)
  • AdjConsolidated — When a consolidation runs, child entity AdjInput entries flow into the parent's AdjConsolidated member
This means the parent entity's total includes both the consolidated children's data and any direct parent adjustments. The Origin dimension provides full transparency — you can always see what came from children (Import, Forms) versus what was adjusted at the parent level (AdjInput) versus what consolidated up from children's adjustments (AdjConsolidated).
Pros: No additional build required — the Origin dimension is designed for this purpose. Clean audit trail showing exactly where adjustments were made.
Cons: When viewing data without the Origin dimension breakout, the sum of child entities may not visually equal the parent total (because the parent includes its own AdjInput entries). This can confuse users who are not familiar with the Origin dimension.

Adjustment Entities Approach

Create dedicated adjustment entities (e.g., US_Corp_Adj) as children of the parent entity. Adjustments are entered against these adjustment entities as regular data in the Import or Forms origin.
Pros: The sum of child entities always equals the parent — the adjustment entity is just another child. Easier for users to understand in reports without needing to filter by Origin.
Cons: Additional entity members to maintain. The adjustment entity needs its own security, and it adds to the consolidation processing since it is another child to consolidate. It also mixes adjustment data with operational entity data in the entity hierarchy.
The right choice depends on the user community. If users are comfortable with the Origin dimension, the built-in approach is cleaner. If users expect the parent to always equal the sum of its children, adjustment entities provide a more intuitive experience.

Related Content