Solvay IFRS reporting is organized per legal companies (one reporting package per legal company) reporting their Financial Statements (P&L, Balance Sheet and Cash Flow Statement) on a monthly basis. To allow Businesses to get their Financial results, each legal company will in addition split its results on Business dimensions.
The following items of Financial Statements require an allocation per Business:
It means that Group IFRS Consolidated results can be obtained as sum of legal companies and as sum of Businesses.
This IFRS reporting per Businesses is used by both Businesses and Corporate Controlling teams to prepare the analysis of Solvay Businesses performance included in both Financial press releases every quarter and Annual report.
To be noted that Business structures are also used in Controlling reporting categories (RSB and PREV).
Business structures are organized around 5 levels aggregating each others in a global hierarchy (following a "Russian dolls" principle - 1 level can belong to only one upper level and never two):
![]()
![]()
5th and last level combines 2 different dimensions : MARK "Activity1" and CGU "Activity2"
![]()
![]()
Process of Business structures updates is organized yearly through a "3 steps / waves" cycle
Best practice is to start in Q3 Y the identification and setup of Business structures changes expected for Go Live Jan 1st Y+1
Wave 1 - October Y: 1st set of expected changes needed for Budget (Controlling cycle)
Wave 2 - December Y : 2nd set of changes (late answers from GBU's) / Creation of New objects in BFC
Wave 3 - end of January Y+1 : Activation/Deactivation in BFC for Y+1 reportings
Any change of Business structures out of this yearly cycle (i.e. during the year) is technically feasible in BFC structures and ERP Master data tables. However never recommended as restatement of past months (since Jan 1st Y+1) is a heavy exercise in ERP's
The following actors are involved:


Timing : Wave 2 - December Y
Sequence of creation: From upper levels to lower ones

Connect to BFC_Top:
Select the “Dimension Builder” module in the "Setup" domain.
Then select the MARK and CGU dimensions and expand the hierarchy to access to the upper levels.

A CGU can be created from scratch in the option "New Reference Member", or through “Save As” from an existing CGU code.


In the tabs “General” and "Translation", enter the information in the following fields as indicated in the Reference file:


In the tab “Properties”,



A MARK "Activity 1" can be created from scratch in the option "New Reference Member", or through “Save As” from an existing MARK code.

![]()
In the tabs “General” and "Translation", enter the information in the following fields as indicated in the Reference file:


In the tab “Properties”,




Special case of 1 CGU transferred and split into 2 or more CGUs: In the corresponding "new" MARK codes we can assign only one CGU.
Example: In 2022, TSDP and TSFU were transferred from TSDPH to TSMIN BU. Corresponding CGU associated to both TSDP and TSFU was split into 2 "new" CGUs. Business must choose which CGU should be assigned to TSDP and TSFU replacing the old CGU.


A BU can be created from scratch in the option "New Reference Member", or through “Save As” from an existing BU code.
Note that it can be created either using the MARK or the CGU hierarchy (no need to create twice in each as 1 single BU table common to both hierarchies).
Note: No need on BU level to manage the specific f characteristics existing on MARK and CGU (change, RSB transfer, value for margin in inventories...) as BU level is not used for data entry but only for retrieval purposes.

In the tabs “General” and "Translation", enter the information in the following fields as indicated in the Reference file:
![]()

In the tab “Properties”,


Customizing principles are the same than the ones described for the BU "Business Unit" level.
Note that those levels can be created either using the MARK or the CGU hierarchy (no need to create twice in each as single tables for each GBU SEGMOP and CLUSTER levels common to both hierarchies).
Note: As on BU level, no need on those levels to manage the specific characteristics existing on MARK and CGU (change, RSB transfer, value for margin in inventories...) as they are not used for data entry but only for retrieval purposes.
Timing : Wave 3 - end of January Y+1
Connect to BFC_Top:
Select the “Dimension Builder” module in the "Setup" domain.
Then select the MARK and CGU dimensions and expand the hierarchy to access to the upper levels.
Doing this move, the new created object (either MARK or CGU) will become available for usage in package data entry in Y+1 ACTUAL's reportings thanks to filters integrated in BFC users accesses providing accesses only on MARK and CGU objects with EMPTY value on "Change" characteristic :

![]()

In the tab “Properties” (either CGU or MARK table),


Doing this move, the existing object (either MARK or CGU) expected not to be used anymore from Y+1 will become blocked (unavailable) for usage in package data entry in Y+1 ACTUAL's reportings thanks to filters integrated in BFC users accesses providing accesses only on MARK and CGU objects with empty value (different from OLD and NEW) on "Change" characteristic :

![]()
In the tab “Properties” (either CGU or MARK table),




In addition to the "OLD" value, characteristic "RSB transfer" may have to be filled in to automate RSB restatements (through dedicated consolidation rules).
Such rules will transfer P&L / Bal Sheet items from OLD CGU/MARK codes (used in Y-1 Actual's reportings) to the NEW ones (used from Y+1 Actual's reportings). This will allow Business users to compare Y-1 and Y+1 results using the same Business structures (Y+1 one).
Example:




In the tab “Translation” (either CGU or MARK table),


Timing : Wave 3 - end of January Y+1
This move has not impact on data entry in reporting packages. However, it impacts the aggregation of each level and thus Business results obtained in retrieval reports.
Note that MARK and CGU hierarchies are not subject to any historisation/archiving. This means that any transfers inside will apply immediately to all reporting periods (past, current and future). This is why set up of manual filters (MARK and CGU dimensions) can be requested to BFC Admin by Corporate Controlling to artificially rebuild the past hierarchies aggregations and allow data retrievals on the past results using those filters.
Connect to BFC_Top:
Select the “Dimension Builder” module in the "Setup" domain.
Then select the MARK and CGU dimensions and expand the hierarchy to access to the upper levels.
Transfers / change of links are highlighted with red background in the Reference file - they can be:
Example in 2022 Business structures changes: TSDP and TSFU moving from BU TSDPH yo BU TSMIN

In the tab “Properties” (either CGU or MARK or BU or GBU or SEGMOP table),

Timing : @ each wave of customizing
Step1 - BFC Admin team to perform consistency checks in BFC_TOP (customizing database):
In each MARK and CGU table,

Example for NEW object NBGH (MARK) and NBGH2 (BU)

Example for NEW object NBGH (MARK) and NBGH2 (BU)

Example for TRANSFERS of TSDP (MARK) from TSDPH (BU) to TSMIN (BU)
Example for NEW object NBGH (MARK) and NBGH2 (BU)

Step 2 - BFC Admin team to pilot changes from BFC_Top (Customizing database) to BFC_WORK (Testing database) for review and validation from Corporate Controlling

Timing : @ each wave of customizing ONLY when authorized by Corporate Controlling

Timing : Dec Y + "on flow" during Y+1 each time there is a change
Reference file gathering the BFC Business structures changes for Y+1

Process to upload Business Structure file in GAR AODOC link here to Business Structure folder :
Step 1 - At each beginning of the year YYYY, created the folder YYYY in AODOC
Step 2 - Download in Excel format Business Structure file from GDrive to local desktop (impossible to import directly a GDrive file to AODOC)
Step 3 - Import the Business Structure file (Excel format) to AODOC :
![]()

![]()


Timing : January Y+1 + "on flow" during Y+1 in case of GBU creation
3 types of users in BFC:
As a consequence, Business structure changes impacts Business accesses in BFC each time a new GBU is created
Process to be followed:
Example : July 2021 creation of new GBU code O&G "Oil&Gas"made of activities previously hosted in both CS "Novecare" and TS" Technology solutions" GBU's






Timing : January Y+1 + "on flow" during Y+1 in case of GBU merge or spin off
When GBUs are merged or splitted it may be useful for historical data retrieval to have a filter that includes the old GBUs that were previously separated or combined.
Examples :
In the 1st example, if a BFC end user wants to retrieve data prior to 2022, previously hosted in two GBUs (TS and CH) and now in just one, he /she can use a filter (combining CH and TS) and that way get the data collected for the 2 GBUs.
Such need must be always confirmed by Corporate Controlling before creating the filter in BFC.



END OF THE PROCEDURE