Financial consolidation applications continue to carry more responsibility. They are no longer used only for statutory consolidation and financial statements. Many organizations now expect Oracle Financial Consolidation and Close to support management reporting, local GAAP views, IFRS reporting, constant currency analysis, disclosure detail, operational reporting and additional business views.
As these requirements grow, a single-cube structure can become difficult to manage. More dimensions, more data combinations, more reporting needs and more business logic can increase sparsity and make processing more complex.
Oracle’s Multi Cube capability for Financial Consolidation and Close addresses this challenge by allowing additional Consol cubes. Oracle positions Multi Cube as a way to create more focused data sets and improve performance by reducing the need to combine too many features and data combinations into one cube.
For finance, consolidation and EPM leaders, this is an important architectural development. Multi Cube is not simply another configuration option. It creates a more flexible way to separate reporting needs, reduce unnecessary cube complexity and support more scalable consolidation design.
Why Multi Cube Matters in Oracle FCC
Historically, Financial Consolidation and Close supported a single cube. That meant users had to combine multiple reporting features, detail levels and data combinations within one structure. As those combinations grew, the application could become more sparse, which could complicate data processing and reduce performance.
Multi Cube changes that model. Instead of forcing every requirement into one Consol cube, organizations can enable additional Consol cubes and use each cube as a unique data set. This helps finance teams design applications around clearer reporting purpose, data relevance and business usage.
The strategic value is straightforward:
- Keep financial statement data focused
- Separate management reporting from statutory reporting
- Support local GAAP or IFRS views more cleanly
- Store additional disclosure detail outside the main cube
- Reduce unnecessary data combinations
- Improve application design flexibility
- Support more targeted reporting and analysis
The result is a more intentional architecture for Financial Consolidation and Close.
Current BSO Cube Support in FCC
Oracle describes the current BSO cube support as including a Rate Cube and a Consol Cube. The Rate Cube stores all global rate data for all currencies. The Consol Cube stores Essbase data, journal data, metadata, rules, forms, reports, audit detail and all artifacts in a single cube.
This structure works for many standard consolidation needs. But when organizations add more reporting standards, management reporting views, detailed disclosure requirements and additional business dimensions, a single cube may become less efficient. Multi Cube gives organizations a way to separate those needs more effectively.
What Multi Cube Support Adds
Oracle’s Multi Cube support introduces four additional Consol cubes with predefined names:
- Consol2
- Consol3
- Consol4
- Consol5
Each cube is treated as a unique data set. Additional cubes can be enabled as needed, without rebuilding the application. Oracle also notes that the approach is based on existing technology already used in other EPM Platform business processes.
This is valuable because it gives EPM teams expansion flexibility. Organizations do not need to redesign the entire application just because a new reporting requirement emerges.
Additional Cube Enablement
Additional Consol cubes are created through Enable Features. Each new cube contains seeded artifacts such as metadata, rules and data forms. Oracle also notes that additional cubes support the same application configuration options as the main cube and include a duplicate copy of exchange rate data.
This makes the additional cubes operationally usable from the start. However, enabling a cube is only the first step. The larger work is deciding what belongs in that cube, how data should move, how reports should be built and how security should be managed.
Dimension Member Independence
Oracle identifies an important design principle: seeded dimension members are available in all cubes when the cube is created, while user-defined members can be assigned to one or more cubes. This gives administrators more control over cube structure.
For example, a custom account member used only for management reporting may not need to exist in the main financial statement cube. A disclosure-related member may belong in an additional cube. A product or department detail may be assigned only where that level of detail is required. This helps reduce unnecessary member usage across cubes and supports cleaner data segmentation.
Application-Wide Elements
Not every component becomes cube-specific. Oracle identifies several elements as application-wide, including approval status, approval groups, dimension security, role security, valid and invalid intersections, application settings, consolidation settings, recommendations, Task Manager templates and schedules, and operational dashboards.
This is important for implementation planning. Application-wide elements create consistency across the FCC application. But they also require careful design because certain governance decisions will apply beyond one cube. For example, if approvals or security need to behave differently by cube, teams must evaluate the right configuration approach instead of assuming every setting can be isolated at cube level.
Cube-Specific Elements
Oracle also identifies several cube-specific elements. These include dimension members, cell-level security coming soon, business rules, seeded consolidation and translation rules, insertion rules, translation override rules, configured consolidation rules, ownership, data forms, reports, Data Exchange, journals, ICM and journals reports, and Task Manager task integrations.
This is where Multi Cube becomes operationally meaningful. A cube can have its own data forms, reports, journals, rules and data exchange configuration. That means each cube can serve a specific business purpose rather than acting as a duplicate of the main cube.
Data Movement Between Cubes
Oracle identifies two main options for moving data between cubes: Data Copy and Data Exchange.
Data Copy is an existing feature. It supports limited mapping and includes journal entry detail.
Data Exchange provides more advanced mapping options. Oracle notes that journal data is treated as the value, and Quick Mode can be used for simple copies.
This distinction matters because Multi Cube should not be used to create heavy dependency between cubes. If data movement becomes too frequent or complex, the architecture can become difficult to manage. A good Multi Cube design should keep data slices mostly independent and minimize data movement between cubes.
Configuration Considerations
Oracle identifies several configuration considerations that customers should evaluate before adopting Multi Cube.
For primary hierarchies, if alternate hierarchies are assigned in additional cubes, the primary hierarchy must also be present.
For dimension security, if cube-specific control is required, organizations should use Cell Level Security.
For scenarios, Oracle notes that all scenarios are present in all cubes, but this can be limited with Cell Level Security.
For approval status, if cube-specific behavior is required, a separate scenario should be used for each cube.
For reports, if reports need to be used in additional cubes, teams should perform “Save As” to create a copy and then point the grids to the new cube.
These are practical design points. Multi Cube should be planned deliberately, not enabled casually.
Cell Level Security and Cube-Level Control
Oracle identifies Cell Level Security as coming soon to FCC. It has already been available in Planning, and it will help define data intersections to restrict read or write access. Oracle also notes that this can be useful where some cube-level security is required. This is important because security expectations often differ by reporting purpose.
For example, management reporting may include detail not intended for all consolidation users. Disclosure cubes may include sensitive notes or supporting data. Constant currency analysis may need different access controls from statutory consolidation. Cell Level Security can help organizations manage this more precisely once available.
When Multi Cube Is a Good Fit
Oracle identifies the main drivers clearly:
- Data slices should be mostly independent
- Data movement between cubes should be minimal
- Resources are shared across cubes, so parallel processing will be no different from a single cube
This is a critical point. Multi Cube is not a shortcut for unlimited parallel processing. It is primarily an architectural design capability for better segmentation, focus and functional separation.
Recommended use cases include:
- Performance improvement
- Segmentation of data to minimize cube size
- Other reporting standards such as local GAAP or IFRS
- Additional detail such as footnotes and disclosures
- Constant currency analysis
- Management reporting
- Functional improvement
- Additional custom dimensions through stacking
These are strong use cases because they benefit from separated data sets and cleaner reporting purpose.
When Multi Cube Is Not Recommended
Oracle also identifies use cases where Multi Cube is not recommended. Historical data is not recommended because Oracle states there is no consolidation performance improvement in that configuration and the application size will still be the same. Archiving data is also not recommended, with the same considerations as historical data and the added logistical complication of resetting opening balances constantly.
This is an important caution. Multi Cube should not be treated as an archive strategy. It should not be used only to move old data out of the main cube. If the objective is historical storage, teams need a different information lifecycle and reporting strategy.
Example Configuration: Statutory, Management and External Reporting
Oracle provides an example configuration using three cubes:
- Consol for financial statements
- Consol2 for management reporting
- Consol3 for external reporting
The example shows financial statements in the main cube, additional detail in other cubes, not all entity hierarchies in the main cube, approvals separated by scenario because the timeframe is unique, and department/product detail stacked to avoid using two custom dimensions. This example is useful because it shows how Multi Cube can support both performance and functional benefits.
A practical version of this model may look like:
- Main cube for legal consolidation and core financial statements
- Additional cube for management reporting with sales or product detail
- Additional cube for footnotes, disclosures or external reporting detail
This approach allows each cube to serve a defined purpose without overloading the main consolidation structure.
Multi Cube Enablement Status and Requirements
Oracle identifies Multi Cube as available in limited release. The configuration option is visible but disabled and will be enabled on a customer-by-customer basis. Customers must log a Service Request with use case details to get access, and fulfillment will follow the same approach as governor updates.
Oracle also notes important requirements:
- Requires a DSO application
- Currently cannot be an EOBP-enabled application, though this is expected to change
- Customers should work with the feature in a test instance
- It should not be enabled immediately in production
- Implementations should not rely on it as a critical feature without evaluation and due diligence first
This is a strong governance message. Multi Cube is powerful, but it requires assessment, testing and controlled adoption.
Practical Multi Cube Readiness Checklist
Before requesting access or enabling Multi Cube, organizations should complete a readiness review.
Key questions include:
- What business problem are we trying to solve?
- Is the use case performance-related, reporting-related or functional?
- Are the data slices mostly independent?
- How much data movement will be required between cubes?
- Which dimensions and members belong in each cube?
- Which reports need to be copied or redesigned?
- Which rules need to be cube-specific?
- Will journals be required in additional cubes?
- What security model is required?
- Are approval processes cube-specific or scenario-specific?
- Is the application DSO-based?
- Is the application currently EOBP-enabled?
- Has the model been validated in test?
- Is the use case strong enough to justify a Service Request?
The strongest Multi Cube implementations will be driven by a clear business architecture, not by technical curiosity.
Business Impact for CFOs, Controllers and EPM Leaders
Multi Cube support can help finance organizations modernize FCC application design in several ways.
Cleaner Consolidation Architecture
Core statutory consolidation can remain focused while other reporting needs move to additional cubes.
Better Performance Design
Data segmentation can reduce unnecessary cube size and support more focused processing.
More Flexible Reporting
Management reporting, external reporting, disclosures and local GAAP requirements can be structured more cleanly.
Stronger Functional Design
Additional custom dimensions through stacking can help organizations manage detailed requirements without overcomplicating the main cube.
Improved Governance
Cube-specific rules, forms, reports, journals and Data Exchange options allow better alignment between data purpose and configuration.
More Disciplined Implementation
Limited release access and test-first guidance encourage customers to validate use cases before production adoption.
How NexInfo Can Help
NexInfo helps organizations evaluate and implement Oracle Financial Consolidation and Close Multi Cube capabilities with a practical focus on architecture, governance, reporting design and performance readiness.
NexInfo’s enterprise delivery model is strengthened by ISO 9001 for Quality Management and ISO 27001 for Information Security, supporting disciplined execution, delivery consistency and secure transformation practices. NexInfo has also received the AI-Enabled Workforce Excellence Award at the 1st Annual Long Beach Business AI Summit, reflecting its focus on applying AI to workforce enablement, enterprise systems and operational transformation.
NexInfo can support organizations with:
- Oracle FCC Multi Cube readiness assessment
- Use case validation for additional Consol cubes
- Main cube and additional cube architecture design
- Dimension and member assignment planning
- Reporting standard separation strategy
- Management reporting cube design
- Disclosure and footnote detail cube planning
- Constant currency analysis design
- Data Copy and Data Exchange strategy
- Report migration and grid reassignment
- Journal and task integration review
- Security and Cell Level Security readiness
- Service Request preparation with use case details
- Test instance enablement and validation
- Production adoption planning and managed support
NexInfo helps finance teams determine whether Multi Cube is the right solution, how it should be designed and how it can be adopted without unnecessary risk.
Conclusion
Oracle Financial Consolidation and Close Multi Cube introduces a more flexible way to design consolidation applications. By enabling additional Consol cubes, organizations can separate focused data sets, support different reporting standards, improve management reporting structures, hold disclosure detail and reduce unnecessary complexity in the main cube.
The capability is especially useful when data slices are mostly independent, data movement between cubes is limited and each cube has a clear business purpose. It is not recommended as a historical archive strategy or as a way to store old data without performance benefit. For finance leaders, the opportunity is to rethink FCC architecture around clarity, performance and reporting purpose.
NexInfo helps organizations evaluate and adopt Oracle FCC Multi Cube with Oracle EPM expertise, ISO-certified delivery governance, AI-enabled transformation experience and a structured implementation approach.
FAQ
What is Oracle FCC Multi Cube?
Oracle FCC Multi Cube allows Financial Consolidation and Close customers to enable additional Consol cubes beyond the main cube. Oracle identifies four additional Consol cubes with predefined names: Consol2, Consol3, Consol4 and Consol5.
Why did Oracle introduce Multi Cube for FCC?
Oracle introduced Multi Cube because FCC historically supported only a single cube, requiring users to combine many features and data combinations within it. As data becomes more sparse, processing can become more complex and performance can decrease.
How many additional Consol cubes are supported?
Oracle identifies support for four additional Consol cubes: Consol2, Consol3, Consol4 and Consol5.
Do additional cubes require application rebuild?
No. Oracle states that additional cubes can be enabled as needed and do not require rebuilding the application.
What does each new cube contain?
Each new cube contains seeded artifacts such as metadata, rules and data forms. It also supports the same application configuration options as the main cube and includes a duplicate copy of exchange rate data.
Are dimension members shared across cubes?
Seeded dimension members are available in all cubes when a cube is created. User-defined members can be assigned to one or more cubes.
What elements are application-wide?
Application-wide elements include approval status, approval groups, dimension security, role security, valid and invalid intersections, application settings, consolidation settings, recommendations, Task Manager templates and schedules, and operational dashboards.
What elements are cube-specific?
Cube-specific elements include dimension members, business rules, consolidation and translation rules, ownership, data forms, reports, Data Exchange, journals, ICM and journals reports, and Task Manager task integrations. Cell Level Security is also identified as coming soon.
How can data move between cubes?
Data can move between cubes using Data Copy or Data Exchange. Data Copy has limited mapping and includes journal entry detail. Data Exchange provides more advanced mapping, while journal data is treated as the value.
What are recommended Multi Cube use cases?
Recommended use cases include performance improvement, segmentation of data to minimize cube size, local GAAP or IFRS reporting, footnotes and disclosures, constant currency analysis, management reporting, functional improvement and additional custom dimensions through stacking.
What use cases are not recommended?
Oracle does not recommend Multi Cube for historical data or archiving data. Historical data does not improve consolidation performance in this configuration, and application size remains the same. Archiving creates similar concerns plus the complication of resetting opening balances.
Is Multi Cube generally available?
Oracle identifies Multi Cube as available in limited release. The configuration option is visible but disabled and will be enabled customer by customer. Customers need to log a Service Request with use case details to request access.
What are the requirements for Multi Cube enablement?
Oracle states that Multi Cube requires a DSO application and currently cannot be used in an EOBP-enabled application, although this is expected to change. Customers should test the feature first and avoid enabling it immediately in production.
How can NexInfo help with Oracle FCC Multi Cube?
NexInfo can help with Multi Cube readiness assessment, cube architecture design, use case validation, dimension planning, report migration, data movement strategy, security readiness, Service Request preparation, test validation and production adoption planning.