Multi-currency accounting: where the exchange rate actually lives in your books

Open most accounting systems and you will find an "exchange rate" field next to the "currency" one, with an unstated assumption that the system fills the first in automatically once you pick the second. Fatouraty does not — not for lack of an integration. A rate a person typed onto a specific document is the one number your books can still defend later; a rate an external feed silently filled in at a moment nobody recorded is not.

Where a rate is entered, exactly

Every workspace has one functional currency — the currency the general ledger actually accumulates in, and the one every financial statement is expressed in. Any document in another currency needs an exchange rate at three separate moments, not one:

• At invoice or bill issue: mandatory whenever the document's currency differs from the functional currency, and it becomes that document's fixed "historical rate." A document in the functional currency itself is pinned to 1 automatically, so there is no chance of it posting at a rate nobody actually chose.
• At payment settlement: a separate, optional rate for the day of payment. If entered, the cash is booked at that rate while the receivable or payable clears at its own historical rate — and the gap between the two becomes realized FX gain or loss. Left blank, the payment books at the invoice's own rate and no realized gain or loss arises at all.
• At period-end revaluation: a closing rate the accountant enters for each foreign currency still carrying an open balance — specifically accounts receivable and accounts payable, not every account.

Realized or unrealized: two different questions

The two sound like synonyms until you ask when each is computed, and why. One arises from an event — cash actually changing hands at a rate different from the invoice's own. The other arises from nothing but the calendar — a balance still open on a later date, looked at with a new rate.

The reversal is scheduled, not automatic

A revaluation entry does not rewrite the receivable as its original invoice recorded it — that stays at its historical rate forever. It is an adjustment against the general-ledger control account alone: debiting or crediting the AR or AP account, with the other side landing on a system FX account, explicitly labelled "unrealized FX gain" or "unrealized FX loss." Because the balance can change by next month — a payment lands, or the rate moves again — the adjustment is dated with a reversal date of the first day of the following month, a stamp the entry carries rather than a background job that fires once that date arrives; the control account returns to its real value once that reversal is actually posted, before the next revaluation runs fresh against the new numbers.

Revaluation's reach stops at open receivables and payables specifically — it does not touch a foreign-currency bank account balance. It is an on-demand action, not a job that runs itself on a schedule; the accountant decides when to run it — typically monthly or quarterly — and at what closing rate. The dated reversal itself is posted the same on-demand way, through the same "process scheduled reversals" step used for any other reversing or recurring entry — nothing fires by itself purely because the calendar reached that date. And running the revaluation twice against the same date is not a way to correct a mistaken closing rate: the second run is blocked as a duplicate and simply returns the original entry unchanged, so the closing rate is worth getting right before you post it, not after.

Tax is computed in the invoice's own currency

The order here is worth stating plainly, because reversing it is a common mistake. Tax is computed per line in the invoice's own currency first — that is the legally reportable figure that appears on the document and feeds the tax-return report. Conversion into the functional currency happens afterward, for exactly one purpose: posting the entry to the general ledger. Conversion does not recompute the tax in another currency; it re-expresses the same already-computed figure.

And when the document finalizes, its total converts as one lump sum at its historical rate rather than as a sum of separately-converted lines — a receivable built from independently rounded parts later drifts against the payment that settles it by a fraction with no economic meaning. Whatever small gap that choice produces, if any, posts on its own under "FX rounding" — entirely separate from realized or unrealized FX gain or loss, because it is not a gain or a loss, only a rounding artifact.

The problem that starts at the third decimal place

Currencies in the region split into two groups of close to equal size. Five divide into a hundred subunits, the way most currencies elsewhere do. Six do not: the Kuwaiti, Bahraini, Jordanian, Iraqi and Tunisian dinars, and the Omani rial — five actual dinars and one rial — each divides into a thousand instead. All six need a third decimal place that the Saudi riyal, the UAE dirham and the Egyptian pound do not.

What this means in practice

• Enter the invoice's rate accurately at issue — it is fixed from that point on, and will not be recomputed later however the real rate moves.
• Only fill in a settlement rate when you actually want realized FX gain or loss recorded; leaving it blank is a valid choice, not an omission, especially when the gap is trivial.
• Run period-end revaluation regularly wherever open foreign balances exist — how often, monthly or quarterly, stays the accounting office's call rather than a rule the system imposes.
• A credit note is always issued in the original invoice's own currency — a dollar invoice cannot be amended by a euro credit note.