Invoicing a customer in their own currency is a courtesy that costs you almost nothing and wins work. The complexity is not in the invoice. It is in the fact that your books are kept in one currency and the world is not.
Two currencies, always
Every foreign transaction has two currency dimensions, and confusing them is the source of most multi-currency problems.
- The transaction currency. What the document is denominated in. The customer’s currency on an invoice, the supplier’s on a bill.
- The accounting currency. The single currency your ledger, your balance sheet and your profit and loss statement are read in. Sometimes called the functional or base currency.
An invoice for 5,000 USD in a business whose books are in EUR is both: five thousand dollars to the customer, and whatever that converted to in your ledger. Both figures are real and both need keeping.
Which rate, and when
This is where implementations differ, and where you should find out what yours does before you need to explain it.
| Situation | What should happen |
|---|---|
| Transaction is in your accounting currency | Rate is 1. No lookup, no provider call, nothing to store. |
| Dated today | Today’s verified rate, frozen onto the record at save time. |
| Backdated | Depends entirely on whether your rate source has history. Many do not. |
| Future-dated | There is no rate yet. Whatever is used is a placeholder. |
| You type your own rate | Used exactly as entered, and flagged as a custom rate so a later reader knows. |
The backdating problem
Most consumer-grade rate providers serve current rates only. So when you enter an expense dated three weeks ago, there is often no historical rate to look up. The honest options are to use today’s rate and say so, or to require you to type the rate that actually applied.
What you want to avoid is a system that silently uses today’s rate for a backdated entry without telling you. The number is not wrong exactly, but it is not what it appears to be, and a year later nobody can tell the difference.
Freeze the rate, do not recalculate it
Once a transaction is saved, its converted amount should never change. If your system re-converts historic entries when rates move, last month’s closed accounts will quietly differ from what you reported. The rate on the record is evidence of what you booked, not a live figure.
Rounding is not always two decimals
A surprisingly common bug: assuming every currency has two decimal places. ISO 4217 says otherwise.
| Minor units | Currencies | Example |
|---|---|---|
| 0 | JPY, KRW, VND, ISK, CLP and others | ¥1500, never ¥1500.00 |
| 2 | Most currencies | $19.99 |
| 3 | KWD, BHD, OMR, TND and others | KWD 12.345 |
Get this wrong and you produce invoices that look wrong to the recipient and totals that fail validation on structured e-invoicing networks.
Where to round
Round at the end, not at each step. Converting each line and rounding it, then summing, produces a total that differs from converting the sum. Neither is wrong in principle, but they disagree, and the disagreement is what a customer will notice.
Exchange gains and losses
You invoice 10,000 USD. At the time, that is 9,200 EUR in your books. The customer pays two months later and the same 10,000 USD is now worth 9,050 EUR.
You received exactly what you invoiced. Your books are short 150 EUR. That difference is a realised exchange loss, and it is a real cost of trading internationally.
Two things follow. It belongs in its own account rather than being buried in revenue, because it is not a trading result. And it is a reason to invoice in your own currency where the customer will accept it, since whoever holds the currency risk is a commercial decision rather than an accounting one.
Practical decisions
Which currency to invoice in
- Your currency is simplest and puts the FX risk on the customer. Fine for strong relationships, occasionally a barrier in competitive bids.
- Their currency wins work and puts the risk on you. Usually worth it, and worth pricing in.
- A third currency, usually USD, is common in some industries and means both parties carry risk.
Getting paid across borders
The exchange rate is rarely the biggest cost. Bank margins on incoming international transfers, intermediary fees and unfavourable conversion at the receiving end usually exceed the market spread by some margin. Providers built for cross-border collection tend to be cheaper than a traditional bank transfer, which is worth checking against your own numbers rather than assuming.
How Invoice Crowd handles multi-currency
Multi-currency in Invoice Crowd runs the length of a record: the amount as billed or paid, the rate that converted it, the date that rate proves, and the single accounting currency your ledger is read in. The accounting currency is set once per business profile.
The rate rules are explicit, which is the useful part:
- Where the record’s currency already matches your accounting currency, the rate is 1 and no provider call is made.
- An entry dated today takes the provider’s current verified rate, and that figure is frozen onto the record.
- A backdated or future-dated entry records today’s rate as a fallback, flagged as such, because it is neither the rate that applied on the day nor a forecast. A backdated entry raises a dialog rather than doing this quietly.
- A rate you type is used exactly as entered provided it is positive, and recorded as a custom rate.
- A typed rate matching one already stored for that date keeps the original evidence.
Precision follows ISO 4217 rather than a fixed two decimals, with sixteen zero-decimal currencies including JPY, KRW, VND, ISK and CLP handled correctly, and seven three-decimal currencies including KWD and BHD. The conversion panel names your accounting currency by ISO code rather than a symbol several currencies share.
Old entries are not re-converted when rates move. Each expense, income and invoice keeps the accounting currency code, the exchange rate and the converted amount frozen at save time. The accounting currency itself can be changed later at business profile level, and doing so governs what is recorded from that point rather than restating history.
Everything lands in one set of books, so the general ledger, the balance sheet and the profit and loss statement read in a single currency regardless of how many the invoices were written in. Collection across borders runs through the same payment gateways, several of which are regional.
A short checklist
- Set your accounting currency once and deliberately. Changing it later governs the future, not the past.
- Check what your system does with backdated entries before you enter a backdated one.
- Never re-convert a saved record.
- Confirm minor units for every currency you bill in, especially JPY and the Gulf currencies.
- Give exchange differences their own account so they never masquerade as trading performance.
- Record the rate source alongside the rate. A number with no provenance is a number you cannot defend.
Frequently asked questions
What exchange rate should an invoice use?
The rate on the date of the transaction, frozen onto the record so it never changes afterwards. Invoice Crowd converts at save time using the current rate from its configured provider and stores that rate on the record, along with the rate date and whether the figure came from the provider or was typed in.
What happens with an expense dated last month?
It depends on whether your rate source has history, and most consumer-grade providers do not. Invoice Crowd serves current rates only, so a backdated entry uses today rate as a fallback and raises a dialog telling you so rather than doing it silently. You can override it with the rate that actually applied, which is recorded as a custom rate.
Do old transactions get re-converted when exchange rates change?
They should not, and in Invoice Crowd they do not. Each expense, income and invoice keeps the accounting currency code, the exchange rate and the converted amount frozen at save time. Later market movement does not reach back into a closed record, which is what keeps last month reported figures matching last month books.
How are currencies without decimal places handled?
By following ISO 4217 rather than assuming two decimals. Sixteen currencies including JPY, KRW, VND, ISK and CLP have no minor unit at all, and seven including KWD, BHD and OMR use three decimal places. Getting this wrong produces invoices that look wrong to the recipient and totals that fail validation on structured e-invoicing networks.
Can I change my accounting currency later?
Yes, at business profile level. What it governs is what gets recorded from that point onwards. It does not restate entries that were already converted and frozen under the old currency, so the change is forward-looking rather than retrospective. Treat it as a decision to make deliberately rather than to revisit.
Should I invoice in my currency or the customer currency?
It is a commercial decision about who carries the exchange risk. Invoicing in your own currency is simplest and puts the risk on the customer. Invoicing in theirs wins work and puts the risk on you, which is usually worth it and worth pricing in. Either way, record exchange differences in their own account so they never look like trading performance.
