A purchase in foreign currency involves at least three values to distinguish: a reference rate used as a benchmark, the rate actually applied by the provider, and the explicit fees of the payment. The spread is the gap between two comparable rates, after aligning their direction and timestamp; it is not automatically the entire cost. Keep the supplier amount, the debited amount, each currency, the date, and the provider's breakdown. Use the actual debit for the observed landed cost. For a simulation, show the chosen rate, the spread assumption, and the fees separately, without presenting ECB reference rates as transaction rates.
Three layers for a single transaction
The supplier invoices in a source currency. The provider converts or debits another currency. A market page may provide a benchmark. If the model only keeps a "rate = 1.XX" field, it becomes impossible to know what that value represents.
The European Central Bank publishes euro reference rates for information purposes and advises against using them for transactions. These rates are quoted against the euro and are usually updated on business days according to its calendar. They can serve as a dated checkpoint, but they are neither a promise from the provider nor a price accessible to the seller.
A provider may advertise a rate and charge a separate line item. Another may fold part of the cost into the rate. Wise, for example, explains in its official documentation that it displays a rate and fees whose amount depends on the transfer's parameters. This source illustrates the need to read the breakdown of the provider actually used; it does not describe every provider and is not a service recommendation.
The minimal record of a foreign-currency payment
| Field | Example status | Why keep it |
|---|---|---|
| invoiced amount | observed on the invoice | proof of the supplier price |
| invoiced currency | confirmed | avoids ambiguity of a symbol |
| debited amount | observed on the statement | observed cash cost |
| debited currency | confirmed | basis for the landed cost |
| reference rate | informational and dated | comparison benchmark |
| provider rate | quoted or observed | conversion actually applied |
| explicit fees | quoted or charged | cost separate from the rate |
| date and time | observed | aligns the values being compared |
| refund or adjustment | observed later | final reconciliation |
The guide on normalizing currency without hiding the exchange cost explains the general structure. Here, the goal is to break down the payment cost so a spread and a commission are not added, omitted, or counted twice.
Calculating a comparable rate gap
Start by putting both rates in the same direction. If the benchmark expresses source-currency units per euro while the provider shows euros per source-currency unit, invert one of the rates in a calculated column without erasing its raw form. Note the formula.
Then align the timing. A reference rate published for one day and a payment executed on another date does not measure only the spread: the market may also have moved. Present the gap as "difference from the chosen benchmark," not as the provider's guaranteed margin.
Finally, identify the explicit fees. If the statement doesn't allow separating the rate from the fee, calculate an overall effective cost from the debited amounts, but mark its composition as unknown. Do not fabricate a breakdown.
Four-step procedure
1. Archive the order. Record the amount, currency, supplier, planned date, and payment method, with no sensitive data in the editorial log. 2. Create the scenario. Choose a dated benchmark, add a provider rate assumption and explicit fees. Every assumption stays editable. 3. Read the confirmation. Before paying, check the amount received by the supplier, the debited amount, the rate, the fees, and the validity period shown by the provider. 4. Reconcile the statement. After execution, replace the estimate with the observed debit and keep the gap. If a line remains unclear, mark it "to confirm."
Fictional breakdown example
The following values are entirely hypothetical and express no actual rate or fee. A fictional invoice is worth 200 units of currency X. An educational benchmark gives 2 X per 1 EUR, i.e. a reference value of 100 EUR. The fictional provider converts the transaction for 102.50 EUR before an explicit fee of 1.50 EUR. The total debit is therefore 104 EUR.
The breakdown is:
- hypothetical reference amount:
200 / 2 = 100 EUR; - gap linked to the conversion in this exercise:
102.50 − 100 = 2.50 EUR; - hypothetical explicit fee:
1.50 EUR; - total effective cost:
104 EUR.
The observed landed cost uses 104 EUR. The 2.50 EUR and 1.50 EUR only explain the gap because the fictional scenario supplies these two lines. If the provider only shows a debit of 104 EUR, the total remains usable but the breakdown must not be invented.
Connecting payment, VAT, and landed cost
The exchange rate does not determine whether VAT is recoverable. That question depends on the regime, the transaction, and the supporting documents. The guide pre-tax price, tax-inclusive price, and recoverable VAT helps choose a base without automatically turning every tax into a cost or a receivable.
In the full landed cost on Amazon, assign the supplier debit to the purchase cost and the payment fees to an explicit line. If the supplier later grants a credit note, link the adjustment to the original transaction. A refund conversion can create a new gap; it must not silently change the historical rate of the purchase.
Managing simulations without false precision
For a future purchase, use several scenarios if the exchange rate is significant. The central scenario relies on a benchmark and current conditions. The unfavorable scenario adds an explicit assumption chosen by the seller. No universal percentage guarantees the necessary caution.
Show the scenario's validity date and invalidate it when the quote, rate, or fees change. A result precise to the cent is not a certainty if the payment has not yet been executed. The seller must see what is observed and what is assumed.
What ArbitragePro+ can automate / what the seller must verify
The convertisseur-devise function is a proposed specification, not a confirmed feature in the application. It could keep both rate directions, align currencies, isolate explicit fees, and compare the scenario against the actual debit. It should flag non-comparable dates and reject an ambiguous currency.
The seller must verify the provider's quote, their account terms, the amount received, the debit, the fees, and the supporting documents. They also validate the tax basis with the relevant professional and choose the assumptions for future scenarios.
Checklist before locking in the cost
- The invoice amount and currency are kept.
- The debit amount and currency are confirmed.
- The compared rates share the same direction.
- Dates and times are visible.
- The ECB rate remains an informational benchmark.
- Explicit fees are not included twice.
- An unknown breakdown stays unknown.
- The final landed cost uses the observed debit.
- Every simulation carries its assumptions and expiry date.
Official sources
- European Central Bank, euro foreign exchange reference rates: https://www.ecb.europa.eu/stats/policy_and_exchange_rates/euro_reference_exchange_rates/html/index.en.html — accessed 2026-08-17.
- European Central Bank, framework for the euro reference rates: https://www.ecb.europa.eu/stats/pdf/exchange/Frameworkfortheeuroforeignexchangereferencerates.en.pdf — accessed 2026-08-17.
- Wise, official help center, transfer fees: https://wise.com/fr/help/articles/2522717/frais-pour-envoyer-de-largent — accessed 2026-08-17.
