Thursday, 28 May 2026

New enhancement way to clone the EPM Application: Starting from EPM Monthly Patch 26.05

Prior to EPM monthly patch 26.05cloning of any EPM application was limited to using backup snapshots or the Artifact snapshot as the source. There was not much flexibility provided by Oracle. From EPM Monthly patch 26.05, administration has got flexibility to specify an Environment Backup as the source when cloning an environment, providing a more efficient and reliable way to replicate the environments for disaster recovery or production-to-test migration.

EPM Automate command :  cloneEnvironment 

Clones the current environment and, optionally, identity domain artifacts (users and application role assignments), Data Management records, audit records, Job Console records, application properties, contents of the inbox and outbox, and stored snapshots. 

This command is an alternative to using the Clone Environment feature.

Syntax -

epmAutomate cloneEnvironment TARGET_USERNAME TARGET_PASSWORD TARGET_URL [SnapshotName=NAME] [environmentBackup=NAME] [UsersAndPredefinedRoles=true|false] [DataManagement=true|false] [appAudit=true|false] [jobConsole=true|false] [storedSnapshotsAndFiles=true|false] [DailyMaintenanceStartTime=true|false] [ApplicationProperties=true|false]

Examples:

  • Clone the environment, users and application role assignments, audit data, job console records, and Data Management records using an environment backup. Also change the maintenance start time of the target environment to that of the source environment:

    epmAutomate cloneEnvironment serviceAdmin Password.epw https://test-cloudpln.pbcs.us1.oraclecloud.com environmentBackup=2026-03-11T16:30:37/Environment_Backup UsersAndPredefinedRoles=true

  • Clone the environment, users and application role assignments, audit data, job console records, and Data Management records using a specific backup snapshot. Also change the maintenance start time of the target environment to that of the source environment:

    epmAutomate cloneEnvironment serviceAdmin Password.epw https://test-cloudpln.pbcs.us1.oraclecloud.com SnapshotName=2026-03-11T16:34:52/Artifact_Snapshot UsersAndPreDefinedRoles=true

  • Clone the environment including the contents of inbox and outbox, stored snapshots, but not the users and application role assignments, Data Management records, audit data, and Job Console records using the last artifact snapshot, without changing the maintenance start time of the target environment:

    epmAutomate cloneEnvironment serviceAdmin Password.epw https://test-cloudpln.pbcs.us1.oraclecloud.com DataManagement=false appAudit=false jobConsole=false storedSnapshotsAndFiles=true DailyMaintenanceStartTime=false

Applies to:   

ARCS, EDM, FCCS, Freeform, NRCS ,TRCS, Planning applications and Enterprise Profitability and Cost Management,

Business Benefit: 

This new option provides a more efficient and reliable way to replicate the environments for disaster recovery or production-to-test migration.

Thank you!

Wednesday, 27 May 2026

The Journey of Oracle ARCS: How Automation and AI Rewrote Account Reconciliation

 Account reconciliation has historically been one of the most labor-intensive phases of the corporate financial close cycle. For decades, corporate accounting teams were trapped in a cycle of manual data extraction, disparate spreadsheets, and fragmented audit trails. This reality exposed organizations to significant operational risk, compliance bottlenecks, and delayed financial reporting.

The evolution of enterprise technology has fundamentally altered this paradigm. At the forefront of this shift is Oracle Account Reconciliation Cloud Service (ARCS). Over the past two decades, this solution has transformed from a rigid, infrastructure-heavy on-premises tool into an agile, cloud-native suite, and ultimately into an autonomous, AI-driven framework.

1. The Legacy Era: Hyperion ARM and On-Premises Constraints

Before the maturity of cloud computing, enterprise reconciliation was primarily managed via legacy systems. Oracle’s flagship offering in this space was Hyperion Account Reconciliation Manager (ARM), deployed as an on-premises module within the broader Hyperion Financial Close Management ecosystem.

While Hyperion ARM successfully digitized the foundational workflow of reconciliation—establishing formal paths for preparers and reviewers—it presented clear operational limitations:

  • High Infrastructure Overhead: On-premises deployments required substantial capital expenditure for server maintenance, database administration, and iterative, disruptive upgrade cycles.

  • Rigid Customization: Creating transaction matching rules or complex data integrations required extensive IT support and specialized script writing, often utilizing Visual Basic (VB) or database procedures.

  • Siloed Data Architecture: Data extraction from external General Ledgers (GL) or sub-ledgers relied on batch processing and flat-file transfers, introducing latency into the close window.

2. The Cloud Paradigm Shift (2016–2017)

Recognizing the limitations of localized infrastructure, Oracle officially launched Account Reconciliation Cloud Service (ARCS) as a standalone Software-as-a-Service (SaaS) solution. This pivot to the cloud dismantled the infrastructure barriers that had long hampered corporate accounting teams.

The introduction of ARCS brought two distinct architectural improvements to the market:

  1. Reconciliation Compliance (RC): A web-based compliance engine that centralized the monitoring, reporting, and auditing of account reconciliations globally.

  2. Transaction Matching (TM): A high-performance engine capable of ingestion and automated matching of high-volume transaction data (e.g., millions of point-of-sale entries against bank statements).

By shifting to a graphical user interface (GUI) and configuration-driven logic, Oracle empowered finance users to build their own matching rules, formats, and workflows independently of corporate IT departments.

3. Consolidation into the Unified EPM Cloud Suite (2019–2021)

As cloud ecosystems matured, the market demanded deeper interoperability. Oracle responded by absorbing ARCS into its comprehensive, unified Oracle Cloud EPM (Enterprise Performance Management) platform.

This consolidation transformed account reconciliation from an isolated monthly chore into a continuous business process. Native integration within the EPM suite allowed ARCS to communicate directly with Oracle Financial Consolidation and Close (FCCS) and broader ERP ledgers. Data flows became automated, giving close managers real-time visibility into reconciliation statuses, variance analysis, and balance sheet integrity directly from centralized corporate dashboards.

4. The AI and Machine Learning Frontier: Achieving the Touchless Close

Today, Oracle ARCS represents the cutting edge of financial technology, utilizing embedded Artificial Intelligence (AI) and Machine Learning (ML) algorithms. The software has transitioned from a system that merely tracks manual accounting activities to an intelligent framework that executes them.

Modern AI capabilities have re-engineered the reconciliation workflow across three primary vectors:

1. Raw Transaction Data

2. Intelligent Auto-Match Engine (Complex many-to-many ML matching)

3. Continuous Anomaly Detection (Real-time variance identification)

4. Risk-Based Auto-Certification (System-generated audit trails)


Intelligent Transaction Auto-Suggest

Traditional rules-based matching engines fail when encountering complex data anomalies—such as timing differences, currency fluctuations, or fragmented vendor descriptions. Historically, these exceptions fell into manual queues, requiring accountants to hunt down matching lines across spreadsheets.

The integrated ML engine analyzes historical matching patterns and human corrective actions over time. When a data anomaly occurs, the system calculates a statistical confidence score and automatically suggestsmatches to the user. This turns a tedious search-and-verify task into a simple, single-click approval process.

Continuous Anomaly and Variance Detection

Rather than waiting for the close cycle to begin to identify ledger discrepancies, ARCS now utilizes background AI algorithms that scan active data pipelines continuously. By establishing a baseline of historical trends and transaction behaviors, the system flags unusual variances, duplicate billings, or suspicious ledger postings in real time. This allows accounting departments to remediate errors prior to the high-pressure period-end close window.

Automated Risk-Based Certifications

A significant portion of a finance team's time during a close cycle is spent verifying low-risk, low-activity, or zero-balance accounts. Oracle ARCS leverages AI to execute automated, risk-based certifications. If an account meets specific low-risk operational thresholds and data validation rules, the AI signs off on the compliance documentation, generates the necessary audit trail, and archives the file. This filters out the operational noise, allowing senior accountants to focus exclusively on complex, high-risk variances.

Looking Forward: The Future of Financial Integrity

The evolutionary path of Oracle ARCS mirrors the broader digital transformation of the corporate finance function. By migrating from the manual constraints of Hyperion on-premises to a cloud-native environment, and ultimately incorporating advanced AI and Machine Learning, Oracle has fundamentally changed how corporations view risk and financial data validation.

The ultimate objective of this journey is the realization of a continuous, touchless financial close. Through persistent AI oversight, automated data harmonization, and self-learning matching logic, Oracle ARCS ensures that financial data integrity is maintained continuously throughout the fiscal period—not just during the first week of the month. For enterprise organizations, this translates to reduced compliance risks, minimized operational costs, and the transformation of the accounting function from historical bookkeepers into strategic, data-driven business partners.

Thank you!

Beyond the Numbers: The Evolution and AI Transformation of Narrative Reporting

For decades, the standard metric of corporate performance was raw data. Balance sheets, cash flow statements, and income disclosures formed the foundation of market trust. However, numbers in isolation rarely tell the whole story.

Today, corporate reporting has shifted toward narrative reporting—the strategic integration of financial data with operational insights, market context, governance, and sustainability goals. It answers not just what happened, but why it happened, what it means, and where the enterprise is heading.

As stakeholders demand machine-readable structures alongside clear human narratives, the discipline faces another critical shift. The following analysis traces the history of this professional discipline and examines how Artificial Intelligence (AI) is transforming it.

The Journey of Narrative Reporting: From Appendix to Center Stage

The evolution of narrative reporting can be categorized into four distinct eras:

1. The Compliance Era (Traditional PDFs)

2. The Stakeholder Era (Integrated ESG Focus)

3 The Digital Architecture Era (Structured Tags (XBRL))

4. The Intelligent Reporting Era (Gen AI & Agentic Workflows)

1. The Compliance Era: Traditional Data Dumping

Historically, narrative reporting was treated as a regulatory checkbox. Annual reports consisted of backward-looking financial tables paired with rigid, boilerplate Director's Reports. The narrative was secondary, heavily curated by legal teams, and provided minimal insight into actual day-to-day business drivers or long-term risk mitigation.

2. The Stakeholder Era: The Push for "Integrated Reporting"

The early 2010s brought a realization: traditional accounting metrics failed to capture intangible value, such as intellectual property, corporate governance, and societal impact. This drove the adoption of Integrated Reporting () and environmental, social, and governance (ESG) frameworks. The "front half" of the annual report grew to equal the "back half," changing reporting into an ongoing narrative of holistic value creation.

3. The Digital Architecture Era: Machine-Readability

Regulators globally began requiring that public narratives be translated into standardized formats. Frameworks like the International Sustainability Standards Board (ISSB) and European Sustainability Reporting Standards (ESRS) converged into a global baseline. Meanwhile, bodies like the UK Financial Reporting Council (FRC) and the SEC mandated structured digital reporting using technologies like Inline XBRL (eXtensible Business Reporting Language), ensuring narratives could be cross-referenced and analyzed programmatically.

4. The Intelligent Reporting Era (Present Day)

The current landscape has shifted from static, multi-authored PDFs to dynamic, interactive reporting ecosystems. Corporate performance is no longer communicated in a single annual document, but through connected data environments that update dynamically and are built for both human review and automated analysis.

The Role of AI in Modern Narrative Reporting

AI is no longer just an experimental tool; it functions as core infrastructure within Enterprise Performance Management (EPM) and disclosure software. Modern enterprise systems (such as Oracle Cloud EPM and Anaplan) embed artificial intelligence directly into the reporting loop, altering how reports are produced and consumed.

AI applications generally fall into two primary areas:

1. The Production Side (Creating the Report)

  • Contextual Variance Commentary: Rather than finance teams spending days manually investigating discrepancies, Generative AI monitors financial grids. When a data intersection breaks a specific threshold, GenAI evaluates the point-of-view data, cross-references historical notes, and drafts real-time, natural-language commentary explaining the root cause of the variance.

  • Automated Alignment & Consistency Checks: Multi-author reports are prone to internal contradictions. AI models audit entire document packages to ensure a metric cited in the initial executive summary precisely aligns with detailed data tables located deeper within the disclosures.

  • Nested Tagging & Regulatory Compliance: AI assists compliance teams by recommending specific regulatory tags (such as financial or thematic ESG markers) across complex text blocks. This ensures the output satisfies regulatory standards for machine-readability.

2. The Consumption Side (How the Market Reads the Report)

The audience for narrative reporting has changed. Institutional investors, analysts, and rating agencies increasingly rely on custom AI agents to read, query, and summarize corporate reports rather than reviewing them manually.

  • Conversational Querying: Institutional stakeholders deploy conversational interfaces over parsed filings, allowing them to ask natural-language questions like: "What specific supply chain risks did management highlight in Q3, and how do they contradict the margin outlook?"

  • Localization and Synthesis: Advanced translation algorithms dynamically adjust narratives for local regulatory environments, while semantic search tools instantly evaluate the strength of a company’s strategic claims against actual performance data.

Balancing Innovation with Governance

While AI streamlines drafting, structural formatting, and initial analysis, it does not replace executive accountability. Present corporate strategies focus heavily on implementing robust human-in-the-loop validation frameworks. Because narrative disclosures carry significant regulatory weight, AI serves primarily as an analytical drafting partner—allowing human professionals to focus less on manual aggregation and more on clear strategic communication.

Ultimately, companies that combine clean, structured, machine-readable financial data with strategic, human-verified narratives will gain a distinct edge in investor relations and market credibility.


Thank you!

Sunday, 17 May 2026

Significance of Supplemental Data Manager – Additional Help for Finance Users

 Supplemental Data

Supplemental Data means accounting supplemental records. The detailed information utmost required for accounting but is outside the scope of typical accounting, like postings in general ledger, etc. Data sitting in these records is typically additional required information which helps management and analysts perform their jobs.


                            

Using the right systems for supplemental data collection and management can gain greater control and visibility into additional information, in comparison to using manual and spreadsheet-based financial processes.

Supplementary Information May Include:

• Accounting information

• Non-accounting information

Accounting Information

• An example of supplementary information is an expanded table containing the details for line items in the financials.

• Supplementary information system is valuable for any company, allowing them to provide important additional information—such as “roll forward” reports, debt roll forwards, fixed asset roll forwards, and equity roll forwards, which are necessary to support financial statements.

Non-Accounting Information

• An employee in charge of accounts receivable might keep a supplementary record with notes about customer demeanor, personality, and ability to pay future invoices. This extra information helps the employee perform their job by giving additional warnings about controls or customers which might need additional attention.

Methods to Collect Supplemental Data

There can be two methods to collect supplemental data. Supplemental data can be collected in single source system where master data is stored or in separate systems.

                                                    

Collection of Data in Single Source System

Supplemental data can be stored in single source system where master data is stored

For example: In any ERP system (e.g., PeopleSoft or JD Edwards, etc.) or any of Oracle EPM Cloud Close suites.

Oracle EPM Cloud Close suite (Financial Consolidation and Close Cloud services (FCCS), Account reconciliation Cloud services (ARCS) and Tax Reporting Cloud services (TRCS) supports Consolidated data as well Supplemental data into a single system.

Benefits of Collecting Supplemental Data in Single Source System like SDM of FCCS

● It provides greater flexibility for reporting purposes

● Cost effective solution

● Administrator needs to maintain a single system

● Improved performance

                


Collection of Data in Separate Systems

Supplemental data can be stored in a separate system than the master source system. It can be MS Excel/File system/Database tables, etc.

Impacts of Maintaining Data in Multiple Systems

1. Collecting data in multiple systems can impact reporting capabilities.
2. System administrator will have to maintain multiple different systems.
3. When the master source system does not support inbuilt supplemental data collection and system admin still have to store supplemental data into master system, the size of master system will increase which might impact performance.

            

Supplemental Data Manager: An Untapped Gem of Close Consolidation

Oracle EPM cloud close consolidation suite (FCCS, ARCS and TRCS) have an inbuilt supplemental data collection tool named “Supplemental Data Manager” (SDM).

EPM cloud close consolidation suite supports consolidation, account reconciliation, and tax reporting for controllership users. Not only this, using SDM functionality of Oracle Cloud, supplemental data can be stored in EPM.
Summary/aggregated data will be available in FCCS/ARCS/TRCS whereas additional/detailed supporting information will be stored in SDM.

Supplemental Data in Financial Consolidation and Close Cloud Services (FCCS)

Oracle Financial Consolidation and Close Cloud Service (FCCS) is a suite of:

                

Oracle Supplemental Data Manager (SDM) is a platform that can be used to centralize the collection of financial, textual, and other unstructured data. It helps organizations to streamline the supplemental data collection process and introduces visibility as well as efficiency into the process.

SDM Provides a Robust Ad Hoc Data Collection Process That Supports:

• Defining the data definition process and associated data forms for data collection
• Provides a complete security mechanism on data
• Supports the ability to create calculation formula and validation criteria
• Control and monitor the data collection workflow

Examples of Use of SDM
                                
                                


How to Enable Supplemental Data Manager in FCCS

To collect supplemental data within FCCS, supplemental data collection module needs to be enabled while creating FCCS application. As shown in below screenshot of “Enable Features” while creating FCCS application, FCCS provides below options –

                

1. Enable both “Consolidation” and “Supplemental Data Collection” option to store both consolidated and supplemental data
2. Enable “Consolidation” option to store consolidated data only
3. Enable “Supplemental Data Collection” option to store supplemental data only
Note – If an FCCS application has been created without enabling the SDM, it can be enabled later as well.

Collection of Supplemental Data in FCCS – Investment Details

An organization makes a couple of investments. For each investment, the company needs to store additional information as well. Detailed information of investments will be collected as supplemental data whereas Invested amount will be part of the company's Financial Statements.

FCCS the Game Changer
Based on requirements – FCCS will keep only the aggregated invested amount for financial statements, whereas other detailed information will be kept in S    DM.
Detailed Investment information to be collected can be divided into 4 different sections –
1. General Information
2. Investment Information
3. Investment Details
4. Investment Value

    


Steps to Set Up SDM in FCCS
Below are the eight steps to set up Supplemental Data Manager in FCCS.
  


Step 1 - Study Existing Process

Study the existing user input templates to:
● Identify all attributes/parameters for which data needs to be collected?
● Is there any need to create an additional dimension or attribute?
● Any validation logic required?
● Any calculation required?
● How SDM Input Form will be organized?
● User/Team details who will input data into SDM Forms?
● How to set up the Workflow process?
● Security setup details required?

Step 2 - Create the Additional Dimension/Attributes to Record Information

In addition to FCCS inbuilt dimensions, additional dimensions can be created to store supplemental information. Each Dimension can have further members under it. Metadata will be loaded for these members.
For example, In following screenshot “Account” is a FCCS seeded dimension, whereas “Moodys Ratings” is a custom dimension to store additional information.



Below two custom dimensions will be created to store investment details.
1. ‘Moodys Rating’
2. ‘SP Rating’
Following are the members and properties for each dimension.
    


Step 3 - Define the Data Set

• A data set consists of all attributes, required to record data.
• Under Data Set, new Attributes can be created.
• It consists of Attributes from dimensions (FCCS seeded dimension or custom dimension) and Attributes created in the data set.

            

• Once the Data Set has been defined, it will be used to create SDM Forms.

As shown in below screenshot – add all Attributes under the “Investment Details”.



Step 4 - Create Form Template

Form Template is created based on ‘Data Set’ and is a reusable component. To Create a Form Template:
• Define the layout of user input forms.
• Define mapping between FCCS and SDM and using that data will flow from SDM to FCCS.
• Define instructions to be followed by the user while entering data.
• Define the Workflow process.
• Define the security setup.
• Define the Users/Team who will be responsible to input data in SDM form for specific Entity.

Create New Section under Form Template

As per requirement, there will be four sections to collect Investment details:
Under each section, there are three tabs:
1. Columns
2. Group By
3. Mapping

Columns Tab
Choose the attributes which need to be added under the ‘Investment detail’ section from “Data Set” “Investment Details”.

• Select the checkbox “Included” for all items required in “Investment Value” section out of the entire Attributes of Data Set “Investment Details”.
• Select the checkbox “View only” if any column needs to be marked as view only.
• For all columns where ‘Data Type’ is Number, you can define the ‘Total Validation POV’.
• For example - If aggregated investment amount is available in FCCS and using SDM, detailed information is getting submitted, SDM Data can be validated against the data stored in FCCS.
• A mapping needs to be defined between FCCS and SDM members for ‘Total Validation POV’.



Group By Tab

● In “Group By” page – it will show only those columns which were selected as “Included” in “Column tab”.
● Select the “Included” check box for which data needs to be sent to FCCS.
● Select the “Group By” check box against which data needs to be aggregated in SDM and sent to FCCS.
● Select the “Included” check box for which data needs to be sent to FCCS.
● Select the “Group By” check box against which data needs to be aggregated in SDM and sent to FCCS.
For example – In screenshot – SDM will aggregate data against “Investment ID” for “Current Value”, “Book value”, “Unrealized Loss”, “Market Value” and “Fair Value” columns and send from SDM to FCCS.    

    


Mapping Tab
In Mapping Tab, mapping between SDM and FCCS is defined.

To define mapping, click on POV - it will open a new window to select the specific member from each FCCS dimension.
    

As shown in the above screenshot - we can see the specific member from FCCS dimension.
As a result of this mapping - Value of “Book Value” entered by user will map to, “Investment Details” account of FCCS.

Click OK.

Click on “Save Button” to complete all tasks related to Section Tab and return to “Form Template”.
Once Section has been defined, the next import task under ‘Form Template’ is to define the workflow process for SDM forms. Go to the ‘Workflow’ tab.

Workflow Tab

Define the workflow process of SDM input form. Below are different available options.

    
● There can be multiple approval levels.
● Once, SDM form will be in Posted status – Data will be moved from SDM to FCCS.
● Based on the selected workflow option, preparer, approver, and integrator need to be defined.
● Post deployment of template, preparer, approver, and integrator who has been defined in Workflow, will be able to perform specific tasks in SDM Input form for Entities that has been defined in Workflow.

Step 5 - Open the Period for Data Collection
To start supplemental data collection process:
• Make sure the period is open for the month in which data is to be loaded.

Step 6 - Deployment the Form Template
Once the form template has been created, the next step is to deploy the template.

Step 7 - Data Submission to Input for Using workflow
Once SDM forms have been deployed, it will undergo the workflow process.
It will have three stages below:
1. Preparer
2. Approver
3. Integrator

Preparer Related Task

Once the SDM form has been assigned to the preparer, the preparer needs to enter the data and submit data to approver for approval.
For our example, there are four different tabs under “Investment details” where the preparer needs to enter data.



Enter the details and click the ‘Save’ button. Similar to this, the preparer need to enter details in all four forms.
Once all data has been entered into four different forms, the preparer needs to “Submit” control from “Preparer” to “Approver” stage.

Approver Related Task
• Once the preparer will submit the data, control will move to “Approver”.
• Approver has the option to “Approve” or “Reject” this data.
• On Rejection – control will go back to the preparer.
• On Approval – control will move to next level (i.e., Integrator).
• Once approver clicks the ‘Approve’ button, control will move to the integrator.

Integrator Related Task
• Once control moves to the integrator, the integrator can post or reject it.
• Once it has been posted, data will be moved from SDM to FCCS.

Viewing Data in FCCS
• As “Book Value” was mapped with the “Investment details” member in FCCS.
At the below member combination, data can be seen in FCCS.
• SDM data will be loaded on the “Supplemental Data” member from the “Data Source” dimension in FCCS.


Drill through from FCCS to SDM

• FCCS will hold summary data and detail data will be available in SDM.
• To see detailed data from FCCS, the drill-through option can be used.
• It is supported via Smart View and FCCS Web Forms.
• In Web Form - right click on the data cell for account “Investment Details”-> ‘C_101” and select Drill Through.
• On the next window, all four input forms will appear.


The screen of SDM below will appear where we can see all four input forms.


Step 8 - Close the Data Collection Period
Once Supplemental data has been posted, close the data collection period.
Powerful SDM Features Provided by FCCS
With the implementation of FCCS, any organization can have a centralized system to store financial data as well as the supplemental data.

Supplemental Data Manager Security
SDM provides a robust security model. While defining the SDM “Form template”, Admin needs to set up the SDM workflow.


Admin needs to define who will be the preparer, approver, and integrator for each entity for which SDM data need to be loaded.

Post deployment of Template – Only preparer, approver, and integrator who has been defined in Workflow will be able to perform specific tasks in SDM Input form for that particular Entity.

SDM allows users to define Teams instead of individual preparer, approver, and integrator. Teams specifically for supplemental data, for example, for working on supplemental data forms
can be created. You can then determine which users or teams can claim a form, and from Access, you can assign teams for workflow stages.

Based on assigned access – multiple users can enter data to their respective assigned SDM Input form at same time.

For SDM Input form – only specific users who have given access “Form Template” under “Access Tab” can view the data.

Based on dimension level security defined in FCCS, users will be able to see data for specific members in FCCS.

Data Flow from Supplemental Data Manager to FCCS
Once data has been approved and posted by the integrator, data will be moved from SDM to FCCS application.
At below combinations, data will be available in FCCS:
● “Supplemental Data” member from “Data Source” dimension
● Year, period, scenario, and entity will be picked from SDM input form.
● For other dimensions, data will be available on member-defined in the mapping session.

Data will be available on the same combination which has been defined under the “Mapping” section. For example, as per the screenshot below, data will be available on “Investment Details” Account.



Supplemental Data Management Dashboard

FCCS provides inbuilt Dashboard to monitor the progress on SDM input forms. You can monitor the business process and supplemental data information using below types of dashboards.
1. Task
2. Compliance
3. Financial dashboards


Benefit of Supplemental Data Management

A Single Interface
Both consolidated and supplemental data can be stored from a single interface of Oracle EPM Financial Consolidation and Close services (FCCS).

Flexible Reporting Capabilities
As both consolidated data and supplemental data is available at the same interface, it provides great flexibility to report both types of data.
Summary/aggregated data will be available in FCCS whereas additional/detailed supporting information will be stored in SDM.
FCCS allows drill through from FCCS to SDM to see detail-level information.

Cost Effective Solution
Storing both consolidated data and supplemental data into a single interface is a cost effective solution for any organization. Administrator needs to maintain a single system. FCCS supports SaaS architecture.

Improved Performance
Instead of maintaining information in multiple sources for consolidated data and supplemental data, having a single source reduced the end to end consolidation cycle time and improved performance.
Security
FCCS/SDM provides a robust security model. For the SDM input form, only specific users who have been assigned any task (preparer, approver, and integrator) or given access “Form Template” under “Access Tab” can view the data.
Based on dimension level security defined in FCCS, users will be able to see data for specific members in FCCS.

Easy User Interface
FCCS provides great flexibility to load supplementary data into SDM input form. Users can use Smart View (Excel), load data file (.CSV format), and use a web interface.
FCCS provides different types of Dashboards to see the status of SDM input forms.

SDM Workflow
Using workflow, it can easily track the status of any task. The administrator or power user sends email alerts to assigned users for their related data forms.

Thank you!

Oracle EPM FCCS: Financial Task Manager

Problem Statement


Manual tracking of the close process, using excel and e-mails is one of the reasons companies still experience issues in their close process from an accuracy, transparency, complexity and comprehensiveness perspective.

By standardizing and embedding controls in period-end close processes, organizations can eliminate labor-intensive, non-value adding activities and streamline decentralized and disjointed workflows that lengthen cycle times, increase the risk of control failure, and threaten the integrity of financial statements.

However, you don’t need to spend countless hours on how to close the books in Real time! 

This article will guide you through how Financial Task Manager is a pathway to Streamline and Accelerate Your Close Operations and best practices you need for a successful journey to EPM Closing and Reporting.

What is Financial Close Cycle


Financial Close Cycle indicates the number of business days required to close the books of accounts and submit finalized financial reports to the management and regulatory authorities at the end of the accounting period. It can be monthly/quarterly/yearly from the time that financial data gathering begins, until management and any regulatory authorities receive finalized financial reports.


Close challenges 


  • Inconsistent closing calendar and checklist 

  • Lack of quality data from upstream processes or ineffective data aggregation activities

  • Lack of automated close processes (e.g., high level of manual journal entries) 

  • Ineffective procedures for validating results 

  • Lack of timely hard close of periods and ability to post transactions after reporting package submission

  • Intercompany accounting – manual adjustments


Organizations are finding it difficult to track:

  • The current status of close

  • Number of open tasks?

  • Where is it stuck?

  • Is there any issue in closing the task? 

  • Who all are assigned to close tasks?

  • Is the predecessor/successor tasks followed?

  • Is any assigned employee on Leave?

  • Do they need some backup for assigned employee?

  • There is no workflow to monitor?

  • Approval mechanism in place?

  • Looking for email notification for current status?

  • Availability of backups?

Task Manager

Oracle Financial Task Manager module of FCCS is built for centralized, web-based management of period-end close activities across the extended financial close cycle.

It helps to manage all financial close cycle tasks, including ledger and sub ledger close, data loading and mapping, financial consolidation, account reconciliation, tax/treasury and internal and external reporting processes.

This includes:

  • Close Manager Components (Setup Calendar, Security, Periods, Years, Custom Attributes, Alert Types, Integrations)

  • Define Tasks for a Close Process - setup Task Types

  • Define Dashboard Views (Calendar, Task List, Gantt Chart)

  • Create / Update Templates (and validate) with repeatable close tasks

  • Setup / Update Schedule by pulling from a template

  • Workflow process


Thank you!

Created by Mohit Jain & Megha Gupta

New enhancement way to clone the EPM Application: Starting from EPM Monthly Patch 26.05

Prior to EPM monthly patch 26.05 ,  cloning of any EPM application was limited to using backup snapshots or the Artifact snapshot as the sou...