Foreign-currency tenders: rates, change, and what adjustment really does

Tenders & currency · 8 min read

A store near the border takes US dollars every day. The customer is happy, the cashier is quick — and at month-end the office has three questions nobody can answer cleanly: which exchange rate did those sales actually use, why do the safe balances not agree with each other, and did the exchange-rate adjustment just change last month's retail numbers? Each question has a precise answer, and they are not the answers most setups assume.

General information only, not professional accounting or tax advice. Currency and gain/loss account setup affects your financial statements — confirm it with your accountant or Business Central partner.

The setup: currency first, tender second

Two pieces of setup meet at the till. In Business Central, the Currencies page is where a currency exists at all: it holds the exchange rates for the currencies in use, and it is where the Adjust Exchange Rates and Update Exchange Rates actions live. A currency with no current rate in that table has nothing for the POS to convert with, so rate maintenance is retail setup, not just finance setup.

In LS Central, the cashier selects the tender through the POS tender key: the TENDER_K command takes a Tender Type Code from the Tender Type table and defines the tender type used in the transaction. For a currency payment, the documented pattern is the currency tender type (parameter 6 in the standard command examples) with the CURR_K post command carrying the currency code — CAD in the example, or whichever currency is intended. The tender type card also decides where the money posts: its Account Type specifies whether payment by that tender posts to a G/L Account or a Bank Account, and its Difference G/L Account is where the difference between the Counted Amount and the Trans. Amount on a statement line is posted. Set those deliberately for a foreign-currency tender; do not inherit them from the cash tender by habit.

At the till: what the customer sees, what the slip records

The documented flow for a store whose own currency is not a float currency is simple, and two details in it surprise people:

• Payment can be exact or over. The customer can pay the exact amount in foreign currency, or hand over more than the price.
• Change comes back in local currency. If the payment exceeds the item's price, the return is made in the local currency — the float — not in the foreign currency the customer paid with.
• The slip shows both amounts and the rate. The amount is shown on the slip in the local currency and in the foreign currency, with the exchange rate used. The worked example in the LS Central documentation shows a payment of US 57.80 dollars at a rate of 0.649, with the change given in local currency. That printed rate is the answer to the month-end question “which rate did the sale use” — the rate in effect for the transaction, captured on the slip, not a rate someone looks up later.

For a Canadian store, read that example with the currencies swapped: the company currency is CAD, the tender is USD, the rate on the slip is the CAD conversion rate in effect at the sale, and the customer walks away with Canadian change. The store keeps the US notes — which is where the next problem starts.

After the sale: declaration, safe, and two balances that differ

After a foreign-currency sale, a tender declaration is made and posted, and the foreign currency is put in a bank, a safe bag, or both. Only tender types marked Counting Required can be entered in a tender declaration, so the foreign-currency tender needs that flag if the store counts it at close — most should.

On the Store Safe card, the effect is visible immediately: after a sale and tender declaration with foreign currency, the Balance (the total balance) and the Balance LCY (the balance in local currency) are not the same amount. That is not an error. One figure is the face amount of what is physically in the safe; the other is what it is worth in the company currency at the recorded rates. The Ledger Entries action on the Store Safe card (Related > Safe > Ledger Entries) shows the day's foreign-currency sales in detail, and foreign-currency bags can be joined, split, and broken like any other bag type as the money moves toward the bank.

The statement then does its normal work: the declaration feeds the statement lines, and before posting, the Difference Amount should be 0.00 on every line and the Counted Amount should equal the Trans. Amount — for the foreign tender line as much as for cash. How that close-out fits the wider day is covered in our end-of-day routine.

When rates move: Adjust Exchange Rates and its limits

Exchange rates fluctuate constantly, so amounts converted from foreign currencies and posted to the general ledger in local currency can become incorrect, and daily entries posted before a daily rate was entered need updating too. Business Central's answer is the Adjust Exchange Rates batch job — and its scope is narrower than its name suggests:

The practical consequence for border stores: the exchange difference on USD tenders is realized through the banking and posting path — what was recorded in LCY when the tender posted, against what the bank credits when the US cash is deposited — not through a period-end job sweeping the safe. If the office expects Adjust Exchange Rates to “true up” the foreign-currency tender account, it will wait forever; the job's documented scope is customer, vendor, and bank entries. The conversion itself follows the rate-table formula: Currency Amount = Amount / Adjustment Exch. Rate Amount × Relational Adjmt Exch. Rate Amt — which is why keeping the rate table current before the trading day matters more than any month-end cleanup.

A checking procedure for foreign-tender days

1. Before trading: confirm the day's rate for the tender currency exists on the Currencies page. A missing or stale rate means every slip that day carries the wrong conversion.
2. At close: run the tender declaration with the foreign-currency tender counted (it must be Counting Required), and post the declaration.
3. On the statement: verify the foreign tender line shows Difference Amount 0.00 and Counted Amount equal to Trans. Amount before posting.
4. In the safe: open the Store Safe card and confirm Balance and Balance LCY differ by roughly the expected conversion — then drill into Ledger Entries and agree the detail to the day's foreign-currency sales.
5. At banking: when the foreign cash goes to the bank, compare the bank's CAD credit with the LCY amount recorded at posting. Any gap is the realized exchange difference — it belongs in the open, in the gain/loss accounts set up for the currency, not absorbed silently into a tender difference.

What success looks like

Take any foreign-currency sale from the week. The slip shows the foreign amount, the local amount, and the rate used. The declaration and statement for that day show the foreign tender line with zero difference. The safe's ledger entries show the amount arriving, and its Balance LCY agrees with the sum of the LCY amounts recorded at the till. Nothing in that chain required a month-end job to fix it — because the rate was right on the day, the declaration counted the tender, and the banking difference was posted as what it is.

FAQ

Does the customer get change in US dollars if they paid in US dollars?
No — in the documented flow, when the payment exceeds the price, the change is given in the local currency (the float). The slip still shows the payment in both currencies with the rate used.

The safe Balance and Balance LCY do not match. Is something broken?
After a foreign-currency sale and declaration, those two figures are expected to differ: one is the face amount held, the other is its local-currency value. Use the safe's Ledger Entries to see the detail behind both.

Will running Adjust Exchange Rates fix a month of wrong-rate tenders?
The batch job adjusts posted customer, vendor, and bank account entries and can update reporting-currency amounts on G/L entries. It is not a tool for rewriting retail tender history. Wrong-rate days are corrected through the tender and banking records, with the difference posted explicitly — see fixing retail mistakes with journals for how to choose the correction route.