1. Objective and Scope

The objective of this procedure is to describe purpose and process related to the BFC internal controls (users accesses management, customizing activities, sensitive actions from BFC Administration team…).

Both maintenance and customizing activities must be performed in compliance with internal controls designed with Data Compliance and Audit team and audited twice a year by Syensqo external auditors.

2. BFC Internal Controls

Main risks to be covered are the following: 

• Uncontrolled activities from BFC Admin (having by definition 100% rights in the tool): non justified deletion of objects, piloting to production of non approved changes in customizing
• Modification of Financial data by unauthorized users
• Missing segregation of duties (i.e users able to unlock and resubmit data)
• Uncontrolled extended display rights (giving access to full set of Syensqo Group results).

BFC Administration team is the control owner of the following internal controls - UAM (User Access Management) and CM (Change Management): Audit

• UAM01 Password Management
• UAM04 Functional Profiles 
• UAM07 Matrix of incompatible functional profiles 
• UAM05 Access Requests
• UAM14 Review of sensitive accesses 
• UAM14 Audit Trails on critical activities
• UAM06 Change of access rights (movers)
• UAM11 Deletion of access rights ( leavers)
• UAM12 Periodic review of inactive users 
• CM03 CM06 CM02 CM06 Change management

2.1 UAM01 Password Management 

Purpose: Check the compliance of BFC users passwords with Syensqo Security policy 

This Control is restricted to “Internal Users” (authentication type "internal") as “External Users” (authentication type "external") are using the Single Sign On.

Description: The BFC Administration team reconciles an extract of password settings from the BFC_Production system and the password guidelines included in the security policy: all the directives must be respected.

Control type: (Completeness, Accuracy, Validation, and Restricted Access): Completeness, Accuracy and Restricted Access

Frequency: "on flow" when Syensqo’s password policy changes (before frequency was a yearly one)

Control evidence: 

In “Action” menu / “Password Manager” option, the BFC Administration team defines length of Internal password as well as their validity duration. 

From June 1st 2023 parameters adapted on password length (request from EY auditors after 2022 audit) :

• As before: After 90 days (before duration was 60 days) using the same password, BFC will automatically oblige the Internal user to change his / her password. Without this renewal, the Internal user cannot connect anymore to BFC
• Length of password set to 14 characters (before 12 characters)

• The Single Sign On enables users to use their Syensqo personal login and password (the one used to connect to their computer) to connect also to BFC. 
• When they will change their Windows password, it will be automatically taken into account by BFC too.

2.2 UAM04 Functional Profiles 

Purpose: All the Functional Profiles creation/modification requests are formally validated by the Syensqo GAR Consolidation Manager (appointed as KUF = Key User Function).

Description: The BFC Administration team, before updating the role into the system, checks manually the presence of incompatibilities in the role design, according to the matrix of incompatible actions. In case of some incompatibilities are found he/she informs the Consolidation Manager (KUF) who validates them.

A functional profile defines the types of rights to perform specific tasks in the application. For example, whether or not a user is authorized to create, change or delete data in schedules. 

The major risk to be managed is to avoid to introduce in Functional profiles (through creation / modification) incompatible rights without any authorization from KUF.

Control type: (Completeness, Accuracy, Validation, and Restricted Access): Validation, Accuracy

Frequency: On Flow, meaning each time there’s a need to change or create a functional profile

A) Functional Profiles created in BFC since its implementation in 2005

B) Functional Profiles currently used (23/05/2024)

C) Description of Functional Profiles currently used (23/05/2024)

Evidence stored in GDrive: UAM04 Functional profiles

2.3 UAM07 Matrix of incompatible functional profiles

Purpose: Matrix of incompatible transactions by critical level is maintained and updated in order to include each new critical transaction.

Description: The file “UAM07 Matrix of incompatible functional profiles YYYY” is a validation of the updated matrix of incompatibilities by the Key User Function (Consolidation manager):

• The "Responsibilities Matrix" tab is a Description of the Functional Profiles that are used in BFC highlighting the incompatibilities existing in some of them. Main incompatibilities existing:

 - Functional profile ADMINISTRATION: "full power" users authorized to modify (creation and deletion) all of the objects and data in SAP Financial Consolidation.

 - Functional profile ADMIN-GAR (new profile set up in April 2024): CONSOLIDEUR rights + publication of packages (attributed to 1 member of GAR Syensqo team to act as back up in case of absence of Acc or BFC Admin teams)

 - Functional profile RTR BO-COR:  the combination of rights to 1) unlock packages + 2) modify data inside + 3) publish packages modified should be considered conflicting duties. 

- Functional profile REOPEN-DEROG (new profile set up in May 2024):  the combination of rights to 1) unlock packages + 2) modify data inside + 3) publish packages (with standard mode or by derogation) modified should be considered conflicting duties. 

• From May 2022, the incompatibilities will be controlled each time there is a change in an existing / creation of a new Functional Profile content (link with UAM04) to ensure that those actions do not generate any incompatibility
• This matrix is signed by the Consolidation Manager (KUF), scanned and published in Google Drive each time there's an update (change or creation of a functional profile) generating a new version.

The "Functional Profiles Definitions" tab is a detailed description of the Functional Profiles.

Control type (Completeness, Accuracy, Validation, and Restricted Access): Validation

Evidence stored in GDrive: UAM07 Matrix of incompatible functional profiles

Frequency: "On Flow", each time we change or create a functional profile (consistent with UAM04)

2.4 UAM05 Access Requests 

Purpose: Access rights given to users are formally validated by the BFC Administration team. 

Description: Access requests are sent by e-mail or via Service One ticket (transferred by IS BFC Admin) to the BFC-Admin mailbox, normally the request is performed by the user with his/her manager in copy (manager as defined in Syensqo One Organizational chart).

Important Notes:

• If the manager is not in copy (it happens often with the transferred tickets), the BFC Administration team must request his/her approval before communicating the access given. 
• To check the user's manager or missing details like User ID, email, BFC Admin can use Syensqo HR system / "Org Chart" section through this link https://performancemanager.successfactors.eu/:

• Any request requiring access to critical data (Administrators and users requiring access to owner groups CONSO or CONSO+) or critical actions (Administrators and users requiring access to functional profile CONSOLIDEUR) must be approved by the Consolidation Manager (KUF) => UAM04 & UAM07.
• Since the implementation of the Single Sign On, before creating a new user, the BFC Administration team must request IT team through ticket in Service One to add this new user to the Active directory (AD)  - “BFC User Group”  - refer to the following procedure Users access Management in BFC-6.REQUEST TO ADD THE USER IN THE ACTIVE DIRECTORY GROUP. 
• Active directory (AD) is a list of all Syensqo users’ accounts (but also computers, servers, printers, shared directories…). It authenticates and authorizes all users and computers by assigning and enforcing security polices, installing and updating software... For example:  when user logs into a computer, AD checks the submitted password and determinates whether the users is a system administrator or a regular user.

Control type: (Completeness, Accuracy, Validation, and Restricted Access): Validation and Restricted Access

Frequency: On demand @ each user access request

Evidence stored in GDrive: UAM05 Access Requests

2.5 UAM14 Review of sensitive accesses

Purpose:  Users list with sensitive accesses is reviewed by Consolidation manager (KUF) before each quarterly closing

Description:

• Although accesses are granted upon managers approval (in case of sensitive accesses upon Consolidation manager approval as well) and users deactivation occurs on a regular basis the list of users with sensitive accesses (rights to change data at conso level) is reviewed by Consolidation manager before each quarterly closing. The risk to be covered is to avoid keeping sensitive accesses no longer needed (users who have changed job positions)
• Note that the exhaustive access review not covered here (only sensitive accesses) is compensated by UAM06 and UAM11 Users deactivation related to Leavers & Movers 

Control type: (Completeness, Accuracy, Validation, and Restricted Access): Validation and Restricted Access

Frequency: Quarterly in March - June - September - December, before quarterly closing process

Validation process:

1. BFC Administration team sends a screen copy of users granted with functional profiles "CONSOLIDEUR"" or ""CONSO-SAISIE" or "ADMIN" or "ADMIN-GAR" by e-mail to GAR Consolidation manager requesting his review and approval 
2. GAR Consolidation manager's answer with validation and/or request for necessary authorization updates, is sent back to BFC Administration
3. BFC Administration team proceeds with updates, when needed, in the system and resent the print screen with new updated list of users to Consolidation manager

Evidence stored in GDrive: UAM14 Review of Sensitive Accesses

2.6 UAM06 Change of user access rights (Movers)

Purpose 1: Deactivation or rights adaptations done on a regular basis for movers.

Description: The Syensqo Group members who have access to BFC should be compliant with their status and their position on HR tools. The objective of this Internal Control is to reconcile the users status on BFC according to their HR status and identify the users that should be deactivated from BFC or whose rights have to be adapted to new job position. 

Changes of HR attributes which can trigger a change in BFC access rights:

• Business Unit - some examples below
  • GBS driving BFC access rights restricted to data entry and WW or Regional scopes of companies
  • GBU xxx driving BFC access rights restricted to read-only and GBU scope
  • Finance driving often sensitive BFC access rights including full Group's scope and sometimes Consolidation rights
• Job classification - some examples below
  • Accounting & Reporting
  • Controlling
  • Finance Management
• Department - some examples below:
  • GBU Novecare - Finance - EMEA
  • Controlling Platform
  • Consolidation
• Position - some examples below:
  • Management Accounting Service Unit
  • Accounting Country
  • GBU Novecare - Controlling ES

In other words, other HR attributes such as Supervisor, Cost Center, Company code have not to be considered as they have no correspondence in BFC rights management.

Among those 4 attributes, Business Unit is the upper one and Position being the lowest one in Organizational chart.

From May 23rd 2024, new process of notifications using MyID application.

Analysis and changes of access rights, when applicable, are done based on the "New Mover Report" sent from MyID:

• BFC New Mover Report is generated by MyID every day when a Mover from HR system having a change at least in 1 of the 4 attributes above and having access to BFC Solvay is detected
• This report is automatically sent to BFC Administration team by email. 
• BFC Admin analyses the report the same day after reception of the notification.

Frequency:   On Flow (each time MyID detects a Mover having an access into BFC Syensqo) - MyID program executed 6 times per day

Control type: (Completeness, Accuracy, Validation, and Restricted Access): Validation and Restricted Access

Email  / notification sent from MyID:

• User ID of the Mover in the title
• 1 mail per changed attribute (Business Unit / Job classification / Department / Position) => up to 4 mails per UserID

• Old and New value of the attribute provided in each e-mail 
• 

Process BFC Admin:

• Step 1 : Analysis of changes per attribute
  • Looking at the existing rights in BFC, BFC Admin will determine if the new HR attributes trigger or not an update

•  Step 2 case A : No update required
  • BFC Admin member will officialize inside the team by replying to the mail and providing his/her analysis and conclusion and , if relevant to support the conclusion, a print screen of existing rights in BFC
    • example 1 "User xxxx has made an internal move inside GBS. His current access rights (providing WW scope of cnies and access to packages) are still needed for his new position. As a conclusion, no action to be taken"
    • example 2 "User xxxx has made an internal move inside Finance Corporate. His current access rights (providing Full Group's access) are still needed for his new position. As a conclusion, no action to be taken"
    • example 3 "no need to update BFC rights for this Mover as they are still appropriate - her access is based on upper levels (GBU's), not on sites"
    • example 4  "User xxxx has left Finance to take another position, not requiring anymore the usage of BFC => account closed this day"

•  Step 2 case B : Update probably required => Check and validation with the impacted user
  • BFC Admin member makes a proposal of rights adaptations to the user, asking for his/her confirmation, keeping his manager in copy
    • example 1 "As part of Internal Control procedures, we have been notified by HR of your recent move from xxx (OLD) to yyyy (NEW). Your new position in GBU x requires a change in your BFC access rights to restrict to this GBU with a read-only mode. As a consequence, your existing rights (access to data entry in packages and WW scope) will be removed. Can you please validate our proposal and confirm we can make the change from now on? "
    • example 2 "As part of Internal Control procedures, we have been notified by HR of your recent move from xxx (OLD) to yyyy (NEW). Your new position in GBS SU Mngt Acc. requires a change in your BFC access rights granting you data entry on WW packages. As a consequence, your existing rights (Full Group access + Consolidation rights) will be removed. Can you please validate our proposal and confirm we can make the change from now on? "
    • example 2 "As part of Internal Control procedures, we have been notified by HR of your recent move from xxx (OLD) to yyyy (NEW). Your new position does not justify to keep in your BFC access . As a consequence, we will close it. Can you please validate our proposal and confirm we can make the change from now on? "

• • Once confirmation and validation is obtained, BFC Admin updates user's access rights in BFC. Evidences of changes (before and after) are logged in BFC and can be displayed at any time

In BFC “Security/Users” module, deactivation will be proceeded the following in the user profile:

• Owner Group: PARTI
• Functional Profile: DESACTIVE 
• Data Access Group: RIEN

and the user must be blocked in order to be prevented from accessing BFC.

2.7 UAM11 Deletion of user access rights (Leavers)

Purpose 1: Deactivation done on a regular basis for leavers

Description: The Syensqo Group members who have access to BFC should be compliant with their status and their position on HR tools. The objective of this Internal Control is to reconcile the users status on BFC according to their HR status and identify the users that should be deactivated from BFC. 

From March 11th 2024, new process of notifications using MyID application.

Deactivation is done based on the "New Leaver Report" sent from MyID:

Frequency:   On Flow (each time MyID detects a leaver having an access into BFC Syensqo) - notifications sent at 1am

Control type: (Completeness, Accuracy, Validation, and Restricted Access): Validation and Restricted Access

Process: 

• BFC New Leaver Report are generated by MyID every day when a leaver from HR system and having access to BFC Syensqo is detected
• This report is automatically sent to BFC Administration team by email. 
• BFC Admin proceeds with the user's deactivation the same day after reception of the notification.

Email sent from MyID:

BFC Admin proceeds the deactivation in BFC Syensqo: 

2.8 UAM12 Periodic review of inactive users

Purpose: Temporarily deactivation on BFC when the user has not connected during the last 6 months

• When the user has not connected during the last 6 months his/her access has to be temporarily deactivated on BFC.
  • Note that on Org. Chart/SuccessFactors  the status may be still ACTIVE, but the user can have a new position that doesn´t request the access to BFC so frequently; temporary leave (maternity, sickness) can also justify those cases.
  • From 2024, to simplify the work from BFC Admin team, deactivation are made without any prior notice to the end users 
• Frequency : mid June / mid December

How to build the file of inactive users: 

Step 1 - calculate the date corresponding to 6 months ago

• For example, for Inactive control performed on 13.06.2024 - 6 months => 13.12.2023;

Step 2 - In BFC, sort ascending the users by last connection date and export the list of users without any connection and users without connection since 6 months

• in the example above, users with no connection since 13.12.2023 and users who never connected to BFC (last connection date = empty)

Step 3 - Save the export under this gdrive folder  UAM12 Review of inactive users

• do not forget to add a timestamp of the extraction in BFC

Step 4 - Using filters on columns, identify users which should be excluded from the deactivation

• Users created during the last 6 months - filter on column "Date created"
  • considering they have 6 months to connect and use BFC. If not, they will be deactivated at the next control wave
• Users created and deactivated before the last 6 months but reactivated during the last 6 months - filter on Column "Last changed"
  • Check in BFC Display report if the user was reactivated in the last 6 months - Blocking status modification changing from "Blocked" to Unblocked"
  • considering they have 6 months to connect and use BFC. If not, they will be deactivated at the next control wave
•  “TINSTALL user” - filter on column "User ID"
  • The user TINSTALL must remain always active: 
  • This user ID is the one used by IT Infrastructure teams to test that the technical installation of BFC application on users’ PC is correct.
  • Note that this user only contains rights to connect to BFC application, without any other rights to modify any objects or to display any data. 
• “ADMIN user” - filter on column "User ID" 
• • The user ADMIN must remain always active: 
  • Admin is a technical user, it is created automatically when BFC application is installed and database created. Some administrative tasks can be performed only by Admin User, mostly related to application installation and upgrade
• “GESTION user” - filter on column "User ID" 
• • The user GESTION must remain always active: 
  • This user is used by Corporate Controlling to fill in PREV (controlling categories for Forecasts) packages (made of fictive cnies per GBU). This is made once a year (Q4 or Q1 following year), this is why this user systematically appears in this control
• “ROBOTS fleet” - filter on column "Functional profile"
  • The users with functional profile ROBOTS must remain always active: 
  • A fleet of robots has been created in BFC and developed by RPA team to perform the following actions for FSL team: packages loading / reopenings / ghost session killing / refresh of big Excel dashboards 
  • As it is a fleet, RPA and FSL is directly mobilizing only some or all robots depending on volumes to be processed. 

Step 5 - Proceed the deactivation of remaining users (not excluded by the analysis above) in BFC:

• Open the user to be deactivated

• Modify its owner Group to select "NET"

• Block the user

Step 6 - Timestamp of the deactivations made in BFC to be posted in the google file

Evidence stored in GDrive: UAM12 Periodic Review of Inactive Users

2.10 UAM14 Audit trails on critical activities

Purpose: Audit trails on critical activities (deletion of objects) on a regular basis to ensure that all the actions made are justified.

Description: This control traces the sensitives actions in the PRODUCTION environment performed by:

• Users with ADMINISTRATION functional profiles (full rights & restricted rights): ADMIN / ADM-xxx / ADM-LEGER
• Users with IT functional profiles
• Users having double accesses to BFC (2 logins)
• Users ID starting with TESTxx and user TINSTALL

As  several controls are already in place to control users accesses (UAM05 Access requests /  UAM14 Review of sensitive accesses / UAM06 UAM11 UAM12 Users deactivation) and already covering the control of sensitive actions (unlocking, publication by special permission...), critical actions to be monitored through UAM14 Audit trails are restricted to the deletion of objects.

Note that IT/TEST/TINSTALL profiles don’t have a significant impact in terms of modifications in BFC:

• The IT profile has access to all the data, however only in consulting mode;
• TINSTALL user has no access to change any objects or to access to any data;
• TESTxx users are only activated on demand by BFC Administration to solve issues raised by BFC end users (eg “I can not see packages”, “I can not see this x company in my list”…). TESTxx user is temporarily activated with the same rights than the requestor to experience/see the same. Once issue solved, the TEST user is deactivated.

Control Report Process

1) On WD2 of each month, DT BFC Admin extract the audit trail file from Log module and send it to BFC Admin team;

Below is the email received from DT colleagues:

2) This list contains all deletion actions performed (who and when);

Evidence stored in GDrive: UAM14 Audit Trail on Critical Activities

3) BFC Admin creates tab BFC Admin review (copy from Actions by User profile tab)

Arrange the layout as below in order to be more legible:

4) Finally it should be analyzed for possible anomalies – BFC Administration team Comments - and the file should be sent/shared for BFC Admin manager review;

Control type: (Completeness, Accuracy, Validation, and Restricted Access): Completeness, Accuracy and Validation

Frequency: monthly and focused on deletion of objects 

2.10  CM03 CM06 CM02 CM06 Change Management

Purpose:

The BFC Administration team is responsible to manage the maintenance of BFC. 

1. The customizing and the main changes in BFC should be duly documented and justified; 
2. The control shall be carried out in relation with the requestor;
3. The control is sized according to the risks.

The following risks will be covered by the Internal Control framework:

• CM01 : Approved management methodology is used
• CM03 : Any request for customizing change is validated (or directly submitted) by an authorized KU (Key User)
• CM05 : Validation of functional design is given by an authorized KU (Key User)
• CM06  :  Acceptance is given by an authorized KU (key User) prior to piloting changes into Production
• CM02 : Backward traceability is ensured - consistency between changes piloted to Production and initial request
• CM06 : Authorization for Production upgrade is given by an authorized KU (Key User) before piloting changes into Production

Types of modifications:

The maintenance categories can be grouped in 4 types :

• [A] Recurring reporting set-up (Basic Customizing) M (monthly)/ Q (quarterly) / Y (yearly)
• [B] Correction of errors
• [C] Improvements 
• [D] Medium to complex Customizing (changes in Chart of Headings, New Business Structures, changes in Reporting content....) represent critical / sensitive maintenances on BFC. 

"Recurring maintenances" – Customizing (creation of new objects) with no impact in the data already in the Production environment:

• Monthly recurring activities: creation of scopes, exchange rates tables, new companies
• Creation and/or Modification of schedules;
• Creation in the Structure: New dimension member; new characteristic member; Filters creation;
• Creation in the Set of Rules: Creation of new consolidation rules
• Creations in the Category Scenario: New controls/new headings/new formulas...

“Critical / sensitive maintenances ” – Customizing (modification of existing objects) with impact in the data already in the Production environment: 

• Changes in the Structure: Creation of new objects (Dimensions; Characteristics, Reference table...); Changes in existing filters;
• Changes in the Set of Rules: Changes in the existing consolidation rules;
• Changes in the Category Scenario: controls / headings & analysis schemes / formulas/ account Families …
• Complex Projects: new IFRS norms as example;

A BFC project can be defined as: 

• A formal request from a BFC Key User (belonging to the “Authorized requestors” list defined below) expressed through a functional specification; 
• A complex request requiring the modification of the Dimension Builder and Category Scenario objects, with the corresponding technical specifications; 
• A request whose implementation in Production passes through tests in the Test environment and formalized validations. The concept of BFC projects obviously does not cover version migrations ( supported under IT project);

• It´s the combination of those 3 criteria that determines whether we are in a recurring maintenance or in a project.

List of Authorized requestors (BFC Key Users):

• GAR CONSOLIDATION team Brussels: Serge Kasbi (temporary manager ) / Mario Tondo / Chammen Ben Ammar / Caio Morgon / Nicolas Bourgois (RSB)
• GAR TAX & CONTROLLING : Anne Calicis
• CORPORATE CONTROLLING Business: Hugo Fradique / Jean Philippe Terrasa (manager)

Operating mode for each maintenance category of the BFC Administration team

[A] Reporting set-up Monthly / Quarterly / Yearly

•  [A1] ACTUAL’s (IFRS purposes) M/ Q / Y – Monthly Process
  • The BFC Admin team is responsible for preparing the Reporting set-up required for each reporting cycle:
    •  Opening of reporting periods on WD-4 – Done directly in Production
    •  Reporting packages creation and generation on WD-2 – Done directly in Production
    •  Creation of exchange rates table on WD-1
    •  Creation of consolidation scopes on WD1
    •  Creation of Consolidation/ Intercos Reconciliation definitions on WD1 – Done directly in Production
    •  Creation/update of objects in the Dimension builder: Companies, Sites, Business activities
    • Note that the Risks related to the management of a monthly / quarterly and yearly reporting sessions are low impact. Any errors detected can be easily corrected.

• [A2] RSB (Controlling purposes) – Quarterly Process / [A3] PREV(Controlling purposes) – Yearly Process
  • The formalization of the modifications done to these two types of reporting sessions are managed by the Corporate Controlling;
  • The BFC Administration team is responsible to perform the necessary changes;
  • Once the changes are made, Corporate Controlling validates that the changes are in line with expectations and gives the GO for piloting to Production;
  • Evidence: Controlling agreement to pilot to Production;

[B] Correction of errors / [C] Improvements (with no impact in the Reporting Content)

• Error corrections and improvements are usually based on the feedback from the Reporting cycles. For example, a control to be modified, a data collection to be improved in the reporting packages, a new report to be created, corrections of existing descriptions. 
• These corrections / improvements are safe from both BFC settings and data integrity point of view. Otherwise, it is no longer a question of corrections / improvements but of a BFC project.
• The associated controls must be minimal and not heavy to ensure fast services to requestors.
• As a general principle, the piloting actions for [B] Corrections and [C] Improvement  are carried out in the same way as the type [A] Reporting Set-up.

[D] Structure Update and Customizing

• The changes linked to the Structure Update and Customizing are expressed by an authorized Key User from Consolidation / Tax / Financial Controlling / Corporate Controlling
• The implementations are more complex but generally not risky as: 
  • The updates are made outside of the closing periods with a compulsory testing part
  • Consequent updates are never implemented over a quarterly reporting period
  • A reversal / step back is always possible
• The changes are managed by the BFC Administration, documenting the changes with:

1. 1. Definition of the need, expressed and completed with the requestor
   2. Functional analysis (impacts of changes in reporting framework)
   3. Functional specifications (changes needed in BFC modules and objects)
   4. Testing plan (to be performed by both Administrator and Requestor)
   5. Evidences obtained from tests
   6. List of objects to be piloted to Production (once final validation and authorization to pilot are obtained)

Internal Controls :

In order to simplify the process, several types of tasks have been created in BFC according to the related process and to the requester: 

• SCO-ADMIN: for the reporting set-up or other recurring tasks / corrections and improvements (type A1 / B / C) -  no approval required from KUF as linked to recurring activities)
• SCO-CONSO: for requests (type D) expressed by the Consolidation team ;
• SCO-CTRLFIN: for requests (type D) linked to the Financial controlling ; 
• SCO-GESTION: for requests (type A2 / A3 / D) linked to the Corporate controlling ;
• SCO-TAXES: for requests (type D) linked to the Taxes ;
• For ALL types, periodic and retroactive review of all pilotings is done to validate appropriateness using four eyes principles (validator not being the one having piloted the changes into Production)

The BFC Administration team uses always these tasks and their content is transferred to Production. Any piloting from BFC Customizing database (BFC_TOPSCO) to BFC production database (BFC_PRODSCO) is logged/archived and can be extracted.

Specific Internal controls for tasks type SCO-CONSO / SCO-CTRLFIN / SCO-GESTION / SCO-TAXES (note: does not apply to SCO-ADMIN tasks):

• BFC Admin team will archive as Internal Control evidences:
  • initial request submitted by an authorized Key User (CM03) - channel can be e-mail / meeting minutes
  • formal acceptance of customizing done from the authorized Key User (CM06)
  • formal authorization to pilot customizing changes (objects) to production from the authorized Key User (CM06)
  • confirmation of piloting and reception into Production in link with the requested changes (CM02)
• Note that the 4 evidences can be sometimes collected in the single printing of a chain of mails

• Evidence stored in GDrive: https://drive.google.com/drive/folders/1G67YgvhE3tVvBJkyYUp6tLwHsLnOTf2c

Internal Control applicable to ALL tasks type (SCO-ADMIN /  SCO-CONSO / SCO-CTRLFIN / SCO-GESTION / SCO-TAXES):

Every month , BFC Admin team will:

• extract from the BFC Production database the full list of piloted tasks (since last day of review to date) - extraction will be stored in this folder Piloted tasks review and validation

• 1st check is to control that number of lines in the file equal to nb of piloted tasks (BFC module Tasks) during the reviewed period
• For each piloted tasks, BFC Admin team will complete the Extraction's file adding the Category type (A / B / C / D)  as well as the Transferred content (objects piloted)
• E-mail will be exchanged between BFC Admin team members requesting review and validation of each piloting applying the four eyes principle (validator not being the BFC Admin team member having done the piloting)
• Detailed review and validation will be formalized in a dedicated column in the Extraction's file: name of validator / note: for tasks SCO-CONSO / SCO-CTRLFIN / SCO-GESTION / SCO-TAXES, subject to a dedicated set of Internal Controls, a reference to the approval obtained from authorized Key User will be given by the validator

Assessment of completeness and accuracy of customizing changes:

Every change (creation / update) in BFC customizing is driven by Corporate Consolidation and Controlling needs to perform monthly / quarterly / year end Consolidation and Reporting cycles. 

As explained above, piloting of changes to BFC Production can be done using different types of tasks:

• recurring needs (scopes, exchange rates, consolidation status of companies...) : managed autonomously (as part of his/her direct responsibilities) by BFC Admin using information collected on flow from various channels of communication (GAR closing calendar, GAR Structure file, GAR closing instructions, General Group Secretary, Quantum interfaces for Exc rates...) and from direct interactions with Corporate Consolidation and Controlling (phone call, mails, chat) - all recurring tasks being documented in BFC Admin Operating Procedures
• complex changes : managed by BFC Admin team following for Internal Control evidences (initial request / testing validation / authorization to pilot to production)

At each Consolidation & Reporting cycle, completeness and accuracy of customizing changes can be considered as achieved once the Consolidation and Reporting process of the period is finalized: meaning that consolidation work is finalized as well as analytical reviews and checks from the different stakeholders (Corporate, Accounting, Businesses) before disclosure.

It means as well as that every change on BFC customizing piloted before the beginning of the process has contributed to reach the Consolidation and Reporting needs without any deficiency.

From 2024, this final - either monthly or quarterly or year end -"Consolidation End state" milestone is formalized directly by Corporate GAR team creating itself a back up with locking of the last run IFRS Consolidation (special variant BKUP used) in BFC. 

END OF THIS PROCEDURE