Invoice a customer in their currency, and your books stay in yours. Turn on multi-currency, tell us each foreign customer's or vendor's currency once, and every document for them is written in it, while your reports never change what they mean.
Turning it on
Open your Books settings and switch on Multi-currency. Pick your home currency (the one your reports read in), and add the currencies you work with. Turning it on also creates an Exchange gain or loss account, where the differences from exchange-rate movement will post on their own.
A company that never touches a second currency never sees any of this: no pickers, no extra columns, nothing.
Your home currency locks once foreign documents exist, because every number in your books is written in it. Pick it before you start, not after.
Each customer or vendor has one currency
Currency is a property of the relationship, not of each invoice. Set it on the customer or vendor in Payees, and every document for them is in that currency from then on. If you work with someone in two currencies, set them up as two payees.
Once foreign documents exist for a payee, their currency locks too. The documents already written in it are the reason.
Writing a foreign invoice or bill
Open an invoice for a foreign customer and the editor tells you at the top: this customer works in their currency. You type your amounts in it, the exchange rate for the invoice date fills in automatically from the European Central Bank's daily reference rates, and the editor shows you both totals side by side, theirs and yours.
You can type a different rate, for example the one your bank quoted. If it is too far from the published rate for that date, the save is refused with both numbers shown, so a slipped digit cannot quietly misprice an invoice. For a date older than the published feed covers, you enter the rate yourself.
The printed invoice, the emailed copy, and the page your customer opens all read in their currency. That is the number they owe. Bills from a foreign vendor work the same way, mirrored. Estimates too, and an estimate that becomes an invoice picks up the rate for the invoice's own date.
Getting paid, and where the difference goes
Here is the part that does the real work. Say you invoiced EUR 1,000 when the rate made it $1,100 in your books. The customer pays three months later, and your bank actually receives $1,047.32.
When you receive the payment, you apply EUR amounts to the invoices and enter one more thing: what your bank actually received, in your currency. Nobody types an exchange rate. The true rate is those two numbers divided, your bank's own rate including its spread, and the $52.68 difference posts automatically to Exchange gain or loss. The preview shows you the derived rate and the gain or loss before you save.
Paying a foreign vendor's bill is the mirror image: you enter what actually left your bank, and if fewer dollars left than the books said you owed, the difference posts as a gain.
Partial payments work the same way, and they close exactly. A EUR invoice paid in three uneven pieces at three different rates ends at exactly zero, in both currencies, with each piece carrying its own gain or loss.
What stays in your currency
Your reports, your account balances, and your bank accounts all stay in your home currency, always. A foreign document carries both sets of numbers: its own currency on the paper, and the home value in your books. Voiding a foreign payment puts both balances back.
A few things deliberately wait: credit memos and purchase orders for foreign payees are not offered yet (the app will tell you so by name if you try), and foreign invoices are settled from the Invoices screen rather than paid online.