Multi-Currency Support

The Introduction

This article is intended for users involved in implementing a multi-currency Aqilla system.

It provides detailed guidance and best practices for configuring and managing multiple currencies within the platform. A foundational understanding of Aqilla is presumed.

Currencies

Any Aqilla instance supports an unlimited number of currencies, although each Aqilla ledger can only have one base currency.

Maintain currencies at Reference > Currencies and select the ledger base value at Configuration > Ledger Definitions.

In this article, the base currency is the British Pound (GBP).

When creating a ledger, you select the base currency, which becomes fixed once any transactions are posted to the ledger.

Changing the base currency is not longer possible once the ledger is in use.

This ensures consistency and accuracy in financial reporting from that point forward.

When creating a new currency, the mandatory fields are Currency Name and Currency Code.

These fields ensure that the currency is accurately identified within the system.

Further options are Realised, unrealised gains/loss accounts, payment account, decimal places, Rate type, symbol and Operation.

The Operation option plays a crucial role in the calculation of the exchange rate.

This option allows users to select either Divide or Multiply, depending on the desired calculation method. By selecting Divide, the system will divide the amount by the exchange rate.

Selecting Multiply will multiply the amount by the exchange rate. This provides flexibility and ensures you can tailor the exchange rate calculations to suit their specific financial processes and requirements.

For an in-depth explanation of the Rate Type option, please see the Currency Rates section below.

Detailed articles on Payment Account, Realised and Unrealised Exchange Gains and Losses are also available in the following sections.

Automatic Currency Feed.

Aqilla facilitates the automatic import of currency feeds on both a daily and monthly basis. The system proactively fills in the Date From, Date To, and Rate fields overnight, ensuring that all relevant information is consistently updated without manual intervention.

This feature is designed to streamline your financial operations and provide you with the most accurate and up-to-date currency information.

Read more about the Automated Currency Feed on our Currenciespage

Currency Rates

Manually entering a currency rate involves selecting the date range using the Date From and Date To fields, and then inputting the exchange rate under the Rate field.

It's possible to store multiple rates for a currency. You can choose daily, weekly or monthly rates using the Date From and To fields.

If required, you can store multiple types of rates under each Rate Type, using one for daily, one for HMRC and another for management reporting.

Please be advised dates cannot overlap within the same rate type.

Rate Types

Any number of Rate Types may be created at Configuration > Rate Types. For example:

Default - Rate used for document entry (unless overridden by the user) and payments/debits.
Management Reporting - An example of an additional rate type. Used by financial reports and the revaluation process.
Other Rate Types - optionally available in some Aqilla views

Rates are maintained for each Currency Rate Type as shown below - at Reference > Currencies.

The above example shows monthly rates, but Date From and Date To can be any date range, so even daily or weekly rates can be supported.

Date ranges can be different (e.g. daily, weekly, quarterly) for each Rate Type.

Payment Account

This defines the account from which payments will be made for the currency in question unless overridden for a specific creditor account.

Realised & Unrealised Exchange Gains & Losses

When a non-base currency document is created in Aqilla, the currency amount is converted to the base currency using a rate suggested by Aqilla or a spot rate that is entered at the time. By way of example an entered sales invoice may have the following attributes:

Invoice Number: 12345
Debtor: SHE001 (Shell)
Invoice Date: 16 Aug 2014
Due Date: 15 Sep 2014
Currency: EUR
Total Amount: 36,931.20
Base Currency Amount: 29,474.23

The exchange rate of 1.253 is implicit.

When the customer makes payment the EUR / GBP rate may be higher or lower than 1.253 leading to an exchange rate loss or gain being realised. If payment has not yet been made, the exchange rate gain or loss is unrealised.

Realised gains/losses are posted by the Payments/Debits or Transaction Matching processes.

It is possible to consolidate realised gains and losses into a single account (e.g. P2230 Exchange Gain / Loss) and similarly consolidate unrealised gains and losses into a separate single account.

The “realised / unrealised - exchange gain/loss” fields are used to hold the accounts to which gains and losses are posted when ledgers are revalued.

Revaluation Process

The revaluation process at Processes > Revaluation is used to calculate and post unrealised currency exchange gains and losses.

Before using this process you need to perform the following actions:

Against each currency that is to be re-valued, it is necessary to define the unrealised exchange gain and loss accounts as described above.
Create one or more Revaluation Profiles at Configuration > Revaluation Profiles using the view shown on the right

The Revaluation Profile defines:

the currency Rate Type that will be used to revalue
whether both gains and losses (or only gains or losses) will be calculated
whether resulting postings will be rough or final

In addition up to a further five filters may be applied to refine the ledger transactions that will be processed. These filters use boolean logic and attributes of ledger transactions.

The revaluation process is performed at Processes > Revaluation by selecting a Revaluation Profile and the period to be revalued.

Aqilla will calculate - for each account, currency and project - the difference in the total base value and the value calculated from the currency values and post the differences to each account. The balancing amount is posted to the unrealised exchange gain and loss accounts defined for the currency in question.

Note that all P&L accounts are excluded from the revaluation process. Any other account can be excluded from the revaluation process by editing the account and setting Suppress Revaluation to “Yes” at Reference > Debtors or Reference > Creditors.

Rough Posted transactions are also excluded from revaluation.

If the rough post mode has been set in the Revaluation Profile, the transactions will be rough posted in the ledger; rough posted transactions can be included / excluded in reports at run time. Rough posted transactions can be fully posted or deleted using Processes > Revaluation.

It is also possible to produce revaluation reports.

Currency Transfer Document

A special Currency Transfer document is available. This document type is by default disabled. If you wish to use the Currency Transfer document, please contact support@aqilla.com for it to be enabled and for help with configuring the Currency Control Account, which must be configured before first using this document.

This document type enables the transfer of values from one account in one currency (source account) to another account with a different currency (destination account) by always using the same base amount for the source and destination accounts thus ensuring that no currency exchange differences will be created.

In the document header, you specify the source account, which determines the source currency, in the document detail lines the source amount, which then calculates the base amount and you specify the destination account and destination amount in the currency of the destination account. The user may optionally adjust the base amount.

One or more lines can be created for transactions being transferred from the same source account.

The document also supports transferring from or to an account in base currency.

When the document is posted the transactions are posted through an intermediate Currency Control Account, which must be configured before first using this document. The journal always uses the same base amount for the source and destination accounts thus ensuring that no currency exchange differences are being created.