Multi-calendar reporting is a common Financial Reporting requirement where the fiscal year ends for submitting entities are different than the consolidated group or intermediary sub-group fiscal year end. For example, the consolidated group fiscal year end could be December 31 while some submitting entities or intermediary sub-groups have a March 31 or June 30 fiscal year end.
Multiple fiscal year ends often arise for organizations that are highly acquisitive (mergers, acquisition, divestures) or geographically dispersed (e.g., for tax efficiency purposes).
Multi-calendar reporting is not an Out-Of-The-Box (OOTB) feature for Oracle Financial Consolidation and Close (FCC) nor most financial consolidation platforms for that matter, in this article, we will cover how you are able to achieve this in FCC with the proper configuration and set up.
The following is a high-level summary of how we were able to set this up for one of our clients.
This organization had a complex ownership structure with majority of submitting entities having a fiscal year end of December 31 (Dec YE), same as the consolidated group fiscal year end. However, a subset of the submitting entities operated on a March 31 fiscal year end (Mar YE). Due to regulatory and management reporting requirements, the client had to report the overall consolidated financial results in both December 31 and March 31 fiscal year ends. This created the following challenges:
- Reporting in both “Dec YE” and “Mar YE” regardless of the month a particular submitting entity closed their books.
- Reports needed to display the proper year and reporting period based on the applicable fiscal calendar selected.
- The solution needs to handle situations where the submitting entity changed their fiscal year end. Prior to roll out of FCC, this was all being managed through spreadsheets.
- Retained Earning and intercompany eliminations need to be computed properly for each reporting fiscal year end.
Oracle FCC was configured to handle the above requirements as follows:
- Within the Scenario Dimension, we created a “Dec YE” and “Mar YE” scenario.
- All submitting entities were tagged as either “Dec YE” or “Mar YE”.
- Financial data for submitting entities were loaded according to their fiscal year ends (e.g., Entities with December 31 year end loaded to the scenario “Dec YE” and entities with March 31 year end loaded to the scenario “Mar YE”).
- Developed custom rules to transform the loaded data to “Dec YE” or “Mar YE” based on the entity tagging.
- Period members within FCC were set up as P01 to P12 as opposed to the calendar months (e.g., Jan to Dec) to facilitate multi-calendar reporting. For example, “Dec YE” Period 1 would be January while “Mar YE” Period1 would be April.
- To handle entities that change their reporting from one to another, the tagging of that entity and load would be changed. For example, if an entity was changing from “Dec YE” to “Mar YE”, the entity tagging would be updated from “Dec YE” to “Mar YE” and would load financial data to the scenario “Mar YE” instead of “Dec YE”.
Our custom configuration and setup:
- Eliminated the need to create both “Dec YE” and “Mar YE” G/L data – the submitting entities would simply load their G/L in their local fiscal calendar format and allow FCC to convert the data into both reporting fiscal year ends (including proper handling of intercompany eliminations and retained earnings roll forward computations).
- Client was able to readily toggle / convert calendar types for the submitting entities as required. Beyond the necessary top-side adjustments determined by Finance and Accounting, the underlying computations to handle the change in fiscal year end would be handled by FCC.
- Can easily change the fiscal year end of an entity by changing the entity’s fiscal year tagging without any changes to the underlying business logic.
- Provided stronger auditability of data and less prone to human errors (e.g., eliminated the reliance on spreadsheets)
- A full set of Financial Statements could be generated out of FCC for any entity (submitting, intermediary and consolidated) in both calendars.
Overall, an effective solution design should always take into account not just the technical feasibility, but also usability for end-users. If the set up is too complex, onerous to maintain, or requires incremental effort to ensure data integrity, the solution will not be readily adopted by Finance and Accounting.