Cross-rate settlements
A cross-rate settlement is what happens when you settle an invoice against a payment (or credit, or prepayment) denominated in a different transaction currency - for example, applying a USD customer payment against a EUR sales invoice. The system does not require the two sides of a settlement to share a currency. When they don't, it automatically resolves the exchange rate between them and settles the transactions correctly, recognizing any resulting gain or loss along the way.
This page documents the exact mechanics - which rates are used, how the gain or loss is calculated, and what posts to the ledger - so you can verify system behavior against your own accounting policy. It applies equally to Accounts receivable and Accounts payable; examples for both are included below.
Conceptual overview
Every posted transaction - an invoice, a payment, a credit, a cash discount line - carries its amount in three currencies:
- Transaction currency: the currency the document was issued in (the invoice's or payment's own currency).
- Accounting currency: your ledger's base currency.
- Reporting currency: a secondary ledger currency used for consolidated group reporting.
The accounting-currency and reporting-currency amounts are calculated once, when the transaction is posted, using the exchange rate in effect on that transaction's own date. That rate is then frozen on the transaction - it is never recalculated later, even if market rates move. This is standard historical-cost treatment: a transaction's own carrying value in accounting currency doesn't drift just because rates moved after it was booked.
A cross-rate settlement arises whenever two transactions with their own, independently frozen rates - and, in this case, different transaction currencies entirely - are settled against each other. The system needs a third rate, one that exists nowhere on either transaction: the rate between the two transaction currencies themselves, as of the settlement date. That is the "cross rate."
When it happens
Cross-rate settlement is not a separate mode you turn on. Any settlement path in the system resolves it automatically the moment it detects the invoice side and the payment side are in different currencies:
- Settling transactions manually from the Settle Transactions action on the Customer transactions or Vendor transactions pages.
- Settling an invoice automatically as part of posting a payment journal.
- Applying a prepayment to an invoice.
There is nothing to configure to enable this. The only prerequisite is that an exchange rate exists (directly, or via triangulation - see below) between the two currencies involved, for the settlement date.
Which exchange rates are used
Three distinct rates are in play for any single cross-rate settlement, and it's worth being precise about which is which:
- The invoice's own rate - frozen at the invoice's posting date. Used to determine how much of the invoice's own accounting/reporting-currency balance this settlement consumes.
- The payment's own rate - frozen at the payment's posting date. Used to determine how much of the payment's own accounting/reporting-currency balance this settlement consumes. This is not the same rate as the invoice's, even when both transactions happen to be in the same non-accounting currency, because each was frozen on its own date.
- The cross rate - resolved fresh, at the moment of settlement, using the settlement's transaction date (defaulting to today if none is specified). This is the only one of the three that is not stored anywhere; it exists only to translate the settlement amount from the invoice's currency into the payment's currency (or vice versa), so that each side's own balance is reduced by the correct amount in its own currency. It is resolved by:
- Looking up a direct exchange rate between the two transaction currencies for that date, if one is configured, or
- Otherwise, automatically triangulating through your organization's designated triangulation currency (configured on the Exchange rate types page) - converting currency A to the triangulation currency, then the triangulation currency to currency B, and combining the two rates.
If neither a direct rate nor a triangulation path exists for the settlement date, the settlement fails outright. Add the missing exchange rate (or configure a triangulation currency) before retrying - there is no fallback or default rate.
Because the cross rate is derived, not stored, there is no persisted "cross-rate" field anywhere on a settlement record. If you need to know the effective rate that was used for a specific past settlement, derive it from what is stored: each side's own settlement-currency amount and its accounting-currency equivalent (see Settlement records, below) - dividing one by the other reconstructs the rate that was applied to that side.
Realized exchange gain or loss
Whenever the invoice side's accounting-currency value for a settlement and the payment side's accounting-currency value for the same settlement differ, the difference is recognized immediately as a realized exchange gain or loss, in compliance with ASC 830 and IAS 21. This is not a mechanism specific to cross-rate settlement - the exact same calculation already runs for a same-currency settlement whenever the invoice and payment were posted on different dates and their frozen rates happened to differ. A cross-rate settlement simply makes a difference between the two sides far more likely, since the transaction currencies themselves are different on top of any date-driven drift.
The formula (both sides always expressed as positive accounting-currency magnitudes for this settlement):
- Accounts receivable:
Gain/Loss = Payment's accounting-currency amount − Invoice's accounting-currency amountA positive result is a gain (the payment, revalued to accounting currency, is worth more than the receivable it's clearing). A negative result is a loss. - Accounts payable:
Gain/Loss = Invoice's accounting-currency amount − Payment's accounting-currency amountA positive result is a gain (the liability is being cleared for less, in accounting-currency terms, than it was originally booked for). A negative result is a loss.
Each side's own accounting-currency amount for the settlement is calculated using that side's own frozen rate (rule 1 and 2 above) - not the cross rate, and not the other side's rate. The cross rate only decides how much of each side's own balance the settlement consumes; it plays no direct role in the gain/loss formula itself.
If a settlement fully closes a transaction's remaining balance, the system does not multiply by the exchange rate at all for that side - it instead takes whatever accounting-currency amount is left (the original amount minus whatever has already been settled), exactly. This prevents fractional-cent drift from accumulating across several partial settlements and leaving an unclearable residual balance. Every settlement before the final one still uses straight rate multiplication, rounded to the currency's normal precision.
General ledger entries
If the realized adjustment for a settlement is non-zero, it posts as its own journal entry - separate from the settlement itself - identified by a dedicated EXCH- voucher and linked back to the invoice's own document number for traceability. The two account legs are:
| Module | Result | Debit | Credit |
|---|---|---|---|
| Accounts receivable | Gain | Customer control account (Accounts receivable) | Realized exchange gain |
| Accounts receivable | Loss | Realized exchange loss | Customer control account (Accounts receivable) |
| Accounts payable | Gain | Vendor control account (Accounts payable) | Realized exchange gain |
| Accounts payable | Loss | Realized exchange loss | Vendor control account (Accounts payable) |
The realized gain/loss accounts are configured once on the ledger (the accounts used for currency revaluation); if either is missing, the settlement fails rather than posting an adjustment to an unconfigured account.
Why the control account moves, not just a gain/loss account: the settlement itself already posted the payment side's contribution to the control account using the payment's own rate - which, before this adjustment, may not exactly match what the invoice's own rate says was owed. The adjustment entry corrects the control account back to the invoice's true booked value, with the offsetting amount landing in the realized gain or loss account. Both legs always use the same amount, in both accounting and reporting currency.
Settlement records
Every settlement creates a record on both the invoice and the payment side, visible from View Settlements on the Customer transactions or Vendor transactions pages. Each record carries:
- The settlement amount in that side's own transaction currency.
- The settlement amount converted to accounting currency, and to reporting currency.
- The exchange rate that side's own transaction currency used for this settlement (its frozen rate at the time - see above).
There is no separate field recording the cross rate itself; as noted above, it can be reconstructed from the two sides' own recorded amounts and rates if needed.
Worked examples
Example 1: Accounts receivable, partial settlement, realized gain
A sales invoice INV-1001 is posted on 2026-01-10 for EUR 1,000.00, converted at that date's EUR to USD rate of 1.08 (accounting currency is USD): accounting-currency amount = USD 1,080.00. This rate stays frozen on the invoice from now on.
An unallocated customer payment PAY-2002 is posted the same day for USD 700.00 (already in the accounting currency, so its own rate to accounting currency is 1.00).
On 2026-02-01, EUR 550.00 of the invoice is settled against part of this payment via Settle Transactions. The cross rate looked up for that date is EUR to USD 1.10.
| Step | Calculation | Result |
|---|---|---|
| Invoice's own accounting-currency amount for this settlement | 550.00 × 1.08 (invoice's own rate) | USD 594.00 |
| Amount consumed from the payment (cross rate) | 550.00 × 1.10 | USD 605.00 |
| Payment's own accounting-currency amount for this settlement | 605.00 × 1.00 (payment's own rate) | USD 605.00 |
| Realized adjustment | 605.00 − 594.00 | +USD 11.00 gain |
Posted: Debit Accounts receivable USD 11.00, Credit Realized exchange gain USD 11.00.
Resulting balances: the invoice has EUR 450.00 still open; the payment has USD 95.00 (700.00 − 605.00) still available for future settlements.
Example 2: Accounts payable, final settlement, realized loss
A purchase invoice PINV-500 is posted on 2026-01-15 for GBP 500.00, converted at that date's GBP to USD rate of 1.30: accounting-currency amount = USD 650.00.
A vendor payment PAY-VEND-77 is posted the same day for USD 700.00 (already in the accounting currency, own rate 1.00).
On 2026-02-10, the full GBP 500.00 invoice is settled against part of this payment. Because this fully closes the invoice's balance, the final-leg rule applies on the invoice side. The cross rate looked up for the settlement date is GBP to USD 1.34 (the pound has strengthened since the invoice was booked).
| Step | Calculation | Result |
|---|---|---|
| Invoice's own accounting-currency amount for this settlement (final leg, exact remainder) | 650.00 − 0.00 already settled | USD 650.00 |
| Amount consumed from the payment (cross rate) | 500.00 × 1.34 | USD 670.00 |
| Payment's own accounting-currency amount for this settlement | 670.00 × 1.00 (payment's own rate) | USD 670.00 |
| Realized adjustment | 650.00 − 670.00 | −USD 20.00 loss |
Posted: Credit Accounts payable USD 20.00, Debit Realized exchange loss USD 20.00.
Resulting balances: the invoice is fully closed (GBP 0.00 open); the payment has USD 30.00 (700.00 − 670.00) still available.
Same-currency settlements can still produce a gain or loss
Cross-rate settlement is not the only trigger for a realized adjustment. If INV-1001 and PAY-2002 in Example 1 had both been in USD, but PAY-2002 had been posted on a later date when USD's rate to the accounting currency (if the accounting currency were a third currency) had moved, the exact same formula would still produce a gain or loss - it is driven by any difference between the two sides' own frozen rates, not specifically by a currency mismatch.
Things to be aware of
While entering a settlement, the accounting/reporting-currency figures shown in the dialog's summary are calculated client-side from the primary transaction's own known rate, without a live cross-rate lookup. In a genuine cross-rate scenario, the actual posted realized gain/loss (and the payment side's true accounting-currency consumption) is only computed authoritatively when you apply the settlement. Treat the dialog's figures as a preview of the primary transaction's own side, not a prediction of the final gain or loss.
The settlement amount you enter is capped against the invoice's own remaining balance, but the amount it translates to on the other side, after the cross rate is applied, is not separately capped against that side's own remaining balance. In ordinary use this isn't reachable through the Settle Transactions dialog, since the picker only offers amounts within what's available - but if you are settling programmatically, or chaining several settlement lines without refreshing balances in between, be aware that an unfavorable cross-rate move between two transaction currencies could in principle push a payment's or credit's SettledAmount past its own Amount. Refresh balances before settling in that situation.