Currency on Documents
When you raise a Sales Invoice, a Purchase Order or a Journal Entry, it has a currency — and here's the reassuring part: you almost never have to choose it. REDA fills it in from the company you're raising the document for, and keeps the whole document in one currency. This article explains where a document's currency comes from, how you change it for the occasional foreign-currency document, and the guardrails that keep every document internally consistent.
Access you'll need. Whoever can raise the document (the relevant Accounts Payable v2 / Accounts Receivable v2 / Accounting Admin v2 set) sets its currency. Turning multi-currency on and configuring entity currencies requires the Accounting Admin v2 or Accounting Controller v2 permission set.
Currency comes from the company
Every document belongs to an entity (one of your companies), and the document's currency is automatically set to that company's home (functional) currency. Raise an invoice from Meridian Properties UK Ltd and it's in GBP; raise one from Meridian Properties US LLC and it's in USD. You don't pick — the company decides, because that's the currency its books are kept in.
Single-currency vs multi-currency
| Mode | What you see |
|---|---|
| Single-currency | Every document is in the one org currency. There's literally no currency to choose — it just is, and no picker appears. |
| Multi-currency | The document defaults to the company's home currency, and a Currency picker on the form lets you change the header to a foreign currency when you need to bill in one. |
The Currency picker — and when it locks
In a multi-currency org, document forms show a field simply labelled Currency. It offers every currency your administrator has activated for the org, with the entity's home currency pre-selected. Change it before you add lines: the moment a document has lines, the picker locks, and trying to change it tells you plainly — "Currency cannot be changed after lines have been added."
Raising a foreign-currency document
Sometimes a UK company has to invoice a customer in euros. In multi-currency mode you set the Currency picker to EUR, enter the amounts in euros, and that's what the customer sees on the PDF. Behind the scenes, when you post it, REDA converts the euros to the company's home currency (GBP) at the dated rate for the document's date — because the books are always kept in the home currency — and stamps that rate onto the document, so the conversion is permanently on record. If that invoice is later paid when the rate has shifted, the small difference is recorded as an exchange gain or loss (see FX accounts).
A note on product prices
When you drop a product onto a line, REDA checks that the product's price currency matches the document's currency. A product priced in GBP won't drop onto a USD document — you'll see "Product currency (GBP) does not match the document currency (USD). Select a product in USD or change the document currency." The simplest habit: keep each product's list price in the currency of the companies that sell it, and type the price directly on the line for the occasional foreign-currency sale.
Journals that touch more than one company
A Journal Entry can carry lines for a different entity than its header (that's how intercompany journals work) — but only when both companies share the same home currency. Put a line for a GBP company on a USD company's journal and REDA stops you: "Cross-entity lines must share the same functional currency — use an intercompany invoice to recharge across currencies." The reason is the same discipline as everywhere else: a journal is one document in one currency, and each company's side must land in its own books at a defensible rate — which is exactly what an intercompany invoice does properly.
The guardrails, in one table
| The message | What it means / what to do |
|---|---|
| "Currency cannot be changed after lines have been added." | Choose the document currency before building lines. To change it now, remove the lines first. |
| "Product currency (…) does not match the document currency (…). Select a product in … or change the document currency." | The product's list price is in a different currency. Pick a matching product, or price the line by hand. |
| "No exchange rate found for … effective on …" | No dated rate covers the document's date. Load the rate, then post. See Exchange Rates. |
| "Cross-entity lines must share the same functional currency — use an intercompany invoice to recharge across currencies." | A journal line's company keeps books in a different currency than the header's company. Recharge with an intercompany invoice instead. |
Where to go next
- Exchange Rates — the rates that convert a document's currency.
- 3-Tier Currency Architecture — the three currencies behind each document.
- Understanding Multi-Currency — the big picture, start to finish.
- Enabling Multi-Currency — switch it on before you begin.
Frequently asked questions
No — an invoice is in a single currency. The lines lock to the header. If you need to bill the same customer in two currencies, raise two documents.
You were probably seeing the home-currency (converted) value rather than the billed (document) value, or a group report in the corporate currency. Both are correct — they're different levels of the same amount.
Not as a true converted document. Foreign-currency documents and the conversion that goes with them require multi-currency to be enabled. See Enabling Multi-Currency.
No: the dated rate in force on the document's date, applied when it posts and stamped onto the document. Looking at the invoice months later, you'll still see exactly the rate it was converted at.
Only commercially. The document's currency is whatever you set the Currency picker to — usually what you agreed to bill in. REDA doesn't force a customer to one currency; the same customer can hold a EUR invoice and a GBP invoice side by side.
Was this article helpful?