Freely-Definable Currency and Financial Statement Version (FSV) Setup

By James Stupple, SAP FICO Consultant, delaware United Kingdom

Global SAP customers often have a need for an operational currency that differs from the national currency their legal entity(s) resides in. To reconcile this discrepancy, SAP customers have, in the past, created mirror company codes, used special ledger, or performed currency conversion/translation in a data warehouse (i.e. SAP BW/BPC) to support their reporting needs. In those cases where a company code’s operational currency was USD and the group currency was also USD, then group currency was used for operational reporting. None of these workarounds are ideal. Beginning with the release of SAP S/4HANA 1709 EX edition, SAP introduced the concept of freely-definable currencies.* Up to eight uniquely separate currencies could be created to meet the most complex customer currency needs.

*Note: Freely-definable (functional) currency is now a standard offering as of SAP S/4HANA 2002 ES, and previous unsupported features such as CO allocations are now fully supported with this currency feature, including with the SAP S/4HANA 1909 EX and SAP S/4HANA On-Premise releases. With each new release, freely definable currency has become more prevalent not only at the individual transaction level as a selectable currency view, but also in standard reports for display purposes. SAP’s new Group Reporting solution for consolidations also supports functional currency.

In this article, we highlight how to use only one freely-definable currency, technically called freely-definable currency 1 in SAP. This solution deprecates the ‘old’ methods of meeting a company’s functional currency needs and is applied to a new SAP greenfield implementation. The article will also refer to freely-definable currency as functional currency for the remainder of the piece, explaining how the new SAP feature was used to solve the functional currency paradox for a recent global implementation.

By James Stupple, SAP FICO Consultant, delaware United Kingdom

Global SAP customers often have a need for an operational currency that differs from the national currency their legal entity(s) resides in. To reconcile this discrepancy, SAP customers have, in the past, created mirror company codes, used special ledger, or performed currency conversion/translation in a data warehouse (i.e. SAP BW/BPC) to support their reporting needs. In those cases where a company code’s operational currency was USD and the group currency was also USD, then group currency was used for operational reporting. None of these workarounds are ideal. Beginning with the release of SAP S/4HANA 1709 EX edition, SAP introduced the concept of freely-definable currencies.* Up to eight uniquely separate currencies could be created to meet the most complex customer currency needs.

*Note: Freely-definable (functional) currency is now a standard offering as of SAP S/4HANA 2002 ES, and previous unsupported features such as CO allocations are now fully supported with this currency feature, including with the SAP S/4HANA 1909 EX and SAP S/4HANA On-Premise releases. With each new release, freely definable currency has become more prevalent not only at the individual transaction level as a selectable currency view, but also in standard reports for display purposes. SAP’s new Group Reporting solution for consolidations also supports functional currency.

In this article, we highlight how to use only one freely-definable currency, technically called freely-definable currency 1 in SAP. This solution deprecates the ‘old’ methods of meeting a company’s functional currency needs and is applied to a new SAP greenfield implementation. The article will also refer to freely-definable currency as functional currency for the remainder of the piece, explaining how the new SAP feature was used to solve the functional currency paradox for a recent global implementation.

Then to Now: Currencies in SAP

Before the concept of freely-definable currencies was introduced by SAP, SAP solutions contained only three currencies:—transaction, local, and group currency. These options didn’t fully meet customer needs. In a recent project, a US based multinational required their operational currency for a legal entity in the UK to be US dollars (USD), rather than the country/national currency of British Pounds (GBP). Customers often refer to this as their functional currency in which they operate, transact, and report. Nevertheless, this customer still needed to produce financial and managerial reporting in both local currency and functional currency, a common requirement for SAP customers with international operations.

SAP’s Best Practices recommendation is to always set the company currency as the national currency. The reason for this was highlighted most recently when the European Union was formed and countries throughout the region adopted the Euro as their standard currency, switching from Deutschemarks in Germany or French Francs in France, for example. SAP supported the conversion to the Euro for its customer base by providing standard procedures and programs to follow, subsequently ‘shifting’ its customer base to operate with the new national Euro (EUR) currency rather than the previously existing country specific currencies.

For SAP customers who had a country (national) currency that differed from what was expected by SAP, the process noted was not supported as standard. Currency changes can happen at any time as country policies change. Although Brexit didn’t result in the UK reverting its currency to GBP since it never adopted the Euro, this scenario highlights that significant changes can happen unexpectedly that may include a currency update. SAP supports these changes as standard so long as customers follow SAP Best Practices for currency assignment upon initial configuration of their system.

Today, it’s equally as important to get one’s enterprise organizational structure configured correctly at the outset of your SAP project, as it is to configure functional currency before any transactional data is posted in the system. This means that the organizational hierarchy template used for new SAP implementations must include functional and national currency for ensuing configuration. Flexibility exists to delete transactional data in non-production SAP S/4HANA On-Prem and SAP S/4HANA EX environments if the currency settings are initially performed incorrectly, but this should be avoided as it is very disruptive, if not impossible for an ongoing roll-out. Finance and non-finance streams are all impacted by removing ‘test’ transaction data. Deletion of transactional data is not supported in the SAP S/4HANA ES starter, quality or production systems.

Downstream Impact of Configuring and Using Functional Currency

The standard month-end process of performing currency revaluation and translation, as well as the configuration to support these activities, is directly impacted by a company’s decision to use functional currency. For consistency and correctness purposes, national currency should continue to be assigned as the local currency for each company and company code, and functional currency should be established in addition for every company code. If a company’s national and operational (functional) currency are the same, they should be configured as such. Next, each company code and the associated lead and non-lead ledger(s) should have the functional currency assigned correctly as shown via screen shots later in this article.

Revaluation and Translation configuration and setup will also be addressed. In particular, Valuation Area configuration is highlighted because unique setup is required to ensure revaluation and translation to group currency is performed correctly during month-end using the functional currency as the basis where needed. Local currency, which was historically the source currency to perform group currency updates from, is no longer needed as the foundation for revaluation of the balance sheet and translation of the income statement for those company codes having a different local and functional currency type, a significant change for customers performing and reporting on these activities.

Revaluation and Translation

With the addition of freely definable currency in SAP Finance the complexity of currency processes such as translation and revaluation has increased with the addition of new input parameter fields and the need for additional valuation areas. Most multinational businesses require foreign currency revaluation and translation in multiple currencies. This article shows how to set up translation and revaluation correctly to allow general ledger accounts to adjust into themselves instead of a separate income statement or balance sheet account. Currency translation is driven from the financial statement version, and in particular the financial statement item. Previously, if you wanted to adjust a GL to itself or an associated F/X adjustment account you would have to setup a separate node on the FSV for every GL account as this was the only way to create a separate FS item to configure.

Let’s explore the details and correct usage of SAP’s new freely-definable currency first followed by the setup of the Financial Statement Version (FSV) used for revaluation and translation.

Sample Configuration

Part 1: Set Up Functional Currency

Part 1 outlines the functional currency setup and later assignment to the ledgers in use by a customer. The configuration can be found at the following IMG menu in Figure 1.

Figure 1—Define settings for ledgers and currency types

 

 Step 1

Each national currency associated with an SAP customer’s legal entities is set up as a ‘Z’ currency type which will later serve as the functional currency. Usage of a ‘Z’ currency type aligns with SAP’s recommended naming convention for customer configuration objects. See settings in Figure 2.

Figure 2—Define currency types

 

Step 2

The next step is to assign the source currency for each currency type and exchange rate settings for currency conversion purposes. See below where source currency is set as ‘00’ document currency for functional currency – USD only (see Figure 3). This is because the only scenario for the customer where functional (operational) currency was USD and differed from the national currency was for those entities that operate in USD. The net effect of this configuration is that financial posting amounts for all non-ZZ functional currencies are equivalent for the local currency and functional currency.

Figure 3—Define currency conversion settings

 

Step 3

Currency conversion settings for company codes is standard as shown in Figure 4.

Figure 4—Establish currency conversion settings

 

Step 4

Next, the company code settings for each ledger must be assigned the functional currency as shown in the Step 4, Step 5 and Step 6 by first selecting the ledger, then performing the company code settings. See the configuration in Figures 5-7.

Figure 5—Define ledger settings

 

Step 5

Company code ledger settings require the assignment of the freely-definable functional currency to be assigned to every company code based on what the operational currency is for each (Figure 6). In most cases this equals the national currency of the company code.

Figure 6—Assign freely-definable currencies to company codes

 

Step 6

See the resulting currency settings at the company code level (Figure 7).

Figure 7—Display company code currency settings

 

Part 2: Financial Statement Version

Part 2 of this process is to walk through the financial statement version as this takes intricate and time-consuming configuration that is critical to the process.

Step 1

There is a requirement for a separate FSV to be created for currency translation purposes. This is in addition to the standard FSV for financial statement creation. See the following two examples:

The first example is the standard FSV for financial reporting of the trial balance, as shown in Figure 8.

Figure 8—Display financial statement version settings

 

The second is the specific FSV created for translation requirements (Figure 9). We will explore and explain the setup of this FSV further.

Figure 9—Display/change financial statement version settings

 

Step 2

If you click ‘Financial Statement Items’ above you can access the structure of the FSV (Figure 10).

Figure 10—Create items for financial statement version

 

For the translation configuration to work every general ledger account for translation requires its own node on the FSV. As an example the ‘Initial TB Offset’ node will only have one GL account assigned. The reason for this is Translation configuration is driven by Financial statement item, hence if the GL account is to adjust into itself you need an FS item for each GL. Note that accounts that are open item managed, auto-post only, or bank accounts cannot translate nor revalue into themselves, but instead are translated and revaluated into an associated foreign exchange adjustment account

Part 3: Currency Revaluation

The second aspect to cover, and the more simple of the two, is currency revaluation. In order for the revaluation adjustments to feed back into the original GL account go to the following configuration path.

Step 1

The IMG path is demonstrated in Figure 11.

Figure 11— Prepare automatic postings for foreign currency valuation

 

Once here click on Exchange Rate Dif.: Open Items/GL Acct (Figure 12).

Figure 12—Display exchange rate difference transaction

Step  2

We can now correctly configure each GL account that requires currency revaluation (Figure 13).

Figure 13—Change view for foreign currency revaluation at G/L account level

 

Double click into a GL account to configure (Figure 14).

Figure 14— Update G/L revaluation account determination

 

The two GL accounts shown in the boxes are the same hence the GL account adjustment from revaluation will be posted back into the same GL account or an associated F/X adjustment account such as for sub-ledger accounts that cannot be directly posted to as noted previously.

Next, we look at the valuation areas and valuation methods. Four valuation areas are configured for our purposes (F1, FP, FZ, and TR) with the associated currency types as shown in Figure 15. Figure 16 shows the settings behind Valuation Method FP00 as an examples. FP01 only differs in the rate type used which was a custom configured monthly average rate specific to translation.

Figure 15—Maintain valuation areas

Figure 16—Configure valuation method

Part 4

The final part is how to setup the currency translation following on from the FSV setup.

Here is a view of the translation configuration and it now becomes clear why you need a node for each GL account you wish to adjust into itself (Figure 17).

Figure 17—Configure translation account determination by exchange rate type for FSV

 

For example, if we look at the two areas highlight above, financial statement item 10 will have one GL account assigned to it in the FSV (21100010). Without the initial setup of the FSV you cannot single out one GL account by FSV Item.

Shown in Figure 18 you can see one GL account per FS item.

Figure 18—Display FSV

 

All these steps together allow you to correctly setup currency translation and revaluation to adjust back into the balance sheet account or P&L account based on customer requirements.

Part  5

The following contain some examples of the variants used for revaluation and translation. Revaluation is shown in Figure 19 where a total of three variants (of those shown) were used to correctly revaluate the local and functional currency amounts as required, using the three different valuation areas F1, FP, and FZ.

Figure 19—Sample revaluation variants

 

Translation variants are shown in Figure 20. A separate variant was set up for all non-USD entities for the balance sheet and income statement with the Currency and Cur. Type Functional Currency fields populated accordingly.

Figure 20—Sample translation variants

Wrapper Program and Concluding Comments

Due to the higher number of revaluation and translation runs required when using functional currency for every company code, the last activity was to create a wrapper program that performed the following:

1. Execute revaluation in successive order for each variant created for USD based entities and post to the lead ledger and associated ledger group, and for the Non-USD entities also posting to the lead ledger and associated ledger group, to revalue from the transaction currency to the functional currency without updating the functional currency.
2. Execute translation in successive order for each variant created so every functional currency is translated to USD. Companies with USD local and functional currency do not have to be translated.

The postings generated from execution of the ABAP-based wrapper program was the revaluation and translation were both performed correctly and reflected in the local, functional and group currency accordingly in the lead ledger and non-lead ledgers. Reconciliation of expected results versus actual results was performed to validate the accuracy of the setup and to confirm the overarching design described met the customer’s functional currency posting and reporting needs. Once a company has a stable month-end process with pre-defined timing of each task, a batch schedule can be used instead of the wrapper program to sequentially establish each revaluation and translation run with its associated variants.