Invoicing in USD or EUR With Books in Another Currency

You invoice a client in the United States for USD 10,000. Your books are in hryvnia, or zloty, or another currency the client has never held. The invoice is right, the payment arrives, and yet the accountant reports a "loss on exchange" that nobody decided to incur. Or a gain, which is nicer but just as confusing. This post explains where those numbers come from, what is realized and what is not, and why the answer changes once you keep a USD account.

Transaction currency and reporting currency

Every company keeps its books in one currency: the reporting currency (IFRS calls the closely related idea the functional currency). For a Ukrainian company that is normally UAH; for a Polish one, PLN. Every document, however, has its own transaction currency: the currency printed on the invoice. A USD invoice is a USD invoice for the client, for the bank and for the contract. In the ledger it has to be expressed in UAH as well, because the ledger only adds up in one currency.

So each foreign-currency amount is recorded twice: the original amount in USD, and its equivalent in the reporting currency at a specific rate on a specific date. The original does not change. The equivalent does, every time the rate moves and the item is still open. That is the whole source of FX gains and losses.

Which rate? Most companies use the central bank rate of the day (the National Bank of Ukraine or the National Bank of Poland), because it is published, auditable and not chosen by anyone in the company. Some use the bank's actual rate for cash transactions. Pick one policy, write it down, and apply it consistently. The rates in this post are illustrative round numbers, not quotes.

The invoice date fixes revenue

The invoice is issued on 3 March for USD 10,000. The illustrative rate that day is 41.20 UAH per USD. Revenue is recorded at UAH 412,000, and a receivable of USD 10,000 is recorded with the same UAH 412,000 equivalent.

That revenue figure will never change. Whatever the rate does afterwards, the P&L will show UAH 412,000 of revenue from this invoice. The rate movement after the invoice date is not a sales matter; it is a financing matter, and it is reported separately. This separation is what lets you compare the margin on projects without the currency noise.

The same logic applies to a EUR 5,000 invoice on PLN books at an illustrative 4.30: revenue PLN 21,500, receivable EUR 5,000, and the PLN equivalent is reconsidered later.

Period end: revaluing what is still open

On 31 March the invoice is still unpaid. The company closes the month, and the rate is now 41.60. The USD 10,000 receivable is worth UAH 416,000 at today's rate but is carried at UAH 412,000. The books are updated to UAH 416,000, and the UAH 4,000 difference is an unrealized FX gain.

Unrealized because nothing has been converted; the client has not paid. It is a measurement, not a transaction. The same revaluation applies to every open foreign-currency item on the balance sheet: receivables, payables to foreign contractors, and bank balances held in USD or EUR. Each is restated at the closing rate, and the differences go to the P&L as unrealized gains or losses.

Period-end revaluation is the step small companies most often skip, and skipping it makes the balance sheet lie. A USD 40,000 bank balance from last year, still carried at last year's rate, can be off by tens of thousands of UAH.

Payment: the gain or loss becomes real

The client pays on 7 April, 35 days after the invoice. The rate that day is 41.35. USD 10,000 lands, worth UAH 413,500 at the payment-date rate. The receivable is closed.

Over the life of the invoice, the company recorded UAH 412,000 of revenue and received cash worth UAH 413,500. The total FX result is a gain of UAH 1,500. How it is split between March and April depends on one policy choice:

• If the March revaluation is reversed on 1 April (a common practice), April shows the whole UAH 1,500 as a realized gain and March's UAH 4,000 unrealized gain is undone.
• If the revaluation is kept, the receivable is carried at UAH 416,000 going into April, and settlement at UAH 413,500 shows a realized loss of UAH 2,500 in April, against the UAH 4,000 gain in March.

Both routes end at the same place: a net gain of UAH 1,500, revenue untouched at UAH 412,000. What matters is that the policy is fixed and the software applies it the same way every month.

Where it lands on the P&L

FX gains and losses are not revenue and not cost of sales. Under an IFRS-style layout they sit below operating profit, usually as finance income or finance costs, or in a line called "other gains and losses". Realized and unrealized amounts are often kept on separate accounts so that a reader can see how much is settled cash and how much is a measurement that may reverse next month.

Some local GAAP layouts put them in other operating income and expense instead. The location matters less than the consistency: project managers should never see FX inside project margin, and the finance lead should be able to see FX in one place. A configurable chart of accounts, IFRS-based or local, is what makes that possible; TridentERP handles realized FX on settlement and period-end revaluation as ledger postings, so the P&L line drills down to the invoices and revaluations behind it.

Why a multi-currency bank account changes the picture

In the example above the USD 10,000 arrived and was converted to UAH the same day. That ends the exposure: the company holds UAH, and the rate can do what it likes. Many services companies instead keep the USD in a USD account, with Wise or a local bank, and pay USD contractors from it, or wait for a better rate.

This does not remove FX from the books; it moves it. The receivable is settled and its realized gain or loss is booked as before. But the USD bank balance is now an open foreign-currency item, revalued at every period end, producing unrealized gains and losses month after month until the money is converted or spent. When a USD contractor is paid from the USD account, no conversion happens; the payment closes a USD payable at that day's rate, and the difference against the rate on the bill date is a realized gain or loss, as with the receivable.

The practical effect is a form of natural hedge: USD income and USD costs in the same account offset each other, and only the net USD position is exposed. The bookkeeping is heavier, because every period end restates the balance, but the economic risk is smaller. Bank statement imports (Wise, MT940, camt.053) that keep the original currency on each line make this workable; a statement converted to UAH by the bank before import loses the information the revaluation needs.

FAQ

Do unrealized gains count as profit for tax?

That depends on the country and the tax regime: some tax unrealized differences as they arise, others only on settlement. Ask a local tax adviser and keep realized and unrealized on separate accounts.

Can I avoid the whole issue by invoicing in my reporting currency?

You can, but then the client carries the exposure and may push back on price. Most US and EU clients expect USD or EUR invoices, so the usual answer is to accept the exposure and manage it with a USD or EUR account.

What rate should go on the invoice itself?

The invoice needs only the USD amount. The rate is a bookkeeping input on the invoice date; record it in the ledger, not on the document, unless local rules require it.

What to do next

1. Write a one-paragraph rate policy: which published rate, on which date, for invoices, bills, payments and period ends.
2. List every open foreign-currency item (receivables, payables, bank balances) and check when it was last revalued.
3. Add realized FX and unrealized FX as separate accounts below operating profit, if they are not already there.
4. If you hold USD or EUR balances, make period-end revaluation part of the monthly close checklist.
5. Review three months of FX results and confirm the numbers trace back to specific invoices and rates. If they do not, the ledger, not the rate, is the problem.