The exchange-rate widget did not tell you what you paid

A shop prices a product in euros. A shopper sees an instant dollar conversion and assumes that is what the bank will charge. The card network, merchant, bank, payment date and possible fees may produce a different settled amount. The displayed conversion was an estimate, not a receipt.

Even a precise exchange rate is incomplete unless it is tied to a source, timestamp, direction, applicable spread and execution terms.

Locale data such as Unicode CLDR^{[1]Unicode CLDR} helps format currencies and numbers for readers. It cannot infer which party owns the transaction or what contractual rate is available. Currency symbols are often ambiguous, while currency codes identify monetary denominations more explicitly.

A reference rate published for information is not necessarily a rate at which a particular buyer can exchange funds. A quote may expire; a card authorization may differ from final settlement; a refund may occur after the market moves.

Suppose a transaction for €100 is displayed at an illustrative market rate of 1.10 dollars per euro, giving $110 before fees. If the execution rate is 1.12, the conversion becomes $112. A 2% conversion charge on that amount adds $2.24, yielding $114.24 in this simplified scenario.

Those numbers are hypothetical. The point is that a single exchange-rate field cannot represent a contract specifying provider, spread, charges, currency, precision and settlement event.

A company may recognize a purchase obligation on one date, settle it later, and value it for reporting under particular accounting rules. The exact exchange gain or loss depends on the accounting context, not merely on the latest number in a widget.

A ledger should preserve original currency amount, transaction currency, relevant rate source, rate time, applied fees, booking entries and settlement evidence. Converting the stored original into a single home-currency string destroys information needed for reconciliation.

A financial assistant that can show rates is not authorized to exchange funds. A prepared estimate does not guarantee a trade, and a successful API response does not by itself prove final settlement. The action path needs the account owner's consent, appropriate provider capabilities, and a record of executed terms.

That is the distinction between informational convenience and dependable financial infrastructure. Good software makes the differences visible instead of hiding them behind a convincingly formatted dollar sign.