Multi-Currency, Revaluation & Translation – ASC 830 (Old FAS 52) and IAS 21

Agenda

  • ASC 830 vs. FAS 52
  • Multi-Currency for Transactions
  • Revaluation and Translation

The Relationship: FAS 52 and ASC 830

FAS 52, ASC 830, and IAS 21 are all accounting standards that deal with foreign currency translation and the effects of exchange rate changes on a company’s financial statements.

The most important thing to know is that ASC 830 is the current codification of FAS 52:

  • FAS 52 (Statement of Financial Accounting Standards No. 52) was issued in 1981 as the original U.S. GAAP standard for foreign currency matters.
  • In 2009, the FASB created the Accounting Standards Codification (ASC) to consolidate all U.S. GAAP into a single, authoritative source. As part of this, FAS 52 was superseded by ASC Topic 830: Foreign Currency Matters.
  • So, when you hear “FAS 52,” you’re really talking about the same principles that now live in ASC 830.

ASC 830 / IAS 21 Summary

These standards provide guidance on accounting and reporting for foreign currency matters.

Scope

  • Transactions denominated in foreign currency
  • Translation of foreign currency financial statements

Accounting for Transactional Gains and Losses

  • When exchange rates differ between the transaction date and the settlement date, you recognize realized gains or losses.
  • If reporting occurs before settlement, the interim changes are unrealized gains or losses.
  • Both realized and unrealized gains/losses are reported in income because they directly impact cash flows.

Example:

  • A U.S. company invoices a German customer €1,000 on Jan 1 when rate = 1.10 → $1,100 recorded revenue.
  • By Feb 1 (settlement), rate = 1.05 → only $1,050 cash received.
  • $50 difference = FX loss in P&L, not a revenue adjustment.

Translation of Financial Statements

Translation of foreign currency financial statements to the reporting currency is intended to:

  • Show the economic effect of exchange rate changes on cash flow and equity.
  • Preserve financial ratios when converting from the functional currency to the reporting currency.

Functional Currency Method of Translating Financial Statements

  • Functional currency = the currency of the primary economic environment where the entity operates.
  • It does not have to match the local country’s currency. For example, a Mexican subsidiary that primarily sells in U.S. dollars may have USD as its functional currency.
  • Functional currency can change if circumstances change (e.g., sales shift to a new market). Disclosures are required, but prior financials need not be restated.

ASC 830 suggests economic indicators to consider in determining the functional currency:

  • Cash flow indicators
  • Sales price and markets
  • Currency of costs and expenses
  • Entity’s financing
  • Intercompany arrangements

When Functional Currency = Currency of the Books and Records → Translation

  1. Finalize all transactions and account for realized and unrealized transaction gains and losses in the functional currency.
  2. Translate the functional currency to the reporting currency at current exchange rates:
    • Period-end rates for assets and liabilities
    • Period-average rates for revenue and expenses
    • Historical transaction rates for equity
  3. Translation adjustments are treated as part of equity (Other Comprehensive Income) until the entire entity is liquidated.

When Currency of the Books and Records ≠ Functional Currency → Remeasurement Before Translation

  1. Convert the accounts to the functional currency first via remeasurement:
    • Current rate for monetary assets and liabilities
    • Historical rates for non-monetary accounts (inventory, PP&E) and related revenue/expenses and equity accounts
    • Average rate for all other revenue and expenses
  2. Remeasurement adjustments are included in current income.
  3. Then perform translation to the reporting currency.

Multi-Currency for Transactions (ERP Context)

  • Transaction amounts are stored in modern ERP systems in both entered and converted currencies.
  • The converted currency amount is based on the exchange rate related to the transaction:
    • Daily Rate Types
    • User Defined Rates
  • Applications allow you to specify the default rate type via profile option or system setup, but it can be overridden by the user.
  • Realized Gain/Loss on AR/AP is calculated based on the difference in the rate between the transaction date and the settlement date and posted from the sub-ledger.
  • Gain and loss accounts are set up at the Bank Account level.

Revaluation in ERP Systems

  • Unrealized gain/loss on monetary items (Cash, Receivables, Payables) is calculated in the General Ledger via Revaluation.
  • Revaluation is calculated using a daily rate type defined in the Revaluation form and the rate date of the last day of the period.
  • Accounts can be revalued individually or in ranges and grouped into different revaluation entries if desired.
  • Revaluation gain/loss accounts are also defined in the Revaluation form.
  • The unrealized gain/loss is posted via journal entry in the converted currency.
  • Revaluation journals are generally reversed in the following period but can be run incrementally.

Example:

  • Receivable of €10,000 recorded at 1.10 = $11,000.
  • Period-end rate 1.15 → $11,500 equivalent.
  • $500 unrealized gain posted at period end, then reversed in the next period.

Translation in ERP Systems

  • Translation converts functional currency balances into the reporting currency for consolidation and financial statement preparation.
  • Period-end rate is used to translate balance sheet accounts; period-average rate is used to translate income statement accounts.
  • Income statement accounts are generally translated on a Period-to-Date (PTD) activity basis, while balance sheet accounts are translated on a Year-to-Date (YTD) balance basis.
    • Ledger options control the translation method for income statement and equity accounts (PTD vs. YTD).

Key Considerations:

  • Rate types for period-end and period-average are defined in the Ledger setup.
  • For equity accounts, typically a historical rate is defined to keep the rate constant in every period.
    • Historical rates must be manually updated when transactions occur in equity other than income roll at year end.
  • For the retained earnings account, the historical rate is recalculated automatically when the first period of the next year is opened and current earnings are rolled into retained earnings.
    • The retained earnings account combination is also defined in the Ledger setup.
  • The difference between translated debits and credits is “plugged” to the Cumulative Translation Adjustment (CTA) account in equity (Other Comprehensive Income).
    • CTA account is also defined in the Ledger setup.

Practical Translation Notes

  • When converting general ledger data that needs to be translated, convert the ending balance sheet only in the period prior to the first transaction period and then translate.
    • The difference between debits and credits on the ending balance sheet should equal the cumulative translation adjustment that exists in the legacy system.
    • Use historical rates for retained earnings and any other accounts that have been using historical rates when performing the first translation.

Special Consideration for Intercompany Accounts:

  • Trading accounts that are settled regularly → revalue and include gains and losses in income.
  • Long-term investment and non-trading accounts → gains and losses to CTA.

Note: Always consult auditors when in doubt.

Leave a comment