Customer Statements in YER, SAR, and USD: What Should They Show?

Why do customer statements become harder with several currencies?

A good statement answers a simple question: how did the customer's balance move from the beginning of the period to the end? With YER, SAR, and USD, one number is no longer enough, because every amount has its own unit and record. Adding one hundred of one currency to one hundred of another does not produce a meaningful balance, however neatly the total is presented.

The practical principle is a separate path for each currency: an opening balance, transactions, payments, adjustments, and a closing balance. A conversion or cross-currency settlement should be a documented event linking the two amounts, rather than a silent change to historical figures. This article provides no exchange rate or financial recommendation. Its purpose is to organize the information a shop owner and customer need to review the same records.

Define the statement's purpose and period first

Before generating a file, decide whether it is for a periodic review, a payment request, reconciliation of a discrepancy, or a period close. The purpose affects the detail, but not the basic rules. Show clear start and end dates, establish whether transactions on the final day are included, and state the issue time if transactions continue throughout that day.

Do not send a statement headed “up to today” without an explicit date. A customer may make a payment minutes later and think the report is wrong. Prefer wording such as “Period: August 1 to August 15; issued at the stated time,” explaining that later transactions are excluded.

Header information that prevents confusion

The header needs enough information to identify the account without exposing unnecessary data. Check for:

• The issuing business or organization's name.
• The customer's name and account number or code, where available.
• The covered period and issue time.
• The account type or relationship description, if needed.
• Currencies with activity or a balance during the period.
• A contact method for queries, if business policy permits.
• A statement reference or version identifier when it is sent repeatedly.

Do not rely on a name alone when several customers have similar names. Equally, avoid full phone numbers, addresses, or extra details in a copy that may be shared more widely than intended. Include what identification and review actually require.

Separate each currency visually and mathematically

The clearest structure is a separate section for each currency, or columns that cannot mix their amounts. For example, show YER first, then SAR, then USD. Each section begins with an opening balance in that currency alone, lists transactions chronologically, and ends with a closing balance in the same currency.

A currency with no activity and no balance does not need an empty section unless reconciliation requires it. If there is a summary at the top, write “YER balance: …; SAR balance: …; USD balance: …” rather than “Total: …”. Placing the currency code beside every amount reduces reading mistakes, especially in a small phone image.

An opening balance needs a date and a source

An opening balance is not a number inserted to make the equation work. It is the accepted balance before the first transaction in the period and should have a date and source: a reconciled previous statement, a documented migration record, or a review approved by the responsible person. Each currency has its own opening balance. One may be zero while another has an outstanding amount.

If an opening balance is disputed, do not conceal that within the statement. Add a clear note such as “Opening balance awaiting reconciliation” and identify who will review it. Changing an opening balance without recording why may leave subsequent arithmetic correct but built on an unreliable starting point.

What fields does each transaction need?

A reviewable entry contains enough information to return to its source. The report need not be cluttered, but should include:

• The date, and time when needed to distinguish same-day transactions.
• The transaction type: credit sale, payment, return, approved discount, or documented adjustment.
• A reference, such as an invoice number, receipt number, or internal identifier.
• A short description understood by both customer and reviewer.
• The amount increasing or decreasing the balance.
• The currency code beside the amount.
• The running balance after the entry, in that same currency.
• The entry's status if it is pending or canceled under the system's procedure.

Use consistent signs and terminology. You can use columns for amounts owed by and owed to the customer, or for increases and payments, but their meaning must not change from row to row. Include a short explanation for readers without accounting experience.

The closing balance is more than the last number

It must be possible to recalculate the closing balance from the opening balance and transactions. In its simplest form: opening balance plus entries increasing the shop's receivable, minus payments, returns, and approved reductions, equals the closing balance. Apply that equation within each currency, never across currencies.

Add the transaction count or totals for increases and reductions to each section. These help reveal a missing row but do not replace the detail. If the balance favors the customer rather than the shop, state that in words instead of relying on a negative sign that might be interpreted differently.

What if payment is made in another currency?

A customer may pay in one currency while the debt is recorded in another. Do not treat this as an ordinary payment in the original currency without a corresponding record. Document the amount actually received, the amount settled in the debt currency, the transaction date, and the reference agreed by both parties. If a conversion rate is used, record it as part of that dated transaction without converting the entire historical ledger.

The event can be represented by two linked entries: a receipt in one currency record and a settlement in the other, sharing one reference. Their relationship must reconcile under the business's approved procedure. Do not delete the original debt and recreate it in another currency; that breaks the history and makes earlier statements harder to explain.

A complete example in three currencies

Suppose Al Salam Store starts the period owing 120000 YER and 450 SAR, with no USD balance. The following transactions occur:

• A credit sale of 35000 YER brings the YER balance to 155000.
• A payment of 50000 YER reduces the YER balance to 105000.
• A credit sale of 120 SAR brings the SAR balance to 570.
• A payment of 200 SAR reduces the SAR balance to 370.
• A credit sale of 80 USD brings the USD balance to 80.
• A payment of 30 USD reduces the USD balance to 50.

The correct closing summary is 105000 YER, 370 SAR, and 50 USD, stating who owes each balance. There is no single total for these figures. If the owner wants an internal estimate in a reference currency, it should be a separate report stating its valuation basis and date, rather than replacing the original customer statement.

How to check the example before sending it

Start with YER alone: 120000 plus 35000 minus 50000 equals 105000. Then SAR: 450 plus 120 minus 200 equals 370. Finally USD: zero plus 80 minus 30 equals 50. After checking the arithmetic, match each transaction to its reference and confirm that no payment was entered twice or sale recorded in the wrong currency.

Handling returns, discounts, and corrections

A return reduces the amount due in the original sale currency unless a different treatment is documented. Show it as a separate entry referencing the invoice or transaction. A discount needs approval and a reason, rather than a direct balance edit. Correct an incorrect currency or amount through a clear adjustment or a system procedure that preserves the change's effect.

If a statement has already been issued before a correction, create a new version with a new issue date and explain that it replaces the previous one. Do not send two identically named files in the same conversation. Use a reference or date that tells the customer which version to rely on.

Sharing through PDF or messaging applications

Review the file before sharing, confirm the recipient, and include no more information than reconciliation requires. Choose a clear filename containing the customer code and period without unnecessary sensitive details. Send a brief note explaining the currencies and period, and ask the customer to identify a transaction reference when querying the statement instead of debating the balance as a single block.

A messaging application should not be treated as the official account archive. Retain the approved version and its sending reference under your internal procedure, and record the customer's response or correction request. On a shared phone, review notifications, automatic downloads, and file folders before sharing statements.

Multicurrency statement review checklist

• The customer name or code is correct and unambiguous.
• The period start, period end, and issue time are visible.
• YER, SAR, and USD have separate sections whenever they have a balance or activity.
• Each opening balance has a source and date.
• Every entry shows its type, reference, description, and currency.
• Running balances recalculate within their own currency.
• No total combines currencies without a stated basis.
• Every cross-currency settlement records both amounts and a shared reference.
• Returns, discounts, and corrections appear as transactions.
• Closing balances state the amount, currency, and who owes whom.
• The file is readable on a phone and in print.
• The recipient, sharing channel, and version have been checked.

Common mistakes

• Putting the currency only in the heading, then showing pages of bare numbers.
• Revaluing all historical transactions when the conversion basis changes.
• Using one opening balance for three currencies.
• Deleting a cross-currency settlement instead of linking both sides.
• Showing a negative balance without saying who is owed the money.
• Sending an undated statement while new transactions continue.
• Changing a previously sent statement without issuing a new version.
• Assuming a PDF is correct because its design is tidy.

Frequently asked questions

Can all three currencies appear in one table?

Yes, if the columns are clear and cannot mix the amounts. Separate sections are often easier to review on a phone. What matters is maintaining a separate running balance for each currency and avoiding a misleading combined total.

Should I convert the whole balance into one currency for the customer?

Not as a replacement for the original record. A separate estimate can be prepared when needed, stating its basis and date. The customer statement should retain the amounts in the currencies in which the transactions arose.

What should I do if the customer pays in another currency?

Document the amount received, the amount settled, the date, and the reference, and link the two entries. Do not use an undocumented rate or change historical entries to make them appear to have occurred in the new currency.

Is a screenshot enough?

It can help in a quick exchange, but may crop out the period, reference, or currency. An organized statement that can be saved and reviewed is better for reconciliation, with appropriate care for the recipient's privacy and the information shown.

Conclusion

A sound multicurrency statement does not try to compress YER, SAR, and USD into one number. It identifies the customer and period, separates opening balances, transactions, and closing balances by currency, documents cross-currency settlements, and preserves references and corrections. Before sending, recalculate it, open the file on another device, and make sure the reader can understand every balance, who owes it, and why it changed.