Multinational organizations may consist of entities operating in a number of geographies or economic environments and dealing in a large number of foreign currencies. For such companies operating internationally, one of the key financial reporting needs is to adopt proper accounting for foreign currency matters.

Determining the appropriate functional currencies, accounting for foreign currency transactions, and converting the financial statements of subsidiaries into the parent company’s currency to present a consolidated financial statement are all guided through accounting frameworks prescribed in the Financial Accounting Standards Board (FASB) Accounting Standards Codification (ASC). Rules for foreign currency measurement and translations are defined in ASC 830, Foreign Currency Matters when a reporting entity conducts transactions in more than one currency and prepares financial statements in a single reporting currency.

The process of handling multiple currencies and updating values in these currencies in real time in a ledger using defined currency translation logic is a standard functionality in SAP ERP. As a first step to understanding the multicurrency architecture in the SAP system, you need to understand some of the key terms associated with different currencies and their definitions (Table 1).

Key term	Business explanation or context	SAP terminology or definition
Legal entity	Organizational unit in FI for which a complete and balanced trial balance can be drawn up for external reporting.	Usually referred to as company code in the SAP system. If for any reasons company code does not represent a legal entity in the SAP system, then there is another term called company. Individual company codes make up the legal entity that is grouped under the company.
Transaction currency	The currency in which a business transaction is processed and booked	Any globally traded currency identified by the International Organization for Standardization (ISO) currency codes. The SAP system automatically converts the transaction currency to other parallel currencies using specified exchange rates.
Company code currency (alias local currency)	Generally used to represent the currency of the country in which the entity is physically located or operates. Generally, local currency sets of books are used for reporting financials in compliance with local ledgers (country statutory Generally Accepted Accounting Principles [GAAP]) and tax reporting purposes.	Assigned at the company code level  (first currency).
Group currency	Currency in which the group balance sheet is displayed. Generally used for consolidation in the SAP system.	Assigned at the client (highest) level. You can specify it as a parallel currency (additional local currency) for a company code.
Controlling (CO) area currency	Currency used for cost accounting purposes, currency in which cost centers, internal orders, and projects are managed and reported.	This currency is set up when the CO area is created. The best practice recommendation is to set this to group currency especially in a multicurrency scenario.
Object currency	A currency defined in the master record of a CO object (cost center, internal order, and so on).	Automatically sets to company code currency 1 (defined as local currency) by default.
Global company currency	Generally used for consolidation in the SAP system. Assigned at the company level that can be used to group company codes into a hierarchy.	You can specify it as a parallel currency (additional local currency) for a company code. You need to store the global company currency in the detail screen for the corresponding company.
Index-based currency	Country-specific currency stipulated in certain countries with high inflation for tax returns. Assigned at the country level.	You can specify it as a parallel currency (additional local currency) for a company code if it is specified as index currency in the detail screen for the corresponding country.
Hard currency	Hard currencies are used in countries with high inflation to improve the value of transaction.  Assigned at the country level.	You can specify it as a parallel currency (additional local currency) for a company code if it is specified as hard currency in the detail screen for the corresponding country.

In most cases, company code (local) currency is the external reporting currency in which a legal entity prepares its financial statements for US GAAP or International Financial Reporting Standards (IFRS) reporting. However, it’s possible that local currency might not be acceptable for US GAAP or IFRS reporting if the cash flows are generally transacted in a currency other than the local currency. In these cases, a functional currency is assigned and US GAAP or IFRS reporting must be conducted in the functional currency. In the next section I explain in more detail the concept and business definition of functional currency in line with ASC standards.

The Concept of Functional Currency

According to ASC 830-10-45-2 functional currency is defined as: “The assets, liabilities and operations of a foreign entity shall be measured using the functional currency of that entity. An entity’s functional currency is the currency of the primary economic environment in which the entity operates; normally that is the currency of the environment in which an entity primarily generates and expends cash.”

For example, consider a scenario in which a US-based multinational company has USD as its reporting currency. It operates a wholly owned subsidiary in Mexico and functions as a manufacturing facility of a US corporation. The manufacturing facility in Mexico assembles parts partly received from the US or sourced locally. It makes a final product and ships the completed product back to the US corporation for sale to customers. The US corporation funds the expenses of the Mexican entity and provides a small margin (a contract manufacturing scenario). In this case, the local currency of the Mexican entity is the Mexican peso (MXN), but the functional currency of the Mexican entity is USD, the same as the reporting currency of the US parent company.

Consider another example that illustrates how this could become more complicated. A US-based multinational company has USD as its reporting currency and has a wholly owned operating subsidiary in Germany that has EUR as its functional currency. This German entity could have a contract manufacturing facility or sales office operating in the Czech Republic that has the Czech koruna (CZK) as the country or local currency. If the entity in the Czech Republic has most of its operational cash flows and capital funding in EUR, then the functional currency for the Czech entity is determined as EUR.

Therefore, in this case the local (country) currency of the Czech entity is CZK, the group reporting currency is USD, and the functional currency is EUR.

There could be many more complicated scenarios and varied characteristics of foreign operations in which the relevant accounting framework (ASC 830-10-45-4 / 830-10-45-5) should be considered by management to evaluate and determine what will be the functional currency of an entity.

Without delving into too many details of accounting provisions and standards governing functional currency, I explain what this currency dimension means from an ERP system capability associated with certain critical financial business process areas.

Every business transaction recorded in the transaction currency should be converted on the transaction date into both local and functional currency, if different. Each company code in the SAP system must load a month-end balanced financial statement in functional currency for consolidation and external reporting.

Unrealized foreign exchange gains or losses must be recognized for any outstanding (open) accounts payable (AP), accounts receivable (AR), and general ledger (G/L) balances of monetary balance sheet accounts in which the transactions are in a currency other than the entity’s functional currency. The SAP system calculates a gain or loss between transactional currency and functional currency for monetary balance sheet accounts. When the local currency is different from the functional currency, this gain or loss should be calculated using the functional currency rather than local currency for the purpose of financial statement reporting (US GAAP or IFRS) using the designated month-end revaluation exchange rates.

A realized foreign exchange gain or loss must be recognized for any AP, AR, or G/L transactions of monetary balance sheet accounts that were settled or closed during the month. Gain or loss calculation is automated in the SAP system during clearing transactions such as payments or cash application. If functional currency does not equal local currency, the foreign exchange gain or loss for financial reporting purposes is calculated by taking the difference between the transactional currency and the functional currency.

The SAP CO module along with integration with inventory management can track actual inventory quantity and value based on historical prices. Countries that have functional currency that is different from local currency need to track and report inventory value in functional currency.

The Asset Accounting (FI-AA) module in the SAP system can maintain a separate set of asset books that are depreciated based on local GAAP and US GAAP depreciation rates. Countries with functional currency requirements need to calculate and book monthly depreciation postings in functional currency on the US GAAP or IFRS ledger.

Similar requirements to convert and report in functional currency values apply for various other scenarios or process areas, such as manufacturing work in progress (WIP) determination and calculation, variance settlement postings from production processes, revenue or cost of goods sold accounting based on Result Analysis or revenue recognition, cost allocations, and FI postings originating from other modules within the SAP system.

SAP S/4HANA Finance architecture does not have any exclusive currency type to distinctly identify and store functional currency separate from local currency. As a solution, it may be quite logical to recognize functional currency as another parallel currency in the SAP General Ledger.

Handling this as a parallel currency could pose a limitation to consistently reporting the values in the ledger for certain types of transactions due to the complex currency architecture design in the SAP system. I analyze this issue in more detail in the next section by taking a close look at the evolution of currency setup across different versions of SAP ERP and the specific reasons and challenges related to accurate reporting of functional currency values.

Evolution of Currency Architecture in SAP ERP

In this section, I outline the changes in customizing and data models for the currency settings, starting from how it was earlier in SAP ERP Central Component (ECC) 6.0, in SAP S/4HANA Finance 1503 (Simple Finance 2.0), and then in SAP S/4HANA Finance 1605 (Simple Finance 3.0).

Currency Settings in ECC 6.0 (Classic and SAP General Ledger)

I briefly explain the available currency settings in FI, CO, and the Material Ledger, and the flow of transaction postings from FI and CO to G/L books.

In ECC 6.0, three currency types can be defined in FI but only two currencies can be defined in the CO module as shown in Figure 1. The Material Ledger can be set up with three currencies in line with the currency type defined in FI and CO.

In this currency architecture that existed in SAP ECC 6.0 (classic and SAP General Ledger), there were a few shortcomings.

Lack of integration in currency types across application components: Each ledger (FI and CO) is distinctly separate with no integration in the setup of currency types other than local currency. It is even possible to define a different CO area currency in the CO area even if FI could have group currency as the second local currency or vice versa. As a result, reporting of values from CO area currency to FI parallel currencies translate at current rates resulting in complex month-end reconciliation efforts between FI and CO.  Even if CO area currency = FI second local currency = group currency, the translation to FI third currency was at the current exchange rate with local currency as the basis, resulting in rounding differences or residual balances. Insufficient currency flexibility: There is no specific currency type that could be defined in the SAP General Ledger for storing functional currency values other than re-purposing the other currency types 40, 50, or 60 defined for hard currency, index currency, or global company currency as third local currency. However, even in this scenario, the definition of functional currency as a third local currency in the SAP General Ledger is always hard to understand for finance accountants. It creates tremendous reconciliation challenges or issues regarding consistency of values reported in certain business transactions. I look at some of the common challenges faced because of these issues. First, definition of functional currency type as one of the parallel currencies enables tracking of inventory in functional currency. However, if the material is subjected to standard cost-based inventory valuation, an issue arises in product cost calculation and reporting of functional currency-based inventory values in the Material Ledger. For a standard cost estimate computed in the product costing module, most organizations typically use a planning rate (P rate) for cost calculations vis-à-vis the current exchange rate (M) for regular business transactions. In the SAP costing process, values of a cost estimate are always calculated only in local currency (10) and CO area currency using the plan rate. The results are written into the material master in the marking step (and transferred to current cost estimate in release step). However, for the price update in the third local (functional) currency, the system does the calculation from the cost estimate currencies by translating the standard price in currency type 10 using current exchange rate type M. This difference in currency translation logic could lead to significant inventory valuation and price differences between local and functional currency when different inventory movement transactions are performed for the material. Second, a similar problem occurs in CO transactional postings such as Settlement of Internal Order, CO Settlements (including settlements from an SAP Quality Management (SAP QM) service order or manufacturing order), CO Allocations, CO Re-postings Result Analysis for POC/Revenue recognition, and WIP Determination and Calculation. In all these business transactions, the CO module tracks the transactional values as well as balances in local (object) currency as well as in group currency. So, when these period-end close functions are carried out, the system automatically settles the object currency (local currency) value and CO area currency value considering the cumulated historical amount, thus clearing the complete balances from the sender cost object to the receiver without leaving any balance. However, for functional currency, the system converts the functional currency posting amount based on the current exchange rate. This could lead to account balances (leftover) in the functional currency value caused by exchange rate differences between the original transaction posting dates and settlement date, which is not desirable. I use this example of an order settlement scenario to illustrate the above mentioned posting behavior and derivation of functional currency amounts if this currency type is stored as the third local currency in the SAP General Ledger.

In this example, consider a company code ZB00 that has the following currency types defined in FI:

• Local Currency (10) – BRL (also the object currency of an internal order used in the process)
• Second Local Currency (30) – USD (also set as CO Area Currency)
• Third Local Currency (40) – defined as functional Currency (EUR)

As a first step, actual postings are booked to the internal order as a cost object with two different posting dates. In Figure 2, the first posting is carried out with a posting date of 1Oct 2016. Let us consider that on this date, the exchange rate of BRL – EUR is 0.08333.

In Figure 2, the LC3 amount represents the amount calculated in functional currency. The functional currency amount is calculated from local currency with the currency translation based on the posting date.

In Figure 3, another expense posting is booked against the internal order with a posting date of 18 Oct 2016. For illustration, the exchange rate of BRL-EUR on this date is 0.08000. Quite similar to posting 1 shown in Figure 2, the functional currency amount is calculated and updated in the LC3 amount.

After the expense postings are booked, the next step is to carry out settlement of expenses from the internal order in CO. In this illustration, the receiver is a G/L account 23530 (Balance sheet). Settlement is carried out on the posting date of 31October. Let’s consider the exchange rate of BRL – EUR on this day as 0.05000.

So, during settlement process as illustrated in Figure 4, the amounts for local currency (BRL) and group currency (USD) are the historical transaction amounts selected and settled to the receiving object. However, this historical amount selection is not supported for the third local currency (functional currency) and the values are recalculated from the local currency by carrying out a currency translation with the exchange rate valid on the settlement posting date. This results in a residual (leftover) amount in G/L Account 58200 after settlement in the third local currency that may need to be manually re-classified or posted to the receiving G/L object to clear the balance.

SAP also recommends the manual journal (re-posting) as the only possible solution to correct currency differences for such scenarios in SAP Notes 158953 and 1737442.

Posting of the manual journal entry as a part of the period-end close processes to zero out the balance in functional currency may seem feasible for a single or low volume of transactions. However, for major corporations with multiple company codes and currency combinations, analyzing the large volume of such transactions and doing these balance re-classifications is very time-consuming and could generate inaccurate results. The complexity of reporting in functional currency further aggregates for companies that adopt make-to-order (MTO) or engineer-to-order (ETO) types of manufacturing processes, with the revenue and cost of goods sold postings in FI originating through a Result Analysis settlement or manufacturing order settlement processes in CO. Even for companies with regular make-to-stock manufacturing, challenges arise in reporting correct WIP inventory value, stock values, and manufacturing variance results, thus affecting the gross and net margin results.

Currency Settings in S/4HANA Finance On-Premise 1503 (Simple Finance 2.0)

From ECC 6.0 enhancement package 7 (Simple Finance Add-on for SAP HANA), SAP has prepared the technical foundation to combine the FI and CO ledgers into one Universal Journal. The new table ACDOCA has a provision for integrating the CO area currency as global currency for the General Ledger and CO at the line item level in the ledger as shown in Figure 5. Global currency is always the currency type of the CO area.

In the enhanced technical architecture of SAP S/4HANA Finance 1503, SAP has taken a step forward to have a unified data model and ensured integration of CO area currency from the CO ledger with the second local currency in the SAP General Ledger. However, the shortcomings and issues as explained earlier regarding the use of a third local currency (first additional currency in the Universal Journal) for functional currency and the resulting inconsistency or proper clearing of balances was still a design limitation with no standard solution to bridge the gap. Also in this version of S/4HANA Finance, there was no standard currency type (beyond re-purposing currency types 40, 50, and 60) or a possibility to define a custom currency type (in customer namespace) for functional currency.

Settings in SAP S/4HANA Finance Subsequent On-Premise (OP) Versions

In SAP S/4HANA Finance On-Premise 1511, the Universal Journal was expanded to include additional parallel currencies (two fixed currencies – local currency and global currency – and three additional freely defined currencies). This enables users to freely configure new currency types in the customer namespace. Currency conversion logic in the accounting interface for custom currencies is not in real time.

Definition of a custom currency type and assignment to a ledger is carried out by executing transaction code FINSC_LEDGER. This transaction is enhanced to contain additional maintenance views for the definition of currency types and currency conversion settings (company code independent and company code dependent).

Figure 7 shows a definition of currency type in the customer namespace (Z1 and Z2). Customers can define a custom currency type and define the maintenance level as company code dependent or company code independent.

Further, you can define additional settings for the custom currency type in currency conversion settings maintenance views. As you can see in Figure 8, it is possible to define the currency code (INR in this example) and translation logic. In SAP S/4HANA On-Premise 1511, by default real-time currency conversion during transactional postings is not enabled. Because the custom currency type does not have a real-time conversion feature enabled, source currency is always set as the default to document currency with no translation logic defined.

After the definition of custom currency type and associated conversion settings, it is possible to assign these currency types to a ledger. Starting from S/4 HANA 1511, it is possible to assign a currency type independent of a ledger, especially the custom currency types. In Figures 9 and 10, currency types 10 and 30 are assigned to both the leading ledger (0L) and the non-leading ledger (Z1), and the custom currency type (Z1) has been assigned only to the non-leading ledger (Z1).

With this version, SAP introduced a certain degree of flexibility in currency settings allowing users to define custom currency types and assign them to a ledger. However, a lack of real-time conversion and also a lack of integration of additional parallel currencies (freely defined currencies other than two fixed currencies) with CO or the Material Ledger in the Universal Journal cause the same issues and challenges for treatment of functional currency as existed in prior product versions of SAP S/4HANA Finance.

In SAP S/4HANA Finance On-Premise 1605 (the latest SAP S/4HANA Finance On-Premise version available for deployment when this article was being written), SAP made additional enhancements to currency architecture in the Universal Journal. These changes in customizing and the data model for currency types enable not only more flexibility in the definition and usage of currency types, but also ensure the integration of currencies with FI-AA, CO, and the Material Ledger.

Key architecture changes related to multicurrency settings in the latest version of S/4HANA Finance On-Premise include:

• Universal Journal (ACDOCA) can now handle two fixed currencies (local currency and global currency) and up to eight freely defined custom currencies
• Real-time currency conversion is possible for all currency types, including custom-defined currencies, and currency conversion settings are maintained globally or specifically per company code
• Balance zero per document is ensured for all currencies
• Selection of historical amounts during clearing or settlement for all currencies is enabled only for certain business processes such as open item clearing and GL/CO allocations. The limitation exists for many other processes, especially those processes that originate outside of the FI module that I discussed earlier in the article such as CO settlement or re-postings, order settlement, Result Analysis, and Material Ledger processes.

To summarize, even in the latest SAP S/4HANA Finance version, several CO and Material Ledger transactions posting to FI perform on-the-fly calculation of values for parallel currencies in FI, thus causing reporting inconsistencies.

With current design limitations for a full-fledged currency solution to handle functional currency, most SAP users who are mandated to do functional currency reporting adopt certain work-around options. In next section, I outline some of the common technical work-around solutions adopted by SAP customers.

Work-Around Solutions to Address Functional Currency Reporting

Some of the common technical work-around solutions recommended are listed below. Selection of a solution option could vary based on the complexity of business scenarios, GAAP accounting needs, and country or currency combination. Based on my experience, a combination of one or more of these work-around solution options could be implemented for a user based on the reporting needs for the legal entity and functional currency associated with it.

The first scenario is manual journal entry to correct functional currency values. The most common approach followed is to set the functional currency as one of the parallel currencies in the FI ledger or Universal Journal and post the journal entry at month end to correct any functional currency imbalance as defined in SAP Notes 158953 and 1737742. As described earlier, this approach is completely manual and time-consuming. This may also necessitate additional customizations or reporting needs to support the manual journal entry process. The second scenario is when functional currency is required to be the same as group or global currency. For countries that require functional currency and the currency matches to group currency or global currency, then setup of currencies in the FI ledger (transaction code OB22) or Universal Journal (transaction code FINSC_LEDGER) could be done as shown below:

• First company code currency = local currency with currency type 10
• Second company code currency or global currency = functional currency with currency type 30
• Set up currency translation from transaction currency

This type of setup is shown in Figure 11.

The third scenario is when functional currency needs to be as local currency of company code. In certain scenarios, an alternate work-around option may be to maintain the local currency of the company code the same as the functional currency. This affects local (country) legal statutory reporting and tax reporting requirements. Regular full-scope operational entities (such as entities with manufacturing, sales, procurement, or employees) will have a legal mandate to fulfill respective country tax reporting requirements. All standard SAP functionalities for tax reporting can consider only country currency or local currency type. Therefore, this option may not be the best fit for the legal entities that have regular full-scope operations. However, you may fit this approach for certain types of legal entities that have very limited financial activities with no sales or purchase types of operations (for example, entities holding only investments or loans and treasury functions).   As you may be aware, current SAP design restricts one group currency per client (defined in table T000). As a result, it is not possible to create more than one CO area with different group currencies. Creation of a new CO area in a new client limits several business functions globally in an organization and also introduces many additional challenges as cross-controlling area postings or functions are not possible. A reporting entity should determine the functional currency in line with the provisions of ASC 830 and ensure accurate financial statement reporting. There is still no perfect standard solution available to meet the complete business process and GAAP accounting needs outlined earlier in the article for functional currency reporting. However, SAP currency architecture in SAP S/4HANA Finance is progressing in the right direction to bridge this gap through simplified and harmonized data model in the Universal Journal.