Selling in a second currency looks like a display problem. Put the euro symbol on the invoice, let the customer pay in euros, done. It is not a display problem. The moment a foreign-denominated balance stays open across a rate movement, your books have to hold two amounts for one transaction and account for the gap between them, and the gap is real money that shows up on the profit and loss.
This post covers the mechanics: what gets tracked, when the rate is captured, what a revaluation is, and the rounding failure that quietly produces an invoice whose lines do not add up to its total.
Three currency roles, not one currency field
Every foreign transaction carries three currency roles, and confusing them is where most multi-currency implementations go wrong.
| Role | What it is | Where it appears |
|---|---|---|
| Transaction currency | The currency the document was denominated in | The invoice the customer receives; the bill the supplier sent |
| Functional currency | The single currency the accounting records are kept in | Every journal entry; the trial balance |
| Presentation currency | The currency a report is displayed in | Statements shown to an investor or parent company |
A euro invoice to a Berlin customer from a business whose books are kept in dollars has a transaction currency of EUR and a functional currency of USD. Both amounts are stored. The customer’s document shows EUR 1,000. The ledger entry shows the USD equivalent at a specific rate on a specific date, and that USD number is what the trial balance sums.
Presentation currency is the one that is genuinely cosmetic, and only that one. Converting a finished statement for display does not change a single posted entry.
The rate has two dates, and the difference is a real gain or loss
A foreign receivable is measured twice: once when it is raised, once when it is settled. The difference between those two measurements is a realised foreign exchange gain or loss, and it is a posting, not a rounding artefact.
Work it through. You invoice EUR 1,000 on a day when EUR/USD is 1.0850. The ledger records a receivable of USD 1,085.00 and revenue of USD 1,085.00. Six weeks later the customer pays EUR 1,000 in full, and the rate that day is 1.1020. The bank receives USD 1,102.00.
The receivable must be relieved at the amount it was recorded at, USD 1,085.00. Cash increases by USD 1,102.00. Those two numbers do not tie, and the USD 17.00 difference is posted to a realised foreign exchange gain account. That is what makes the entry balance, which is the same invariant every other entry obeys under double-entry accounting.
The customer did not underpay or overpay. In their currency the invoice was settled exactly. The gain belongs entirely to the rate movement, and a system that quietly re-values the receivable to make the payment tie is erasing a number that belongs on your income statement.
Revaluation at period end, and what “unrealised” means
Unrealised foreign exchange gains and losses come from balances that are still open when the period closes. A EUR 40,000 receivable recorded at 1.0850 sits on the balance sheet at USD 43,400. If the month closes with the rate at 1.1000, that same claim is now worth USD 44,000 at current rates.
Revaluation posts the USD 600 difference to an unrealised gain, with the other side against the receivable. No cash has moved. Nothing has been settled. The balance sheet simply stops reporting a foreign balance at a rate that is months stale.
Two rules make revaluation tractable:
- Only monetary items are revalued. Receivables, payables, foreign cash balances and loans are revalued at the closing rate. Inventory, fixed assets and prepaid amounts stay at the rate they were recorded at, because they are not claims on a fixed number of foreign currency units.
- Revaluation is per open balance, per currency, at one closing rate. It is a period-end routine that reads open balances and writes one entry, not a continuous recalculation.
When the invoice is finally paid, the total gain across revaluation and settlement equals the single realised difference between invoice-date and payment-date rates. The intermediate postings only change which period recognises which slice of it.
The rounding failure: a two-line invoice that does not equal its own total
Here is the concrete failure, and it is more common than FX volatility.
An invoice has two lines, each EUR 33.33, totalling EUR 66.66. The rate is 1.0850.
| Conversion point | Arithmetic | Result |
|---|---|---|
| Per line, then sum | 33.33 × 1.0850 = 36.163 → 36.16, twice | USD 72.32 |
| Total, then convert | 66.66 × 1.0850 = 72.3261 | USD 72.33 |
One cent apart. Both are defensible arithmetic. Only one can be posted.
If the revenue lines are converted per line and the receivable is converted from the total, the journal entry has debits of USD 72.33 and credits of USD 72.32, and it is unbalanced. In a ledger that treats balance as an invariant rather than a preference, that entry is refused outright. In a ledger that does not, it posts, and the trial balance carries a one-cent discrepancy that nobody can find three months later because the source document looks correct in both currencies.
The fix is unglamorous: pick one rounding point, convert everything else from it, and force the residual cent onto a designated line rather than letting it float. Oneop’s ledger applies a balance tolerance of a ten-thousandth of a unit, two orders of magnitude tighter than a cent, which means a one-cent rounding difference is a rejection and not an allowance. That is deliberate. A tolerance wide enough to absorb rounding errors is also wide enough to absorb real ones.
Which rate to use, and where the choice is not yours
Three rate policies exist in practice, and the right one depends on what the balance is for.
- Spot rate on the transaction date for individual receivables, payables and payments. Most defensible, most work.
- Average rate for the period for income statement aggregates in a presentation currency. Acceptable where the rate is stable and the volume is high.
- Closing rate for revaluing monetary balances at period end. Not optional if you revalue at all.
Statutory reporting rules may fix the choice for you, and tax authorities frequently publish the rate you are required to use. A system that lets you configure a rate source should also record which rate it used on each entry, because “what rate did we book this at” is a question auditors ask about individual documents, not about settings.
How Oneop handles multi-currency
Multi-currency in Oneop is an entitlement on the Business plan, listed as such on the finance module page and on pricing. The ledger mechanics underneath it are the same ones every other entry uses: an invoice debits receivables and credits revenue and tax as one posting with both sides named, a payment moves the receivable to cash, and no posted entry is ever edited. A correction is a linked reversal, which matters more in foreign currency than in domestic, because a rate typed wrong on the invoice date needs a visible reversal rather than a silent amendment.
Two checks stand behind every posting. The posting service sums the debit and credit lines and refuses an unbalanced entry before any row is written, and a database trigger re-sums the lines on the transition to posted and aborts the transaction if they differ. Neither check knows or cares which currency the source document was in, which is exactly the property you want: the rounding decision above has to produce a balanced functional-currency entry or it does not get to exist.
If you are still deciding whether the second currency is worth the machinery, the honest answer is that the mechanics only earn their keep once foreign balances stay open across rate movements. Until then you are maintaining accounts that never receive a posting. The related question of which document should trigger the invoice in the first place is covered in invoicing from what shipped, and the copies-diverge problem that makes currency data drift between systems is covered in connecting CRM, invoicing and accounting.