A guest may see the room rate in euros and pay cash in pounds while the hotel's base accounting currency is Turkish lira. One exchange-rate field is not enough in this situation. Track separately the quoted currency, payment currency, conversion-rate type and the physical cash remaining in the drawer. Otherwise, a folio may appear closed while the foreign-currency drawer is short, an exchange difference is posted to the wrong revenue account or a refund amount becomes disputed. This guide turns foreign-currency collection into an auditable process from reservation to shift close.

What you will learn in this article
  • Store the hotel's base currency, the reservation's rate currency and the payment currency in separate fields.
  • Do not assume that charges, payments and cash currency exchanges must use the same rate; link the transaction type and effective time to the record.
  • Link a refund to the original payment's currency, method, amount and rate reference; never rewrite the historical transaction with a later rate.

Separate the three currencies

A foreign-currency stay can involve at least three currencies. The property currency is the base unit for accounting and reports. The rate currency is the unit used to quote the reservation or room rate. The payment currency is the cash or card currency actually paid by the guest. For example, the room rate may be EUR 120, the payment GBP 105 and the property currency TRY. Compressing all three into one field makes it impossible to understand later how the transaction was settled.

For every movement, the PMS should retain the source amount, source currency, applied rate, property-currency equivalent, rate type and effective time. Showing only the TRY equivalent is not enough; the user must also see the GBP 105 paid by the guest. Oracle OPERA Cloud's foreign-currency configuration likewise supports currency codes and different rate types for pricing, settlement and currency buy/sell transactions. This separation is a fundamental control even for a small hotel that accepts only two foreign currencies.

  • Property, rate and payment currencies were recorded separately.
  • The source amount and property-currency equivalent were shown together.
  • The currency code was defined in ISO format with its symbol and decimal rule.
  • The rate type and transaction time remained visible on the folio.

Choose the right rate for each transaction type

Posting a room charge to the folio, taking a foreign-currency payment and exchanging cash at reception are not the same transaction. Each may follow a different rate policy. Oracle OPERA Cloud documentation defines rate types such as Posting, Settlement and Exchange Cash separately and allows different effective dates for each currency and transaction type. A room charge quoted in a foreign currency may, for example, be converted into the property currency using the posting rate, while the guest's payment is calculated using the settlement rate in effect at that time.

Rate selection should not depend on a user's memory. The transaction screen should automatically load the permitted rate type for the action; only an authorised role should be able to override it, with a reason. The system should prevent saving when the rate is missing or not yet effective. A new rate introduced during the same business day must not retroactively alter completed movements.

  • Posting rules for room charges and settlement rules for payments were defined separately.
  • Cash currency buy/sell transactions were kept separate from payment records.
  • Manual rate changes require an authorised role, reason and approval.
  • Transactions with a missing or not-yet-effective rate were blocked.

Define the rate source and effective time clearly

The property should define its exchange-rate source in a written policy. The source may be the CBRT, a bank, a payment provider or the property's published operational rate. Rates published by the CBRT are indicative and do not automatically mandate the rate applied between parties outside the central bank. Saying 'we use the CBRT rate' is therefore not enough. The system must define which date applies, whether to use the buying or selling rate, the effective time and which prior value applies on a holiday.

Oracle's exchange-rate management documentation states that rates take effect at a specified date and time and remain valid until superseded by a newer rate. This is a safe model for a hotel: retain each rate with its start time, source, type, creator and approver. If the policy uses the previous valid value on holidays or weekends, display that rule clearly as well. This prevents different shifts from selecting different rates for the same transaction.

  • The rate source and buying/selling direction were defined by policy.
  • An effective date and time were added to every rate record.
  • Weekend and public-holiday behaviour was defined in advance.
  • The rate was changed prospectively with a new record rather than deleting the old one.

Show both payment values on the folio

When EUR 200 is collected from the guest, the folio movement should not appear only as 'TRY 7,500 payment'. The line should include the EUR 200 source amount, applied settlement rate, property-currency equivalent, payment method, document or POS reference and user. The guest transaction, accounting entry and physical cashier can then be compared through the same line. Oracle's reservation-account payment workflow also states that, with multi-currency enabled, payments are converted using the current settlement rate.

Exchange-rate rounding must be managed separately. Unless the currency decimals, property-currency rounding rule and destination account for small differences are defined, each payment may leave a small shortage or surplus. Before completion, the system should show the source amount and its equivalent for confirmation; the same rate and rounding result should then appear on the receipt. The source foreign-currency amount must remain available even when the folio balance reaches zero.

  • The source foreign-currency amount and property-currency equivalent were shown on the same line.
  • The rate, method, reference and user were linked to the payment movement.
  • A separate account rule was defined for decimal and rounding differences.
  • Receipt values were matched exactly to the folio movement.

Handle cash, card and change separately

A cash foreign-currency payment creates physical cash, while a card payment depends on bank or payment-provider reconciliation. Even in the same currency, these methods should not be combined in one cashier account. For cash, record denominations, amount received, change given and the currency of the change. For cards, separately track the terminal, transaction number, authorisation result and any later bank fee or conversion.

When the guest gives more cash than the amount due, show the change calculation clearly. Oracle notes that, when configured, a change-due prompt can appear when cash received exceeds the balance. If the hotel gives change in another currency, this second conversion is a separate movement with its own rate and user; it must not be hidden inside the original payment line. The system should not promise change in a currency absent from the drawer and should show available denominations and alternatives.

  • The foreign-currency cash drawer and card/POS account were tracked separately.
  • Amount received, change and change currency were recorded.
  • Card transaction number and terminal details were linked to the payment movement.
  • Change in another currency was logged as a second conversion.

Preserve the original transaction when refunding or voiding

The most important rule when refunding a foreign-currency payment is not to delete the original record. Link the refund to the original payment ID and preserve the source currency, source amount, method and reference. Where possible, return a card payment to the same card with the payment provider's reference. Record a cash refund as an outflow from the relevant foreign-currency drawer. Refunds in another currency or by another method should require property policy and authorised approval.

Even after rates change, do not recalculate and overwrite the historical payment's property-currency equivalent. The refund's accounting effect is created as a separate offsetting movement under property policy and applicable fiscal rules. Before the action, show the original payment, proposed refund and any exchange difference side by side. A refund is a money movement; it does not automatically correct the sales line on the invoice. Track invoice, folio and payment corrections as linked but separate statuses.

  • The refund was linked to the original payment ID.
  • The original currency, amount, method and rate record were preserved.
  • A refund using another method or currency required a second approval.
  • Refund and invoice/folio correction were tracked with separate statuses.

Configure new currencies, including GBP, end to end

Adding pounds sterling is not just adding GBP to a dropdown. Configure the code, symbol, decimal precision, accepted payment methods, posting and settlement rates, cash-drawer account, card account, report column, receipt display and refund permission together. If the system accepts GBP payment for a reservation not priced in GBP, test that scenario separately. When no rate is available or the drawer is inactive, the error message should tell the user how to resolve the issue.

Before enabling a new currency, run end-to-end tests: create a GBP-priced reservation, take a GBP payment for a TRY-priced reservation, process partial and excess payments with change, void, refund by cash and card, check out, close the shift and review the revenue report. The same records should appear with the same transaction IDs in the folio, cashier, bank and accounting export. Test missing rates and unauthorised manual rate attempts as well as successful scenarios.

  • GBP code, symbol, decimals and rate types were configured together.
  • Cash drawer, card account, report and receipt fields were enabled.
  • Partial payment, excess payment, refund and check-out scenarios were tested.
  • Missing-rate and unauthorised-transaction error flows were verified.

Perform a four-way reconciliation at shift close

Do not close a foreign-currency shift by checking only the total TRY balance. First compare PMS payment totals by currency and method. Second, count physical cash. Third, review POS and bank reports. Fourth, reconcile the property-currency equivalents in folio and accounting accounts. Oracle notes that cashiers can have starting amounts in multiple currencies and that payment and charge details are available in cashier-closure reports.

For every currency, show opening balance, receipts, outflows, change, refunds, expected close and counted close separately. If there is a difference, the user should not edit the total directly; require a reason, denomination count and approval. When POS totals are pending, close the shift as 'awaiting bank reconciliation' rather than completed. End-of-day reports must distinguish exchange differences, rounding differences and true cashier variances.

  • PMS, physical cash, POS/bank and accounting totals were compared.
  • Opening and closing amounts were counted separately for each currency.
  • Exchange, rounding and cashier differences were recorded with distinct reason codes.
  • Variance adjustments were logged with user, explanation and approval.
Short answers

FAQ

Must a hotel use the CBRT rate for every foreign-currency transaction?

Rates published by the CBRT are indicative and do not automatically determine the rate for every transaction between parties. The hotel should define the source, buying/selling direction, transaction type and effective time in a written policy and confirm the fiscal treatment with its accounting owner.

Can a guest pay in pounds for a room priced in euros?

Yes, if the PMS and property policy support it. Store the EUR rate, GBP payment and property-currency equivalent separately, and record the settlement rate, method and reference at payment time. Cashier, reporting, receipt and refund flows must also be configured for GBP.

Should a foreign-currency refund use the current exchange rate?

There is no single universal answer; the method depends on property policy, the payment provider and applicable fiscal rules. Preserve the original payment's currency, amount, rate and reference, and record the refund and any exchange difference as a separate offsetting movement.

Sources and updates

Operational recommendations should be adapted to the property's own conditions. Information about PMS and currency workflows was checked against the official documents below on 22 September 2026.