Starting from H1 2505 the long-awaited and urgently needed functionality of currency conversion in story reporting is available. Before it is described how to use the currency conversion object in queries and story reports, it is described how the currency conversion functionality works in Success Factors and which data manipulations are required to make the object functional for reporting.
Introduction
There are multiple use cases for the usage of currency conversions, such as e.g.
- Payments for Base Salary are paid in Euros and Bonus Payments are paid in US dollars. For the calculation of the monthly or annual salary it is required to convert all payments into a single currency. This target currency could be the “country currency”, the “Legal Entity currency” or the “Pay Component Group currency”.
- Even if all pay components are paid in a single currency (e.g. EUR) it could be possible that the pay ranges are defined in another currency (e.g. USD). For the calculation of the compa ratio or the range penetration, it is required to use the currency conversion.
- Another reporting use case is to convert all compensation amounts into one target currency that is freely entered by a report user.
The currency exchange rate is stored in an MDF object “Currency Exchange Rate”. There are a couple of aspects to consider that will become relevant for reporting:
- “Currency Exchange Rate” is effective-dated.
- There is a “Type of Currency Exchange Rate” which allows to maintain different rates for different purposes. There is a picklist for this field. However, note that “Default” is used for the “Type of Currency Exchange Rate” in the Success Factors applications (there is currently no configuration possibility to use values different from “Default” in Success Factors).
- The system allows to maintain the conversion rate in both directions; however, this is not a must.
See the example from Figure 1: In addition to the record shown in Figure 1 it is possible to maintain a record for DEFAULT-EUR-USD with any “Exchange Rate”.
IMPORTANT: Even if no opposite direction record is maintained, the system automatically calculates and uses the conversion with the inverted rate. For the example of Figure 1 it means, that a conversion from EUR to USD with an exchange rate of 1.0487 (=1/0.9536) is used. - Note that it is not possible to maintain entries where the source currency is identical to the target currency. If it is tried to post that, the error message “Exchange rate with the same source currency and target currency is not allowed” prevents saving of such records. This will become relevant later in this blogpost when the usage of the “Currency Exchange Rate”-object in reporting is discussed.

Figure 1 MDF object Currency Exchange Rate
With regard to reporting this brings some significant challenges, because simple enablement of the “Currency Exchange Rate”-object for reporting is not sufficient. In the following these challenges and the respective enhancements are explained, before some practical examples are presented how the “Currency Exchange Rate”-object with the enhanced records can be used in reporting.
Employee Profile Behaviour and Reporting Challenge
To illustrate the previously mentioned “challenges”, let’s have a look into a concrete example:
(1) See in Figure 2 the pay components in the employee profile of employee “Siva Pragadeeshadmin”: There are 3 pay components, (a) “Pay Component 3” with 777 USD (Frequency: Annual), (b) “Basic” with 4000 INR (Frequency: Half-Yearly) and (c) “Base_Salary” with 1000 EUR (Frequency: Monthly). The goal is to convert all amounts into a target currency “US Dollar” (e.g. because the Pay Component Group Sum for “PCG1_su” is configured in USD as indicated in Figure 2 in red).



Figure 2 Multiple pay components with different currencies used for employee “Siva Pragadeeshadmin”
(2) Let’s have a look what this means for the currency conversion:
- No conversion is required for “Pay Component 3” since the amount of 777 USD is already in the requested target currency.
- A record in the “Currency Exchange Rate”-object is maintained for the currency conversion of Indian rupees (source currency INR) to US dollars (target currency USD) with rate 0.001191
- See Figure 1 above, a record in the “Currency Exchange Rate”-object is maintained for the currency conversion of USD (source currency) to EUR (target currency) with rate 0.9536. However, no conversion rate is maintained for EUR to USD
(3) See Figure 3 for a simple query which connects the original amount-field (compensation-amount) with the “Currency Exchange Rate”-object. The goal would be to convert the original amounts into a “converted amount” as “compensation-amount” multiplied with the “conversion rate”. If just the “Currency Exchange Rate”-object is joined without a filter for the target currency, then you get many records: Let us assume that there are 20 conversion rates each of EUR, INR and USD into different target currencies, then the query described in Figure 3 results in 60 (=3 x 20) records for employee “Siva Pragadeeshadmin”. If now a filter is applied for target currency = USD, then only one records remains, i.e. the record for “Basic” with amount 4000 and source currency INR and target currency USD. Reason: There is no record for source currency = target currency = USD to show the record for pay component “Pay Component 3” and there is no record for source currency = EUR and target currency = USD to show the record for pay component “Base_Salary”.

Figure 3 Illustration how to join the “Currency Exchange Rate” object
Solution Approach
The “trick” which is used in this context is to create additional records in the “Currency Exchange Rate”-object. It is important to emphasize that this creation of additional records happens during report runtime; nothing is persisted on the data base. To differentiate the persisted records and the ‘artificially’ added records a new column “TYPE” was introduced (don't exchange this column TYPE with the field "Type of Currency Exchange Rate"; both fields have nothing to do with each other). The logic is the following:
- The persisted records get a label “Standard” within the column “TYPE”
- For each currency which is maintained in the instance, a record with source currency = target currency and a rate = “1” is created which get a label “Auto” in the column “TYPE”
- If no opposite direction record is maintained in the “Currency Exchange Rate”-object, the system automatically creates an additional record with the inverted rate and a label “Reverse” in the column "TYPE". For the example of Figure 1 it means, that a record with “Source Currency” EUR and “Target Currency” USD is generated with an exchange rate of 1.0487 (=1/0.9536) and TYPE “Reverse”.
Figure 4 shows how the final output looks (the records relevant for the example are shown in red).

Figure 4 Illustration of the currency exchange rate records for the 3 different TYPES “Standard”, “Auto” and “Reverse”
Practical Examples
This “enhanced” Currency Exchange Rate-object can be used in various manners. In the following some examples are presented to give report designers an idea how this could look like:
- Use case is the conversion of all compensation amounts into the legal entity currency (alternatively, it is possible e.g. to use the country currency or others).
Example: “Legal Entity Boston” has currency USD and “Legal Entity Paris” has currency EUR. Then, all compensation amounts of “Jack Miller” who is assigned to “Legal Entity Boston” are converted into USD and all compensation amounts of “Francois Bernard” who is assigned to “Legal Entity Paris” are converted into EUR.
Figure 5 shows the respective query. The conversion happens with the help of a calculated column as shown in Figure 6. Here, a query filter is used that the target currency = legal entity currency (Figure 7). Figure 8 shows the report result for the employee “Siva Pragadeeshadmin”. You can see those records from the “currency exchange rate”-object of 3 different “TYPES” that are used in the output, (1) “Auto” for the conversion of 777 USD to 777 USD, (2) “Standard” for the conversion of 4000 INR into 47.632 USD and (3) “Reverse” for the conversion of 1000 EUR into 1048.6577 USD.

Figure 5 Query for the usage of the currency exchange rate object (Legal Entity Currency = Target Currency)

Figure 6 Creation of a query calculated columns for the converted amount

Figure 7 Filter for Legal Entity Currency = Target Currency

Figure 8 Final report output with the converted amounts
- A similar idea is the usage of an input parameter as target currency, i.e. the report user can freely enter any currency as target currency and all compensation amounts are converted into this target currency.
Figure 9 shows the definition of the input parameter TargetCurrency with the default EUR, Figure 10 shows the query and Figure 11 shows the filter that is used as target currency = input parameter. Figure 12 shows the report output for employee “Siva Pragadeeshadmin” with target currency EUR. Note that one “currency exchange rate”-record of TYPE “Auto” is used while the other two records are using records of TYPE “Standard”

Figure 9 Usage of an input parameter as target currency

Figure 10 Query for the usage of the currency exchange rate object (Target Currency entered as input parameter)

Figure 11 Filter for currency as input parameter = Target Currency

Figure 12 Final report output with the converted amounts
- Both approaches described at (1) and (2) can also be achieved with data blending in a more elegant way (data blending will be available also in the "optimized user experience" later in 2025). If there are multiple amount fields which needs to be converted, the blending approach has advantages since it is not required to join the “Currency Exchange Rate” object multiple times but to use it only once and to do the conversion of the amounts in the story. The approach presented here used the currency of the Legal Entity to which the employee is assigned as target currency.
To achieve that the following steps are required:- Creation of a simplified query as indicated in Figure 13. Furthermore, it is required to create a 2nd data source just based on the “Currency Exchange Rate” object.
- The “Linking” of both data source is shown in Figure 14.
- Figure 15 shows the creation of the converted amount. Note that the amount comes from the 1st data source while the rate comes from the 2nd – ‘blended’ - data source.
- Figure 16 illustrates the creation of the final report. Note that fields of the tables come from two different data sources.

Figure 13 Main query for the blending approach

Figure 14 Linking of the two data sources

Figure 15 Story calculated measure for the converted amount

Figure 16 Report design for the usage of data blending (Legal Entity Currency = Target Currency)
- Also, with the “blending-approach” it is possible to use the target currency as input parameter. Following step are required to achieve this:
- Creation of one data source just based on the “Recurring Compensation”-object (maybe plus “Job Information” -> “Personal Information” to get the employee’s name) and one data source based on the “Currency Exchange Rate” object (plus join the “Target Currency”)
- The definition of the input parameter in the 2nd data source (see Figure 9) and the definition of a filter that the target currency is equal to the input parameter (Figure 11).
- For the linking of both data source, just the 1st condition shown in Figure 14 is required, i.e. “Compensation Currency Code” of the 1st data source equal to the “Source Currency Code” of the 2nd data source.
- The creation of the converted amount happens in the same way as indicated in Figure 15.
Conclusion
The presented approach gives an idea how the currency conversion functionality can be used in concrete user scenarios. Performance measurements have been conducted which indicates that the performance will be increased by roughly a factor of 5 compared to the scenario where no currency conversion is used at all. No significant differences have been observed if the target currency is used from the business data (Legal entity currency, country currency, pay component group currency) or entered as input parameter. The blending approach might be 20% slower compared to the direct usage of the “Currency Exchange Rate”-object in the source query; however, it is very likely that the blending approach will have performance advantages if the “Currency Exchange Rate”-object is multiply joined in the source query.
UPDATE 16.May 2025:
The join from (Source) Currency => Currency Exchange Rate => (Target) Currency which is used in section Practical Examples for use case 1 and 2 is required to allow a filter for Legal Entity Currency = Target Currency (use case 1) and Currency as Input Parameter = Target Currency (use case 2). Currently this join is considered as cyclic join and is currently suppressed in many instances. It is currently under investigation to bypass this cyclic join prevention for the Currency MDF object. As long as this bypass is not yet supported it is only possible to implement a hard filter for one particular target currency.