An exchange rate in BlossomERP is a stored fact: for a pair of currencies and a date, how many units of the second one unit of the first buys. Rates live per company, and are only ever read from that store — no screen and no posting consults a feed in the middle of your work.
Where rates come from. Your company chooses (7.12): enter rates by hand, or have them fetched daily from published reference rates — the European Central Bank's daily feed is the primary source, and a second public feed fills the currencies the ECB does not publish (several African and Gulf currencies among them). Whichever the source, the result is the same stored, dated, inspectable rows: System Setup → Exchange Rates shows every rate your documents will use, and a rate you type yourself always stands for its date.
How a document gets its rate. When a document's currency or date changes, the rate fills itself in: the latest stored rate for the pair on or before the document's date. If the pair was never stored directly, the application tries the inverse (the reverse pair, turned upside down), then a cross through a pivot currency — your home currency first, then the dollar, then the euro. At posting, the resolved rate is frozen onto the document: later rate movements never rewrite history (1.11).
Where differences land. Because rates move between an invoice and its settlement, settling foreign money produces realized exchange gains and losses — computed per allocation, invoice rate against settlement rate, and posted openly to your flagged FX gain/loss account (7.5). GRNI clearing splits its difference the same honest way (Chapter 4): the price part to price variance, the rate part to realized FX. Bank legs follow 7.6's rule — valued at the stored rate for the document's date, the difference likewise realized.
What never happens. A rate is never invented. A pair with no stored rate leaves a document's rate blank, and a posting that cannot resolve a rate it needs stops and names the pair and the date.
Revaluing what is still open. An unpaid foreign invoice stays in the books at its booked rate while the period runs — but at period end your company can choose to restate what is still open. The FX revaluation switch (in the company settings) turns on a period-end run, offered on the period itself (Revalue FX balances): it lists every open foreign sales and purchase invoice — its balance, the rate it was booked at, the closing rate (the latest stored rate on or before the period's last day) and the difference — and, on your confirmation, creates two draft batches: the revaluation, which moves the receivables and payables control accounts to the closing rate with the difference posted to your unrealized FX gain/loss accounts (the ones you map in the company settings, or the chart's Unrealized FX Gain/Loss account until you do), and an auto-reversal dated the first day of the next period that undoes it. Reviewers post both drafts from GL Batches, like any other batch. The auto-reversal is what keeps the books honest: the new period starts again from booked rates, so each period's run measures the whole movement afresh — nothing is counted twice — and when the invoice is finally settled, its realized difference is still measured against the rate it was booked at. Re-running a period whose drafts are still unposted replaces them; a run that has been posted must be reversed before the period can be revalued again. An invoice whose closing rate was never stored is blocked by name and left out of the batch: the worksheet shows it with its reason, and no rate is ever guessed for it.
Bank balances are revalued too — account by account. The same switch turns on a second run, offered on the period itself (Revalue bank FX balances). For every bank account held in a foreign currency it lists the balance in the account's own currency, the closing rate, the value that balance currently carries in your home-currency books, and the unrealized difference between the two. On your confirmation it creates — per account — the same kind of draft pair: a revaluation that moves the bank account's home-currency carrying value to the closing rate, with the difference on your unrealized FX gain/loss accounts, and an auto-reversal dated the first day of the next period. Reviewers post both drafts from GL Batches. Only the translated value moves: the balance in the bank's own currency never changes, so your reconciliation in that currency is untouched. Re-running a period replaces its accounts' unposted pairs; a posted pair must be reversed before the period can be revalued again. A bank whose closing rate was never stored is blocked by name, and so is a bank whose own-currency balance cannot yet be stated — one whose history predates currency adoption (7.6) — until you adopt its balance on the Bank form. Neither is ever guessed at.