Skip to Content

Introduction

Valuation areas in FI are used mostly in Foreign Currency Valuation. Unlike in classic GL in new GL they became mandatory in FCV. The usual approach is to create a valuation area per legal requirement – mostly represented by a country GAAP. Following such approach in an international company that operates in large number of countries would end-up in creating tenths of valuation areas.

The maintenance of it, variant creations for each country, complexity of description in user manuals would be quite uneasy.

Theoretically creating one valuation area per country should be enough – in the practise surely exceptions like in Turkey – where open items / GL balances except bank accounts must be valuated with buying rate and the bank / cash accounts must be valuated based on effective buying rate – would extend the number of needed valuation areas extensively and the approach of using a valuation area representing a country would already have some exceptions.

As we all know exceptions make the SAP world brighter but there is a way to limit the exceptions in terms of valuation areas.

Considerations

Valuation areas have an valuation method assigned, which indicate (among others) which FX rate type is used for valuation.

This concepts assumption is that an international company has 2 valuation requirements –  one for group valuation and one for local valuation (accordingly to each country GAAP).

The group valuation follows EUR currency and ECB FX rates. ECB only publishes FX rates based on EUR but the valuation must be also able handle non-EUR-based currency pairs like USD/PLN – for which cross-FX-rate calculation can be used.

Local valuation is based on each National Bank FX Rate or ECB if country is based in EUR-zone.

Concept

There are 4 possible valuation procedures in SAP:

  • Lowest Value Principle
  • Strict Lowest Value Principle
  • Always Evaluate
  • Revalue only

This actually means that, in very lean version, maximum 4 valuation areas – one per procedure should be enough to fulfil all local GAAP requirements.

In each of these valuation areas only one FX Rate type would be maintained. Theoretically under that one FX rate type all required FX from each country can be maintained. However, reading and selecting / checking the FX rates, when these are maintained under only one FX rate type, is not easy for regular accountants. That is the point where alternative FX rate can be used.

For all valuation methods the same FX rate type would be assigned, which in this example will be named as ‘CLLL’. For each FX pair an alternative FX rate type representing the national bank FX rate.

Illustrating it in an example:

Having USD/ PLN currency pair would result in creating pair under 2 FX rate types:

USD/ PLN in CLLL and alternative FX rate CLPL.

USD/ PLN in CLPL without alternative FX rate.

In such processing system will first access the USD/ RON in CLLL (assigned to valuation method) and using the alternative FX rate it will read the FX rate using CLPL rate type.

Such settings also enable using the reference currency for cross-currency calculation in 100% secure way – it is made sure that the cross-rate is calculated only based on one set of FX rates. Such cases can happen when a country can decide which FX can be used – like in Hungary, where company can choose between using ECB or Hungarian National Bank. In Hungarian case for an USD document there is no FX rate published officially by ECB – in such case it must be calculated using cross-rate scenario.

Rollout settings are basically restricted to only creating new currency pairs  – without having a need to create a new valuation area.

Customizing

The customizing will only show how to configure local valuation areas – setting for group valuation are following the same way but they do not require alternative FX rates to be used.

In example customizing 3 countries would be used: Germany and Hungary using ECB FX and Poland using Polish National Bank.

At first the currency types used in valuation method should be defined. Following the concept 3 currency types are defined:

Path SAP NetWeaver –> General settings –> Currencies –> Valuate
Transaction OB07 – Check Exchange Rate Types

Now the translation rates can be defined.

Path SAP NetWeaver –> General settings –> Currencies
Transaction OBBS – Define Translation Ratios for Currency Translation

 

At first the main FX rate must be used to reference the alternative FX rate:

Then per National Bank the target FX translation rates are defined:

  • For Poland

  • For European Central Bank

For cross-rate calculation the currency pairs must also be updated in the customizing (like USD/HUF)– no FX entry is needed.

Having the FX rate customizing done valuation areas can be set up, starting with creation of valuation methods:

Path Financial Accounting (New) –> General Ledger Accounting (New) –> Periodic Processing –> Valuate
Transaction Define Valuation Methods

 

There are 2 accounting rules – in Germany only loss can be shown, Poland and Hungary should show both gain and loss from FX valuation. For this 2 valuation method would be needed.

Valuation Method Valuation principle
LGL Local valuation: Gain and Loss – Always evaluate
LLO Local valuation: Loss only – Lowest Value Principle

 

Based on that the valuation areas can be created:

Path Financial Accounting (New) –> General Ledger Accounting (New) –> Periodic Processing –> Valuate
Transaction Define Valuation Areas

 

In this example following valuation areas for vaulting currency type 10 are created:

Valuation Area Valuation principle
LA Local valuation: Gain and Loss
LO Local valuation: Loss only

Having valuation areas defined they should be assigned to accounting principle representing a ledger:

Path Financial Accounting (New) –> General Ledger Accounting (New) –> Periodic Processing –> Valuate
Transaction Assign Valuation Areas and Accounting Principles

Basic settings for valuation areas are completed then.

To finish settings the account determination would be needed – it can be valuation-area-dependent or not. Both ways are supported and by that the ledger and accounts approach are supported. This can be done using (in ECC):

Path Financial Accounting (New) –> General Ledger Accounting (New) –> Periodic Processing –> Valuate –> Foreign Currency Valuation
Transaction OBA1 – Foreign Currency Valuation

 

Here is a sample customizing of accounts for KDF – ‘Exchange Rate Dif.: Open Items/GL Acct’ type without using a valuation-area dependent entries:

Valuation-area dependent entries can be done using:

Having account assignment made customizing made the valuation areas customizing is finished. However, there are also additional settings which enable showing valuation values in line item reports like FBL1N/ FBL5N or FBL1H and FBL5H:

Path Financial Accounting (New) –> General Ledger Accounting (New) –> Business Transactions –> Closing –> Valuate –> Valuations
Transaction OB_9 – Determine Values for Line Item Display

Here to the valuation fields used in structure RFPOSXEXT can be assigned to valuation areas:

These fields must also be defined as special fields in the line item display (table T021S – see note 984305 for more details):

Example

The example shows valuation of companies existing in 3 abovementioned countries.

FX rates of ECB and Polish National Bank were maintained:

The documents were posted with different FX rate than used in valuation.

Valuation run done for each country:

  • Germany – loss only- valuation area LO

Valuation is performed with the FX rate entered in OB08 (it’s converted from indirect to direct in this example) for currency type CLEB for USD/EUR FX rate:

  • Hungary – always evaluate – valuation area LA

Valuation is performed with FX entered in OB08 for currency type CLEB and one cross-rate calculation for USD/HUF currency pair that is not provided by ECB:

System calculated an cross-rate for USD/HUF by using formula based on EUR currency (entered as reference in CLEB):

325,1 / 1,1318: 287,2415

  • Poland – always evaluate – valuation area LA

Valuation is performed with FX entered in OB08 for currency type CLPL:

As it can be seen one valuation area can provide different values if we set it up in a generic way.

Once valuation is posted the results of it can be seen in FBL1N/ 5N in column ‘Valuation Difference’:

The highlighted columns contain the FAGL_FCV result shown in each valuation area.

Further thoughts

The above examples shown that restriction of valuation areas is possible and brings a number of benefits:

  1. Easy-to-monitor if all companies made the Group and Local FX valuation
  2. No constant changing of User Manual
  3. Simplified rollout settings
  4. Uncomplicated maintenance – only if new cross-rates are needed

On the other hand there are some constraints and some follow-up settings that must be kept if this approach is chosen:

  1. If multiple currencies are used in S4HANA then one valuation area can only handle 3 – they would however use the same currency type
  2. If you use currency translation and want to use the same valuation area then there must be one financial statement version that handles all requirements for currency translation
  3. If in a country has two or more officially published rates are used for valuation (for example different for bank accounts and different for open items) then another generic valuation area must be created

 

Which approach to valuation areas have you chosen in your companies?

Marek

To report this post you need to login first.

1 Comment

You must be Logged on to comment or reply to a post.

Leave a Reply