Financial Statement Versions (“FSV”) have existed in SAP for many years as a way of structuring General Ledger (“GL”) Accounts into meaningful reporting formats. However, probably like many of you, I haven’t really given them much thought. Now with S/4HANA Cloud Public Edition, the FSV are an integral part of the solution, not only for reporting but also for their links to configuration and processes.
This Blog is also a follow up to my previous musings in Why YCOA? The value of the standard Chart of Accounts in S/4HANA Cloud Public Edition. It continues the message of highlighting all the benefits of working with the standard, delivered content. Equally it provides guidance on what you need to consider as you adapt the system, whether through creation of additional GL Accounts within the existing YCOA numbering, executing a renumbering or creating new FSV.
I started thinking about this Blog in terms of how far we can support the full cycle of Financial Statement reporting from the General Ledger. As I dug into the various reporting options, it evolved into a description of the FSV and related content.
I’m limiting the discussion to the General Ledger (technically Universal Journal tables ACDOCA and ACDOCP, including Management Reporting) only. This means the basic building blocks are the Company Codes and GL Accounts, with values in Company Code, Group or Functional Currency. I also consider the use of Ledgers for the Accounting Principles and note that all values only represent pre-consolidation data.
Adding Group Reporting into the picture would include Group or Presentation Currency and post-consolidation results, as well as the use of Hierarchies to manage Financial Statement Items. In addition, the Group Reporting Review Booklet provides a new, interactive format for Financial Statements review and reporting. I’m hoping this toolset will become available for General Ledger reporting in later releases.
For this Blog I’m going to assume a working knowledge of Chart of Accounts and General Ledger Accounts as well as Financial Statement Versions and Global Hierarchies. For details, please refer to SAP Help Financial Statement Version (FSV). The focus is on FSV content rather than functionality.
Any discussion of FSV also needs to address the use of Semantic Tags and much of the following covers their relationship. Personally I’ve found it difficult to appreciate the point of Semantic Tags but researching this Blog has given a slightly better impression of their value.
Semantic Tags are basically “named” components of an FSV (Financial Statement Items / FSV Nodes, GL Accounts or Functional Areas) such as “Revenue”. The Semantic Tags can have a 1:1 or 1:n relationship with the assigned objects, meaning that, for example, several FSV nodes can be linked together.
The idea is that you can use the Semantic Tag in other applications and it is automatically updated as new GL Accounts are created and assigned to the underlying FSV object(s). The Semantic Tags can be used in:
I’m not going to cover the detail of the Financial KPIs but would suggest these resources:
Financial Statement-Based Key Performance Indicators (KPIs)
SAP Help Financial Statement-Based Key Performance Indicators (KPIs)
You will also find that many of the Semantic Tags mentioned in the documentation actually need to be created in configuration and mapped to an FSV before the KPI based reports can be used.
The key point to be aware of around Semantic Tags is that the underlying GL Accounts are always dependent on the FSV. For example Semantic Tag ACC_REC has 28 GL Accounts assigned for FSV FPA1 but only 22 in CFG0. Whilst the careful use of GL Account number ranges for both the FSV and the Semantic Tag assignment can reduce maintenance effort for newly created GL Accounts, the reality is that working with multiple FSV requires correct co-ordination. There are no standard tools to enable consistency of assignment (where it is required) for GL Account to FSV or Semantic Tag to FSV so factor this in to your data management processes.
The screenshots are taken from a system which has countries Germany and US active and no custom FSV maintained. The system is basically what you would expect following initial provisioning of either Starter or Development systems through CBC. We also have Ledger settings as follows
Ledger 0L – Local Accounting Principle
Ledger 2L – Group Accounting Principle
Once you have provisioned the system, the initial list of FSV would look something like this, depending on the actual Countries:
Figure 1. SSCUI 102669 Define Financial Statement Versions
Note that the **99 FSV represent the delivered standard for each Country activated in the system. If further Countries are added, they will create a further **99 entry.
The more perceptive will also have noticed that whilst there is delivered Country (Local Accounting Principle) specific content, the only IFRS relevant FSV is for Cash Flow. We’ll come back to this later.
The Standard List view shows the attributes of each FSV including the Chart of Accounts (YCOA – Operational or YIKR – Alternative).
Figure 2. SSCUI 102669 Define Financial Statement Versions – Standard List view
Tip – where the “Standard List” option is not shown in the configuration overview screen, but you want to view and analyse the detailed configuration view, you can use the “Menu - Table view – Print”. This view is useful if you want to sort or filter information without extracting to Excel.
Figure 3. How to access Table List view
These are reference FSV and cannot be changed or transported. They may be updated by SAP in the release upgrade process, for example because of legal changes.
So whilst $DE3 is the same as 1099 and $US2 is the same as 1799 when the system is first provisioned, over time they may diverge. This may be due to SAP creating new GL accounts and assigning to the $*** FSV or updating their structures to reflect legal changes. Similarly customers may create and assign new GL accounts to 1099 and 1799 FSV or change the structures to meet their requirements. Either way, it’s useful to know there is a reference to check back against.
You may also want review $DE2 and $US2 for the way Functional Areas can be structured to provide an alternative reporting view.
3318458 - Financial statement versions with prefix "$" not migrated
As mentioned, these are based on the $*** template FSV and are the default reporting views for each installed Country.
They can be used in apps such as:
Balance Sheet/Income Statement
Balance Sheet / Income Statement - Multidimensional
In addition to reporting, these FSV are also assigned to the Local Accounting Principle for each Country.
Figure 4. SSCUI 103215 Assign Financial Statement Versions to Accounting Principles
Note again that there is no delivered entry for IFRS Accounting Principle which is mapped to Ledger 2L in this system.
This linkage of FSV and Accounting Principle is relevant for the Advanced Valuation functionality which is the default setting for new installations (and newly activated Countries). The valuations are executed for a Ledger which is linked to the Accounting Principle which in turn is linked to the FSV. The Advanced Valuation configuration uses Semantic Tags to select the GL Accounts which will be considered in the valuation process.
This means that it is possible to configure a single Valuation Rule with one Semantic Tag, but the Tag has different assigned GL Accounts for each FSV (and therefore each Accounting Principle and Ledger). For example if you wanted to revalue Petty Cash GL 10020000 for Accounting Principle DEAP but not USAP, you can assign the GL to Semantic Tag “FX” for FSV 1099 but not for FSV 1799.
Advanced Valuation comprises four related processes which are, (in order of execution):
This references Semantic Tags “ACCREC” and “ACCREC_OTH”
Figure 5. SSCUI 104799 Define Discounting Rules
This references Semantic Tag “FX”
Fig 6. SSCUI 105450 Define Rules for Foreign Currency Valuation
This also references Semantic Tags “ACCREC” and “ACCREC_OTH”
Figure 7. SSCUI 105452 Define Rules for Impairment
This does not use Semantic Tags as the source GLs are assigned directly.
Figure 8. SSCUI 105454 Define Rules for B/S Reclassification
There are some “features” in the delivered content which you should be aware of.
Coming back to the IFRS requirements for Ledger 2L and assuming you require a specific view which is different to the Country / Local Accounting Principle FSV, you will need to:
There is an "IFRS Oriented" view in the tab "Account Structure Overview" of xls "Preconfigured G/L account master data for YCOA (global)" in Signavio Process Navigator.
A similar situation would exist if you work with USGP as an international US GAAP Accounting Principle and require a different view than for domestic USAP.
FSV CFG0 enables report app Cash Flow Statement - Indirect Method and any Custom Analytical Queries.
SAP Help Cash Flow Statement - Overview
The FSV provides the FS Items which are mapped to the defined Semantic Tags used in the reports as described in SAP Help Assign Semantic Tags for Cash Flow Statement
Whilst you can create your own new FSV, you must map the GL Accounts to the predefined Semantic Tags for it to work with the Cash Flow Statement app.
Rapid Financial Planning & Analysis for SAP S/4HANA (“Rapid FP&A”) is a set of planning models in SAP Analytics Cloud, designed by SAP Services and which can be downloaded for free.
Implementer's Guide to Rapid Financial Planning & Analysis for SAP S/4HANA using SAP Analytics Cloud
Rapid FP&A WorkZone – this includes specific content on working with FPA1.
FSV FPA1 provides the link between the standard GL Account content in S/4HANA Cloud Public Edition and the Rapid FP&A models. It includes both P&L and Balance Sheet GL Accounts and is structured to provide nodes which are suitable for planning, for example where underlying GL Account level detail is not required.
Financial Planning and Analysis (2FM)
FSV YPS2 is focused on Margin reporting and only contains P&L GL Accounts and Revenue Recognition Balance Sheet GL Accounts. I’ll divide the usage of YPS2 into two categories:
The first bullet point means that you will need to work with YPS2 regardless, so it becomes questionable whether also maintaining an alternate FSV is worthwhile.
This is described in SAP Help Budget Availability Control for Projects, particularly the section Semantic Tags. Only expenses assigned to Semantic Tag ACT_COST in FSV YPS2 are considered. Currently this covers P&L items only, with Inventory or Asset purchases not checked.
Note that whilst it is possible to report on Budget and Actual costs at the level of the more detailed Semantic Tags, the Availability Control (i.e. system checks on expenditure) is only at the total level. This is described further in 3413883 - Project budget control on account level.
SAP Help also mentions that the lower level Semantic Tags used for reporting need to be assigned to ACT_COST to enable them to appear in reports such as the Project Budget Report. This is shown below:
Figure 9. SSCUI Assign Semantic Tags to Financial Statement Versions
FS Item 24 is assigned to both ACT_COST and MATCST
Figure 10. SSCUI Define Semantic Tags for Financial Statement Versions
Semantic Tag MATCST is assigned to Parent Tag ACT_COST
The Budget Control for Cost Centers has a different logic and uses GL Account Hierarchies to define the Availability Control.
In Event Based Revenue Recognition apps for Projects, Sales Orders, Services and Provider Contracts, the reported values for each item use a hardcoded link to Semantic Tags and FSV YPS2. To ensure these reports show the correct result, any changes to GL Accounts need to be reflected in YPS2.
Figure 11. Link between Billed Revenue Key Figure in app Event Based Revenue Recognition – Projects and FSV YPS2 Semantic Tag.
Further details of the relevant Semantic Tags are described in the Configuration Help for SSCUI 101878 Define Semantic Tags for Financial Statement Versions.
This relationship between the Semantic Tags and the EBRR app is also described in this excellent microlearning.
Why YPS2 Financial Statement Version is Important in SAP S/4HANA Cloud
Project Costs Report (F2513) is hardcoded to Semantic Tag ACT_COST and FSV YPS2 as described in KBA 2799100 - Fiori app 'Project Cost Report' shows zero costs.
This behaviour is also expected for other cost reports where there is no FSV selection option.
These apps are listed in SAP Help Reporting and Analysis and are dependent on the predefined Semantic Tags.
Where FSV is included in the app selection options, you have the option to work with either YPS2 or a custom alternative. Either way, the GL Accounts must be assigned to the relevant Semantic Tags for the FSV.
2482140 - Semantic Tag Related Apps or CDS Views Show No Data in S/4HANA
Hopefully you now have more insight in the role of the FSV and related Semantic Tags in S/4HANA Cloud Public Edition, particularly the hardcoded elements. You will also understand that there is a depth of functionality and integration in the standard content which can be leveraged largely out of the box.
Equally if you do require changes such as GL Account renumbering, custom FSV or even just new GL Accounts, you know the dependencies to be addressed.
I won’t give any guarantees that this Blog covers every possible dependency or relationship. There may well be further linkages which are not well documented or which exist for processes I haven’t considered. For this I apologise and please let me know any errors or omissions.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
13 | |
7 | |
6 | |
6 | |
6 | |
5 | |
4 | |
3 | |
3 | |
2 |