The ERP Central Component (ECC) Business Suite offered two choices for ledgers (leading and non-leading) and three choices for local currencies (LC1, LC2, and LC3). It included foreign currency valuation via transaction code FAGL_FC_VAL to re-valuate open items in foreign currency and general ledger (G/L) balances for non-open item G/L accounts.

These concepts have evolved throughout the SAP S/4HANA journey (from SAP S/4HANA Finance 1503 through 1511, 1605, and now 1610). At present, SAP S/4HANA Finance 1610 offers:

• Ledgers: a standard ledger consisting of a leading and non-leading ledger and an extension ledger that includes a regular and simulation extension ledger

• Currencies: You can assign up to 10 currencies (LC1 to LC 10) to a company code. Two of the 10 need to be standard SAP currency types and the remaining eight can be user-defined currency types. You can specify if the amounts for these currency types should be converted in real time or at period end.

• Foreign currency valuation with a new transaction (FAGL_FCV) that provides the earlier functionality of the foreign currency valuation transaction (transaction code FAGL_FC_VAL). In addition, it can be used to create inception postings. Inception postings are made to post the amounts for user-defined currency types at period end, if you choose not to populate the amounts in them on a real-time basis. It can also be used for creating simulation postings in the extension ledger, to simulate financial results.

Extension Ledger in SAP S/4 HANA Finance

SAP S/4HANA Finance offers an extension ledger that you can use to manage parallel reporting based on multiple accounting principles, such as International Financial Reporting Standards (IFRS) and local Generally Accepted Accounting Principles (GAAP). The advantage with the extension ledger is that every financial posting to the underlying ledger is not physically replicated into it.

The extension ledger gives the same end result as a non-leading ledger, together with significant savings in disk space. It is to be used when the number of differential postings between the two accounting principles is at a minimum. This concept has already been discussed in the Financials Expert article “How to Use the Extension Ledger Functionality in SAP S/4HANA Finance” published in April 2016, and holds good until SAP S/4HANA 1511.

As of SAP S/4HANA Finance 1610, there can be two types of extension ledgers–the regular extension ledger (as in SAP S/4HANA 1511) and a simulation extension ledger (the new one). Either of them has to have an underlying ledger.

While the purpose of the regular extension ledger has already been explained in the referenced article in April 2016, we now explain what the new simulation extension ledger is all about.

As the name indicates, this category of ledger is meant for simulation postings. The simulation postings can be made out of the foreign currency valuation run (transaction code FAGL_FCV). Without making the actual posting out of the production run, you can now write a posting into the simulation extension ledger. These postings can then be used to simulate the financial results based on the postings made in the underlying ledger and simulation postings created out of the foreign currency valuation (FCV) run.

Let’s now see the why and how of the simulation extension ledger.

 The postings created out of simulation runs:

• Can be used to analyze the implications of various exchange rates on different currencies
• Can be used for predictive analytics

The simulation ledger is a placeholder to temporarily hold foreign currency valuation postings, to help you simulate the financial results, as shown in Table 1. This feature comes in handy to those organizations that have a massive number of transactions in non-local currency. Later, we will show how the simulation postings are performed.

As you can see in Table 1, there is an open item worth $100M at the end of the period.

Three simulation runs were created out of the FAGL_FCV program, which created three postings into the simulation ledger S1. Each time, the business could comfortably check the impact on financial results as $101M, $ 101.1M, and $ 101.4M respectively, using the simulation ledger S1.

Finally, the production run of FAGL_FCV created a posting for $ 1.6M in the leading ledger 0L. At this juncture, the simulation ledger is neutralized. It no longer holds the simulation postings. The financial statement created out of ledger 0L now shows the revalued open item finally reported at $101.6M.

To summarize:

• Simulation postings out of FAGL_FCV can be created and deleted as many times as you like before the actual postings are made out of the production run.
• The postings out of simulation runs are created using an alphanumeric document number, beginning with S (e.g., S000000001). To view this document use transaction code GD22.
• The history of simulation runs is stored in table FAGL_BSBW_HISTSM.
• Should you choose to repeat the simulation run, you can delete the results of earlier simulation runs. If not, only the delta postings from the previous simulation run are made.
• The actual posting (into the leading or non-leading ledger) out of the production run from FAGL_FCV automatically deletes the simulation posting.

How to Set Up the Simulation Extension Ledger

The customizing task to set up the simulation extension ledger is similar to the regular extension ledger. Apart from defining the ledger, there is no other customizing to be done. You set up the ledgers in SAP S/4HANA using transaction code FINSC_LEDGER, which leads you to the screen shown in Figure 1.

Figure 1

Ledger definition in SAP S/4HANA

Click the New Entries button and create the entries as highlighted in Figure 1. In this example, extension ledgers E1 and Z1 are created.

To create these ledgers:

• Type E1 and Z1 in the Ledger column
• Enter a description in the Ledger Name column
• Choose the Extension Ledger option from the drop-down list of options in the Ledger Type column
• Specify the Underlying Ledger as 0L
• For the E1 ledger, choose the drop-down option Simulation Extension Ledger in the Extn. Ledger Type column
• For the Z1 ledger, choose the drop-down option Extension Ledger in the Extn. Ledger Type column
• After entering these details, save (CTRL+S) these entries.

How the New Currency Architecture Relates to the Foreign Currency Valuation Process

The currency architecture in SAP S/4HANA has been evolving with every release, with significant changes from Simple Finance On-Premise 1503 to SAP S/4HANA 1511 to SAP S/4HANA Finance 1610. The currency architecture is changing to cater to multiple/functional currency reporting, which was covered in the article “Plan Your SAP S/4HANA Finance Implementation with an Understanding of Multicurrency Architecture” by Muralidharan Sethuraman.

Table 2 sums up how the currency architecture differs among various versions.

Different Options to Set Up the User-Defined Currency Types

The customizing task to set up the currency settings can be carried out from the same transaction code (FINSC_LEDGER) in the various versions of SAP S/4HANA. There is a combined view cluster for currencies and ledgers.

The user-defined currency types, as mentioned in the Table 2, can now be set to have real-time conversion. If the real-time conversion is active, the amounts in the user-defined currency types are populated automatically with each posting. In the direct FI postings or the postings that happen through an interface (materials management [MM] or sales and distribution [SD], for example), the amounts are always balanced (i.e., debits are equal to credits even for the user-defined currency types). But what happens with the follow-on processes such as clearings, settlements, and allocations? Let’s discuss that now.

In the follow-on processes, the amounts in the follow-up postings must be same as the original postings so that the balance is zero for all currencies. For example, when you do payment clearing, the customer or vendor line item must have the same amounts as the amounts posted at the time of invoicing for all currencies. Otherwise, even after the clearing, there may be balances left over in some currencies (currency types).

As of now, we can say that SAP system functionality is evolving in this area. A perfect zero balance in the user-defined currency types is supported only for some processes (denoted with Y in Table 3). However, with future releases, the scope will be expanded to support all other processes (denoted with N in Table 3).

Until the time the perfect zero balance is supported for the follow-on processes, they can be managed with a work-around solution, as you will see. We use the example of an internal order settlement to explain the workaround.

Use the Currency Conversion Settings and a New FCV Program to Achieve a Perfect Zero Balance

This section of the article has two objectives:

• To create simulation postings for the simulation extension ledger
• To create inception postings to achieve zero balances for the follow-on processes in a user-defined currency

Step 1. Create user-defined currency types. Use transaction code FINSC_LEDGER to display the screen shown in Figure 2.

Figure 2

Create user-defined currency types in SAP S/4HANA

Click the New Entries button and create the user-defined currency types as shown in Figure 2.

In our example, we create the currency types Z1 and Z2. To create the entries:

• Enter the currency types as Z1 and Z2 in the Currency Type column
• Enter a description
• Choose the drop-down option Company Code-Specific in the last column. You can set up currency types with other options in this column, but that is not the objective of this article.

Step 2. Define real-time conversion settings for the user-defined currency types. Since we set up the user-defined currency type to be company-code specific, we show how these currency types are set up for company code 2000. Again, you execute transaction code FINSC_LEDGER, and in the screen the system displays, click the Currency Conversion Settings for Company Codes folder on the top left, as highlighted in Figure 3.

Figure 3

Define the real-time conversion settings for user-defined currency types

In our example, we set the Currency Type Z1 not to have real-time conversion and Currency Type Z2 to have real-time conversion as indicated in the Real-Time Conversion check boxes.

Step 3. Make two expense postings into an internal order, each at a different exchange rate. In our example:

• Debit the expense account 400120 and credit the balance sheet account 200120
• Company code currency is GBP, global currency is EUR, user-defined currency 1 is USD, and user-defined currency 2 is INR

The postings reflect in table ACDOCA, as shown in Figure 4. Use transaction code SE16 to display table ACDOCA.

Figure 4

The manual FI postings made to an internal order, as reflected in table ACDOCA

In this figure, you can see that the user-defined currency codes are populated in the Currency Fields as USD and INR. However, in the corresponding Amount fields, Currency 1 amounts are blank and Currency 2 Amounts are populated. This is because the currency types Z1 and Z2 are set up accordingly in Figure 3.

Step 4. Settle the internal order to GL 200199 using transaction code KO88 (not shown here). Before the settlement of the internal order, the exchange rate for local currency to user-defined currency 2 (GBP-INR) changes again.

Figure 5 shows how table ACDOCA looks after the settlement.

Figure 5

Table ACDOCA after the settlement

As you can see in Figure 5, there is a balance of 8000 GBP left over in user-defined currency 2 after the settlement is done. This is because the settlement for user-defined currencies does not happen at historical exchange rates. Rather, the amount is converted using the exchange rate on the day of settlement.

Amounts in user-defined currency 1 are still blank, because the Z1 Currency Type is not set for real-time conversion. Amounts in local currency and global currency are perfectly balanced to zero, because settlement takes place at historical exchange rates.

This demonstrates what the real-time currency conversion settings do. This also demonstrates, as shown in Table 3, that some of the follow-on processes such as settlement don’t ensure a zero balance for user-defined currency types.

We shall now see what to do with amounts in user-defined currency 1, as they still continue to be zero. For this, we use the new FCV transaction code FAGL_FCV.

Step 5. Set up valuation areas. Before you can perform the FCV, you have to set up the relevant valuation areas. This has also slightly changed as of SAP S/4HANA 1610.

The valuation areas were traditionally set up only for re-measurement runs at the month end, using the closing rate. However, with SAP S/4HANA Finance 1610, you can set them for:

• Inception postings (to calculate and populate the amounts for Z1 Currency Type, using an M [average] rate)
• Re-measurement run (to re-valuate open items for all currency types, using the closing rate)

Follow IMG menu path Financial Accounting (New) > General Ledger Accounting (New) > Periodic Processing > Valuate > Define Valuation Areas. Two valuation areas must be set up, as shown in Figure 6. You can see that a new field has been added in the valuation area to designate it for inception postings.

Figure 6

Valuation areas for inception and re-measurement runs

In our example, we created the valuation areas IC and RM. 

• Since we intend to use the IC valuation area to create inception postings for currency type Z1, we assigned the currency type Z1 in the third column, and in the seventh column, which is a new field in this screen, select the drop-down option 1 – Valuation Area for Inception Postings.
• The valuation area RM is created for the regular re-measurement run. Hence, we have not assigned any currency types against this valuation area.

The valuation areas must be assigned to a valuation method and accounting principles. The accounting principles are assigned to the ledger groups, as before. Therefore, that is not included in this article.

Step 6. Perform the FCV run using transaction code FAGL_FCV. This takes you to Figure 7, which has a good number of changes.

Figure 7

The initial screen of the foreign currency valuation transaction (FAGL_FCV)

Note these differences:

• Separate tabs for Open Items in Subledger (i.e., customers and vendors) and Open Items: G/L Accounts
• Option for a Test Run
• Option to create and delete the simulation postings (P_SIMU and P_DELIND)
• The posting to FI-GL is no longer a batch process, but can be posted in real time. Hence, the option to create a batch input session no longer exists on the screen.

Step 7. Perform the FCV run to create inception postings. Use Valuation Area IC to create inception postings and populate amounts for user-defined Currency Type Z1. Before creating the postings, do a simulation and see how the simulation extension ledger (E1) is updated. Make the entries in the foreign currency valuation transaction (FAGL_FCV) as shown in Figures 8 and 9.

Figure 8

Select the option to create simulation postings

Figure 9

Specify the G/L accounts to be valuated

In our example, we entered the following values in Figure 8:

• Company Code = 2000
• Valuation Key Date = 30.06.2017
• Valuation Area = IC. (This option will create the inception postings.)
• Choose the radio button P_SIMU. (This option will create the simulation entries for the inception postings.)
• P_SIMLDG = E1 (The simulation extension ledger E1 has been specified here.)
• The indicator P_DELIND is left unchecked. This is to be used in case you want to delete any previously created simulation postings.

In Figure 9, we entered the three G/L accounts used in our example. You can add them manually one by one or select them from the drop-down choice.  G/L 400120 and 200120 were used during posting to the internal order and G/L 200199 is the settlement receiver for the internal order. Note that you can also leave the G/L accounts blank, and select the check boxes Valuate GL Acct Balances and Valuate P&L Accounts, in which case all the G/L accounts will be revaluated.

Step 8. Execute the inception run in simulation mode. After you perform the inception run in simulation mode, the proposed inception postings (in Ledger E1) are shown in Figure 10. The system considers this run as the inception posting run because the valuation area IC is used.

Figure 10

The G/L accounts to be valuated are specified here

The amount in Local Currency 1600 GBP (850+750 GBP) as shown in Figure 4, multiplied by an exchange rate of 1.5 to USD, results in a USD amount of 2.400.

You can also see these postings updated in table ACDOCA for ledger E1 (Figure 11). Use transaction code SE16 to access table ACDOCA.

Figure 11

The simulation postings as updated in Ledger E1

As you can see in Figure 11, simulation postings are updated in ledger E1 using an alphanumeric document number. The amounts in all other currencies are zero. Only the amounts in user-defined Currency 2 are displayed.

There are four simulation documents posted. You can interpret them as:

• Document S00000021is posted for G/L 200120
• Document S00000022 is posted for the Settlement Receiver G/L 200199
• Document S00000023 is posted for primary postings into G/L 400120 (posted from F-02)
• Document S00000024 is posted for settlement postings into G/L 400120 (posted from KO88)
• The Offset in all the documents is posted to G/L 230000 or 280000. These G/L accounts are assigned against transaction key KDB in transaction OBA1. (Showing transaction OBA1 is not in the scope of this article.)

This concludes the demonstration of the first objective of this section of the article, which is to create simulation postings for the simulation extension ledger.

Step 9. Perform a production run of transaction code FAGL_FCV. This action displays the screen shown in Figure 12. To perform a production run, choose the option Post Valuation Immediately instead of P_PSIMU. All other entries such as Company Code, Valuation Key Date, Valuation Area, and the G/L accounts in the G/L Account Balances tab remain the same as specified for the simulation run in step 7 of this article (refer to Figure 9).

Figure 12

Settings for FAGL_FCV to perform a production run

It posts the following documents shown in Figure 13, as updated in table ACDOCA.

Figure 13

Inception postings updated in table ACDOCA

As you can see in Figure 13, four inception postings are made in the FI-GL, populating the amount in the user-defined Currency 1. Now let’s apply a filter (CTRL+F5) in Figure 13 for G/L 400120 and see if there is a balance left over in user-defined Currency 1.

As you can see in Figure 14, in the user-defined Currency 1, there is a perfect balance of zero, as the inception postings for both debits and credits in G/L 400120 were created at the period end, using the (same) average exchange rate. However, there is still a balance left over in the user-defined Currency 2 even after settlement.

Figure 14

Final balance for G/L 400120 in table ACDOCA for all currencies

With this, you now know that if the user-defined currency types are set for non-real-time conversion and subsequently coupled with the new feature of inception postings, that can help you achieve the zero balance in a multi-currency reporting scenario.

This concludes the demonstration of the second objective of this section of the article, which is to create inception postings to achieve a zero balance for the follow-on processes in a user-defined currency.

A look at table ACDOCA and ledger E1 now shows that there are longer any simulation postings in it. This is because the simulation postings lose their purpose once the production run is performed. Hence, they are deleted automatically from table ACDOCA.

Use transaction code SE16 to access table ACDOCA (Figure 15).

Figure 15

Check the number of entries in ledger E1 after the production run

You can notice that the number of entries in the simulation extension ledger E1 are now zero. This is because the simulation entries are automatically deleted, when the production run is performed.

Step 10. Perform the re-measurement run of FAGL_FCV, using the Valuation Area RM, after you complete the inception run of FAGL_FCV. (This remains the same as before. Hence, this is not in the scope of this article.)

In this article, the key takeaways for you are:  

• You can define up to 10 currencies in SAP S/4 HANA 1610, eight of which can be user-defined.
• The user-defined currency types can be set up for real-time conversion or otherwise.
• The simulation extension ledger is used to store simulation postings.
• The simulation postings are created out of the new FCV transaction code.
• The new FCV transaction code also offers to create inception postings.
• The inception postings are created for the user-defined currency types that are set for non-real time currency conversion.
• Not all business processes currently produce a perfect zero balance after the follow-on processes. You can expect more in this regard with the future releases of SAP S/4HANA.

Ajay Maheshwari

Ajay Maheshwari is an SAP Finance and Controlling (FI/CO) and SAP S4/HANA solution architect with more than 13 years of experience. He is well known for his contributions to the SAP Community Network (SCN) Forum.

He is among the all-time top 20 contributors to the SCN Forum, across all SAP modules and one of the top contributors in his own space, SAP FI/CO.

He is one of the official SAP mentors and has been recognized as the topic leader in the SCN Forum each year since 2011. 

He has experience with SAP implementations and rollouts in several industries and thoroughly enjoys designing complex business processes and delivering SAP training in the areas of FI/CO and SAP S/4HANA.

Currently, he works as associate director at itelligence, an SAP Platinum Partner.

You may contact the author at ajaycwa1981@gmail.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.

Kavita Agarwal

Kavita Agarwal is an SAP FI/CO and SAP S/4HANA solution architect with more than 16 years of experience. She is well known for her contributions to the SAP Community Network (SCN) Forum and is a platinum level contributor there.

She has experience with medium- to large-sized SAP implementations and rollouts in several industries and geographies and has been part of major finance transformation programs in the chocolates and confectionary industry. She enjoys designing complex business processes and delivering SAP training in the areas of SAP FI and SAP S/4HANA.

Currently, she works as an independent consultant helping customers optimize their SAP systems to derive maximum benefits out of their SAP investments and also offers e-learning solutions in SAP FI/CO.

You may contact the author at kaviag06@gmail.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.