1. Concept

1.1 Need 

Perimeter Change management is needed to ensure comparability of figures over time when the reporting structure changes, by restating the reference period to align it to the structure of the current period.

The reference period that we compare against is usually the Budget or the previous year, but it can also be the Best Estimate / BFR.

Examples:

Normally the Best Estimate should reflect the latest reporting structure, so there is very limited need for restatement when comparing Actuals vs Best Estimate: we will not use 

Some changes in master data have a retroactive impact in the reports (i.e. they change historical figures), others do not.

The perimeter change developments only apply to Co$Ta reporting:

• In BW: Co$ta Origin
• In Qliksense: Co$ta Origin and Co$ta Destination
• HR (FTEs): pending

It does not cover P&L items that are not in the scope of Co$ta (e.g. Sales, raw materials & energy, post-EBITDA items), and does not cover balance sheet or cash flow items (e.g. working capital, fixed assets, many CAPEX items…).

1.4. Methodology

When changes are impacting the data retroactively, the reporting system’s past data will change, and will no longer reflect the original situation (automatic restatement).

In this case, we will rely on a flow (“Perimeter Correction”) that will allow to rebuild the original figures we had before the automatic restatement.

Then in all cases, we will use another flow (“Perimeter Adjustment”) to restate the original figures and have them comparable to the current period.

Note: the budgeting hierarchy for the current year will be frozen at the same time as the budget figures. Any subsequent change for Best Estimate leading to discrepancies with this frozen version will have to be managed through perimeter adjustments on the budget. Consequently, there can be no automatic restatement on the current year budget.

1.5. Examples

1.5.1. Cost Center A is reassigned from GBU X to GBU Y

1.5.2. Part of the costs of CC A are transferred to a different CC (i.e. starting in the current year, these costs are posted on CC C instead of CC A)

2. How does it work?

2.1. General principles

• The perimeter correction and perimeter adjustment flows are loaded in BW through a specific transaction, via a flat file.
• Perimeter correction and adjustment flows can be retrieved in BW (via Adjustment Perimeter Type (C_PERITYP).
• The data is then loaded into Co$ta and available in the Co$ta reports.
• Co$ta Reports offer the possibility to display the original figures, the flows and the restated figures (see Co$ta - Dashboard).
• The level of granularity (in terms of dimensions) at which we load the flows have to be adapted to the level of detail we want for the restatement:
  • Most will have to be loaded at Cost Center (or budgeting node for the budget) level and at GBU level
• The development enables the automatic determination of dimensions (e.g. determine macro-package & package based on sub-package provided in the file, removing the need to provide all dimensions)
• However, when dimensions are provided in the upload file, they overwrite any automatic determination based on the current structure (mandatory if we want to restate items that were changed because of a change in the budgeting hierarchy for example)
• Loading flows with more granularity will help having consistent drill-downs in the reports but is heavier to prepare
• It is advised to apply a materiality threshold to select for which perimeter changes to apply this technique
• Unless the scope change is an acquisition or divestment (or change in consolidation rate), perimeter adjustments and corrections should compensate and should not change the total of the reference period.

2.2. Specifics

• Full transfer of cost centers (change of business area or profit center): applied retroactively in BW, requires flows B & D
• Change of consolidation status of a company (in case of divestment): applied retroactively in BW - Largely consistent and requires flows B & D, but causes issues in some cases (e.g. R&I activity in 1 company in Korea invoicing other companies: interco cost - Hosting company is divested -> costs appear retroactively as 3rd party costs, but before the divestment the activity was transferred to another conso company, current costs are still interco)
• Partial transfer of costs between 2 CCs: leads to comparability issues between the 2 CCs: no automatic process possible. Only requires flow D
• Creation of new cost centers (e.g. for a carve-out): no past data automatically retrievable, but if the new CCs are assigned to the same budgeting hierarchy levels, restatement may not be needed if figures are analyzed at Level 5.
• If several perimeter adjustments stack up one after the other (e.g. organizational change + macro-package change), we’ll need to maintain full consistency to compute the correction flows. Note: it was decided not to perform restatements in case of taxonomy change, i.e. we accept the retroactive automatic restatement of the figures.
• There is a risk of conflict if there are manual corrections (e.g. package reassignment by PSL) on top of a perimeter correction

2.3. In practice - Restatements for costs at the origin

2.3.1. File to use

Perimeter adjustments need to be loaded in BW using a specifically formatted file.

The file allows to force the values of different dimensions, but in many cases there are automatic determination rules that will apply if no value is entered. A value that is entered always overrides the automatic determination.

2.3.2. Contents of the file and explanations

Legend:

• Mandatory fields: on orange background
• Most useful fields: on light blue background
• Other fields to be used for more specific cases: on white background

2.3.3. Transaction for upload

You can upload the file using the transaction ZBW_CUST_COSTA in WBP and then click the button

2.4. In practice - Restatements for destination Bridge

2.4.1. File to use

Perimeter adjustments need to be loaded in BW using a specifically formatted file. 

The file allows to force the values of different dimensions, but in many cases there are automatic determination rules that will apply if no value is entered. A value that is entered always overrides the automatic determination.

2.4.2. Contents of the file and explanations

Legend:

• Mandatory fields: on orange background
• Most useful fields: on light blue background
• Other fields to be used for more specific cases: on white background

2.4.3. Transaction for upload

You can upload the file using the transaction ZBW_CUST_COSTA in WBP and then click the button

3. Reporting

3.1. Origin Perimeter changes in BW

Once the perimeter change file (excel format) has been successfully loaded in BW (following the previous step), it is important to confirm that the data were appear correctly in BW. 

In order to do this, you will need to run BW Co$Ta Origin query.

Perimeter and Adjustment flows can be specifically accessed using the characteristic Adjustment Perimeter Type (C_PERITYP).

Once you ran the query, add dimensions and measures to reflect the structure of the file you have loaded. See template of upload file here for the structure.

Then, make your checks and ensure that the data loaded in BW (via excel file) appears correctly in the BW query.

3.2. Origin Perimeter changes in Co$Ta

Once all checks in BW are done and successful, your final check will be to confirm that what appears in BW appears also correctly in Co$ta - Dashboard.

In order to perform this last check, you will need to wait the next QS upload of BW into QS COSTA. Once this upload is done, you will be able to see and check the latest perimeter changes made.