In markets that deal in more than one currency every day, a branch may sell in one currency, the warehouse may buy in another, and salaries may be paid in a third. Even so, many projects treat multiple currencies as a field added to the invoice, and the problems surface when the first profit reports are requested.
A system can’t decide for you which exchange rate is the right one, or where the difference between two rates is recorded. These are management and accounting decisions, and if they aren’t settled before development, the developer settles them with their own assumptions, which may not be yours.
One of the signs in the article “Six signs your organization needs a custom ERP system” was multiple currencies and branches. Here we set out the decisions we recommend settling before a single line of code is written, in language a general manager understands as well as an accountant does.
The base currency and the documents that carry a currency
The first decision is the base currency: the currency in which the books are kept and consolidated reports are prepared. It may differ from the currency most branches sell in, and management may need an additional reporting currency for presenting results to the owners.
Suppose an organization sells in the local market in the local currency and imports its goods in a more stable foreign currency. Management may choose the foreign currency as its base currency because that is the currency it measures real profit in, while keeping customer invoices in the local currency.
Next, decide which documents carry their own currency. Invoices, receipt vouchers, and payment vouchers usually do, because they reflect what was agreed with the customer or supplier. For inventory cost, the usual choice is to record it in the base currency, converted at the rate on the purchase date, so that the value of the goods on the shelf doesn’t change with every movement in the exchange rate.
You also need to decide whether a customer has a single account in several currencies or a separate account for each currency. The decision affects the account statement the customer will receive and the way receivables and collections are tracked.
Exchange rates: where they come from and which one applies
The rate source and who enters it
Choose a single approved source for the exchange rate: the rates published by an official body, the market rate that management adopts, or a daily rate set by the finance manager. Then decide who enters the rate, when they enter it, and what happens if today’s rate hasn’t been entered: does the system block invoicing, or does it use the last rate with a clear warning?
Agree as well on the direction of the rate: is it entered as the local-currency value of one unit of the foreign currency, or the other way around? A small mistake in this agreement inverts every amount, and it is usually discovered late. In markets where the buying rate differs from the selling rate, decide which one applies to sales and which to purchases and currency exchange.
Document date or payment date
Each document has a rate fixed on it when it is issued, usually the rate on the document date. But payment may come weeks later, and the rate may have changed in the meantime. So agree in advance that the invoice keeps its own rate and that the payment is recorded at the rate on the day it is made.
The effect of this decision becomes clear with partial payments: a single invoice may be paid in installments, each at the rate of its own day and with its own exchange difference. A customer may also pay an invoice in a currency other than the invoice’s own, so the system needs a clear rule for converting the payment into the invoice currency before closing the invoice.
Exchange differences
The difference between the two rates isn’t an error to be corrected. It is an exchange gain or loss, recorded in an account set aside for it. You also need to decide whether open balances in other currencies are revalued at the end of each period, or whether the difference is simply recorded at the time of payment.
Suppose an invoice was issued in a foreign currency when its exchange rate was high, then paid a month later after the rate had dropped. If the system has no account for exchange differences, the customer’s account will be left with a small balance whose origin no one knows, or someone will edit the invoice by hand to close it.
A system carries out currency decisions precisely, but it doesn’t make them for you.
Prices, rounding, and cash boxes
There are two main options for pricing. Either management sets a separate price list for each currency, or there is a single price in the base currency that is converted at the time of sale. The first gives the customer a fixed price; the second is easier to manage, but it changes the displayed price with every movement in the exchange rate.
Rounding is a small decision with a cumulative effect. Here you decide whether each invoice line is rounded or only the invoice total, what the smallest unit actually in circulation is for each currency, and which account rounding differences are recorded in. Leaving this unsettled produces small differences between invoices and receipts that build up until they become a reconciliation problem.
For cash, the safe rule is a separate cash box for each currency, because a single cash box holding different currencies is hard to count unless each currency’s balance is kept separate. Exchanging one currency for another is recorded as a transfer document between two cash boxes, with its rate, its date, and the name of the person who carried it out.
If the organization is moving to the system from Excel files, the opening balances themselves need the same decision: the balance of each cash box and each customer in its own currency, with the approved conversion rate on the go-live date.
Reports, permissions, and the change log
Define the reports before development, because they show what has to be stored with every transaction. A branch manager often needs reports in the currency the branch deals in, while management needs consolidated reports in the base currency that bring all the branches together. That is only possible if every document stores its currency, its rate, and its amount in the base currency, all together.
It also helps to identify the reports that show amounts in their original currency alongside the base-currency equivalent, such as customer account statements and receivables aging, because a customer settles accounts with you in the currency of their invoice, not the currency of your reports.
Editing the exchange rate is a sensitive permission, because it changes the value of everything recorded after it. So it is limited to a small number of users, and the rate for a day that has been closed, or that documents have already been issued against, can’t be changed except through an approved procedure.
Suppose an employee mistyped a single digit when entering today’s rate, and the whole morning’s invoices were then issued at that rate. Correcting the rate alone isn’t enough: the system has to identify the affected documents, and they have to be handled through an approved procedure that leaves a visible trace.
Every change to the rates also needs an audit trail: who changed the rate, when, and from what value to what value. That trail is what answers the auditor’s or the manager’s question months later, when no one remembers why one figure differs from another.
A list of decisions before development
Gather the answers to these questions in a single document that the finance manager approves before work begins on the financial modules:
- What is the base currency, and do we need an additional reporting currency?
- Which documents carry their own currency, and in which currency is inventory cost recorded?
- Does a customer or supplier have one account in multiple currencies, or one account per currency?
- What is the source of the exchange rate, who enters it, and what happens if today’s rate is missing?
- Which rate applies to the document, and which to the payment?
- In which account are exchange differences recorded, and are open balances revalued at the end of the period?
- Do we use a price list for each currency, or prices converted from the base currency?
- How is each amount rounded, and where are rounding differences recorded?
- Does each currency have its own cash box, and how is currency exchange between cash boxes recorded?
- Which reports does each branch need, and which consolidated reports are needed in the base currency?
- Who has permission to edit the rates, and is a record kept of every edit?
These decisions don’t call for complex accounting terminology. They call for a session that brings together the general manager, the finance manager, and the people who handle cash every day. Whatever is agreed is written down as clear business rules that the system is built on, instead of being discovered after launch.
You can discuss your situation with the ITS team, so that together we can review your currencies and branches and identify the decisions that need settling before development begins.
Related serviceCustom ERP systems