Architecting the Single Source of Truth
Nadia Lodroman | Oracle EPM Consultant | Integrity in Every Insight.
Listen to Tresora and Ledgeron's chatting about this blog post:
Unleashing the ‘Has CbCR Scenario’ Attribute in Oracle TRC for Pillar Two
In the current international tax landscape, European tax directors and global EPM architects are facing unprecedented architectural scrutiny. With the EU Minimum Tax Directive and OECD GloBE rules fully operational, the historical divide between corporate finance, statutory tax provisioning, and country-by-country reporting (CbCR) has officially collapsed.
Far too often, implementations fall into what I call the classic "architecture trap": treating Oracle Tax Reporting Cloud (TRC) like a generic EPM Planning application. Unwittingly, teams spin up separate, custom scenarios for Actuals, CbCR, and
Pillar Two, creating disconnected data silos.
This approach introduces catastrophic audit risks and manual maintenance nightmares exactly when tax authorities require total transparency.
To achieve true automation, we must master Oracle’s native, out-of-the-box metadata capabilities. At the absolute center of this structural alignment sits a deceptively simple metadata flag in the Scenario dimension: the
Has CbCR Scenario attribute.
The Anatomy of the Attribute: Under the Hood of the Multi-Cube Architecture
To understand why this attribute is so critical, we must look at how Oracle TRC is engineered. The application relies on distinct underlying Essbase cubes: the Consol cube (housing book accounts, temporary differences, and the core corporate tax provision) and the CbCR cube (built specifically to aggregate Table 1, Table 2, and constituent entity information).
When you select an existing tax provision scenario—such as Actual—and assign the
Has CbCR Scenario custom attribute to CbCR_Scenario_Yes, the platform dynamically provisions a shadow scenario suffixed with _CbCR (e.g., Actual_CbCR) across all cubes.
[ Primary Scenario: Actual ] ---(Has CbCR Scenario = Yes)---> [ Shadow Scenario: Actual_CbCR ]
│ │
(Consol Cube) (CbCR Cube)
• Statutory Provision • Table 1 & Table 2
• FX Rates & Book Data • Inherits Primary FX Rates
This is not a mere naming convention. This native pairing alters the core data-flow engine of TRC:
- Inheritance Without Duplication: The Actual_CbCR scenario automatically inherits book accounts, tax rates, and foreign exchange (FX) rates from its primary parent scenario (Actual). You do not load or maintain a separate set of FX tables for your CbCR data; the system translates CbCR intersections using the foundational rates already locked in by corporate finance.
- Decoupled Process Management: It enables separate data locking and approval workflows. The statutory provision team can sign off on their close, while the global tax compliance team continues to refine, validate, and sign off on CbCR data independently—without risking unexpected shifts in the corporate provision.
When and How to Deploy the Attribute
The decision to activate Has CbCR Scenario must be made early in the design phase. If an organisation already has historical data residing in a single scenario, enabling this attribute requires a data migration process via the Application Configuration screen to safely port historical CbCR intersections over to the new shadow member.
The Implementation Vector:
- Navigate to the Scenario Dimension within the simplified dimension editor or Smart View.
- Select your core provisioning scenario (e.g., Actual).
- Locate the Has CbCR Scenario attribute, map it to CbCR_Scenario_Yes, and refresh the database.
- Run the out-of-the-box CbCR Data Migration job if you are retrofitting an active environment.
Once deployed, data entry and automated rules split cleanly. While your automated provision pipelines continue to run seamlessly in Actual, the CbCR tables are accessed and computed strictly through Actual_CbCR.
The Pillar Two Ripple Effect: Re-Engineering the Automation Workflow
The strategic value of this metadata separation becomes clear when designing the Pillar Two automation workflow. Under OECD GloBE requirements, groups rely extensively on Transitional Safe Harbours (TSH) to avoid grueling top-up tax calculations in low-risk jurisdictions. However, to qualify for the TSH, an MNE must utilize a Qualified CbCR—meaning the numbers must tie back precisely to the consolidated financial statements.
If you have isolated your CbCR data into a separate shadow scenario (Actual_CbCR), your Pillar Two automation sequence must be deliberately adjusted to pull from the correct intersections.
1. Data Sourcing and the CbCR Automation Rule
The Pillar Two engine needs to capture GloBE Income and Covered Taxes. When the Has CbCR Scenario flag is active, you must configure your CbCR Automation rules to push statutory provision data from the Consol cube (Actual) directly into the CbCR cube (Actual_CbCR). This acts as the bridge, ensuring that Table 1 revenue and profit figures are perfectly reconciled with the corporate ledger before Pillar Two looks at them.
2. Calibrating the Safe Harbour Rules
Oracle’s Transitional Safe Harbour forms (covering the De Minimis test, Simplified ETR test, and Routine Profits test) look for CbCR data points. The system must be explicitly instructed to target the Actual_CbCR scenario to evaluate these tests. If your workflow points blindly to Actual, the Safe Harbour calculations will evaluate against empty cells or incomplete data sets, failing the test and triggering unnecessary full GloBE top-up tax calculations.
3. Orchestrating the Consolidation Sequence
Because of this multi-cube dependencies, your EPM Automate close scripts or Task Manager flows must change from a linear process to a structured, multi-phase orchestration:
Step 1: Consolidate & Lock Financials (FCCS)
│
▼
Step 2: Run Tax Provision & Lock "Actual" (TRC Consol Cube)
│
▼
Step 3: Execute CbCR Automation to copy data to "Actual_CbCR"
│
▼
Step 4: Consolidate & Translate CbCR Cube ("Actual_CbCR")
│
▼
Step 5: Execute Pillar Two Safe Harbour & Top-Up Tax Automation
By decoupling the scenarios, you ensure that any late-stage adjustments required to align CbCR data with local statutory filings do not break or trigger a recalculation of the core corporate tax provision.
Designing for Long-Term Auditable Integrity
From an architectural standpoint, the choice is clear. Attempting to build custom script workarounds to manage separate scenarios for provisioning and CbCR is a short-sighted strategy that breaks Oracle’s upgrade paths and native analytical features, such as the CbCR Risk Assessment Dashboards.
Leveraging the native Has CbCR Scenario attribute guarantees that your application honors Oracle's designed data schema. It provides a traceable, auditable data flow from the ERP general ledger, through the statutory tax provision, into the qualified CbCR, and ultimately into the Pillar Two top-up tax calculation. For European multinational groups navigating the intense oversight of tax authorities, this architectural integrity is
no longer a luxury - it is an operational necessity.
Driving the Tax Function Forward
Navigating the complexities of Oracle TRC metadata and aligning your system architecture with Pillar Two requires more than just technical configuration; it demands a strategic vision that bridges corporate finance, tax law, and EPM technology.
If your organisation is looking to optimise its Oracle Tax Reporting Cloud footprint, eliminate architectural silos, or bulletproof its Pillar Two automation workflows for upcoming audit cycles, ensure your implementation is led by expert design.
Reach out to
Nadia Lodroman and the team at www.lodroman.com to discuss how to transform your tax reporting process into a robust, future-proof single source of truth.
Turning financial complexity into operational clarity. Because in Finance, Integrity is Permanent.
General EPM Strategy FAQs
Why should a company use EPM Automate instead of custom scripting
EPM Automate allows for robust, bi-directional data orchestration between Oracle EPM and source ERPs (like NetSuite or Fusion) using native capabilities. It is highly scalable, easier to maintain during Oracle's monthly updates, and avoids the fragility of heavy custom coding.
Can Oracle Cloud EPM integrate with multiple different ERPs simultaneously?
Yes. Through strategic data pipeline architecture, Oracle EPM can ingest, consolidate, and even write-back finalized data to multiple disparate ERPs concurrently, acting as the single source of truth for the enterprise.
How does Oracle FCCS handle Minority Interest (NCI) and CTA?
While standard FCCS provides out-of-the-box functionality, complex global enterprises often require advanced configuration to isolate and calculate Minority Interest (NCI) and Cumulative Translation Adjustments (CTA) accurately at the top consolidated hierarchy without relying on manual journals.
Can you bypass the out-of-the-box Goodwill calculation in Oracle FCCS?
Yes. By utilizing advanced native configuration and custom consolidation rules, you can bypass standard Goodwill Input/Offset functionality to meet highly specific, non-standard acquisition accounting requirements.
How many daily transactions can Oracle ARCS process?
Oracle ARCS is built for enterprise scale. With proper architecture in the Transaction Matching engine, ARCS can easily process and auto-match hundreds of thousands of daily banking transactions, representing billions of dollars in value.
What is the difference between Transaction Matching and Reconciliation Compliance in ARCS?
Transaction Matching automates the high-volume, line-by-line matching of data (like daily bank feeds or ACH). Reconciliation Compliance is used to govern the period-end justification of broader balance sheet account balances.
Does Oracle TRC handle Country-by-Country Reporting (CbCR)?
Yes. Oracle Tax Reporting Cloud (TRC) provides built-in frameworks to automate Country-by-Country Reporting, ensuring multinational organizations remain compliant with global BEPS (Base Erosion and Profit Shifting) regulations.
How does Oracle TRC integrate with FCCS?
TRC and FCCS share the same platform architecture, allowing for seamless data flow. Finalized pre-tax consolidated data from FCCS feeds directly into TRC for tax provisioning, ensuring perfect alignment between the finance and tax departments.
Still have a question?
All things Oracle EPM
