Single Currency Processing (FRS23, IAS21)

Single Currency

ITAS is a multi currency system whereby all transactions are entered in their actual (local) currency. However it is often required to report in the Functional Company Currency, therefore currency conversion is required. The 2 methods for doing this are known as multiple and single currency.

The multiple currency method takes the original transaction value and converts it to the target currency using relevant exchange rates at the time the report is run. Typically these will be spot, month end or year end rates and all transactions will be converted using these rates.

Single currency will secure the target currency value at the time of the transaction, typically using the prevailing exchange rate for the document date. Thereafter the functional currency value(s) arean element of the transaction and may not be changed i.e. same the local currency value may not be changed.

Using the single currency method, the transaction’s value will not change from month to month and therefore complies with the FRS23 requirement.

If operating single currency, a 2^nd currency may be nominated whereby the system will secure all 3 currency values per transaction. This is useful when there is a group/company functional currency (e.g. US Dollars), but the company is located in a country also requiring FRS23 but in the local currency (e.g. Swiss Francs)

There are many options for running single currency, these are all controlled on the ‘Single Currency Operation Parameters’ page in S01.

The main feature/control is how the functional currency equivalent is be calculated; it may be generated automatically by the system in the posting process Or the user can enter the Exchange Rate per transaction.

The most efficient control is to enable RPP to utilise the FXR content wherec timely entry of exchange rates ensures consistent application of functional currency values.

If user prompt is required, the exchange rate can:

Default to the prevailing rate or have no default e.g. DOCENT
Be derived from existing data e.g. INVOICING where the ROE fixed to a physical contract is used
System spot rates used e.g. Futures settlements

Most transactions will use the ROE to generate the functional currency equivalent value, however sometimes it is necessary to post adjustments whereby the functional currency value(s) need to be entered explicitly. DOCENT/JNI enables these entries.
Other situations where the system generates the functional currency equivalent value are:

Document reversal; where the original document’s functional currency equivalent is used as the basis, not converting the local currency value again
WIP Account closure and month end accruals (WIPACCRUE); the functional currency equivalent is based on the historical value of the invoices, not the current value
Warehouse intakes and processing; these will use the historical value of the invoices as opposed to the calculating them based on the intake/processing date
Cash matching and REVALX; see below

When operating the company as FRS23/IAS21, most reports provide the option to also selact the multi currency feature as well.

As well as recording the functional currency values on the accounting transaction, this value is also stored on the physical contracts as part of their goods, costs and commission invoice marking. This means the contract valuation and accrual procedures can use the historical rates to comply with FRS23.

Currency Revaluation

Retaining the historical value in the books is correct for some types of account such as P&L, whereas outstanding counterparty debits and credits, cash at bank etc. need to be revalued each month so the current value of the asset is shown. This is achieved in procedure REVALX. The differences between the historical value and current book value are posted between the account and the nominated FX Revaluation account. The FX Revaluation account is nominated on the ‘Single Currency Operation Parameters’ page in S01 . On the same page, the company can select their REVALX options such as post the valuation to the client account itself or a specific nominal ledger account, revalue by department etc.

The revaluation takes effect in the month about to be closed, and uses the month end exchange rates for that period. The revaluation is reversed in the following month.

Cash Matching

As explained above, when an invoice is raised in a currency other than the company currency, it also has a company currency value using a ROE appropriate at the time the invoice was raised. The cash paid or received on account of the invoice may have a different ROE. When the 2 are matched the currencies net to zero in the local currency but do not necessarily do so in the company currency. In this situation a revaluation journal (JNI) is generated automatically to net the company currency value to zero allowing the match to take place. The Journal posts the difference between the client account and nominated FX Revaluation account (as for currency revaluation) and is included in the match. If the match is subsequently broken, the journal is automatically reversed. This mechanism is employed in both client and nominal ledger matching. Because the items are revalued on matching, matched items are excluded from the REVALX procedure.

FFCC

The variation margin of forward FX deals is visible through various valuation reports (TOPEN, VALUATION etc.). On maturity there is an option to secure that latest variation margin on the FX deal itself and post this value between the nominated FX Revaluation account and FFCC account. This is triggered by nominating the FFCC account on the ‘Single Currency Operation Parameters’ page in S01

IAS 21, FRS23 and SSAP20

IAS 21 is the International Accounting Standard on Foreign Exchange, and it has been introduced into UK GAAP as FRS 23. For companies which adopt FRS 23 it supersedes SSAP 20 (CFM26000). SSAP 20 remains in force for those companies that do not adopt IAS or FRS 23. It was implicit in SSAP 20 that a company would draw up accounts in its local currency, but IAS 21/FRS 23 permits a company to use any currency to prepare its accounts even where it is not the functional currency. Two currencies are defined for the purposes of IAS 21 and FRS 23.

Functional currency

This is defined for tax purposes at CTA10/S17(4). The functional currency is the currency of the primary economic environment in which the company operates. This may be sterling or another currency.

IAS 21/FRS 23 sets out a number of objective indicators for determining a company’s functional currency, such as the currency that influences the price for which goods and services are sold, and the currency that influences its costs of labour and other expenses. Where the indicators give mixed results, the management of the company must make a judgement.

In many cases, the company’s functional currency will be the same as the ‘local currency’ that it had under SSAP 20. However, in some more complex groups, the functional currency of an intermediate holding company, for example, may under IAS 21 and FRS 23 be influenced by the functional currency of its parent. In some cases this may make it more difficult to determine the functional currency of a company in circumstances where the company would have a different functional currency when viewed in isolation. This may, in practice, lead to a change of functional currency for accounting and therefore tax purposes.

Presentation currency

Under IAS 21 or FRS 23 a company can present its financial statements in any currency. The currency in which the financial statements are prepared is known as the presentation currency. Where the functional currency differs from the presentation currency, the functional currency must be disclosed in the accounts. The general tax rule is that whatever the presentation currency, CT profits or losses must be calculated by reference to the functional currency. The term presentation currency is not used in the legislation - instead the rules refer to the currency in which the accounts are prepared.