Multi-Currency Settlement

Multi-Currency Settlement

Definition

Multi-Currency Settlement is the core capability of ICMP cross-border billing and payment, supporting billing in local currency, unified settlement currency (Base Currency), and multi-currency collection. Combined with FX Management for exchange rate management, it reduces exchange rate risks and cross-border payment costs, meeting the settlement needs of global customers.

Core Capabilities

Multi-Currency Settlement includes: Multi-Currency Billing——Operator invoices may be billed in local currency, and the platform supports USD, EUR, CNY, GBP, etc.; Unified Settlement——Multiple country charges are converted to Base Currency according to FX Management exchange rates, generating Unified Invoice; Multi-Currency Collection——Customers can pay in local currency through Payment Gateway or LPM; Exchange Rate Lock——FX Lock secures the exchange rate to avoid fluctuations.

Cross-Border Process

Typical process: The platform obtains invoices billed in local currency from multiple operators; converts them to Base Currency through FX Management at agreed exchange rates; consolidates and generates Unified Invoice to send to customers; customers pay through Payment Gateway in agreed or local currency; the platform performs Reconciliation with operators for account reconciliation and settlement. Each step must accurately record currency, exchange rate, and conversion results to meet Audit Trail requirements.

Practice in ICMP

SimtoLink ICMP's Multi-Currency Settlement supports multiple currencies, FX Management, Unified Invoice; deeply integrates with Cross-Border Billing, Payment Gateway; supports LPM local payments; meets Audit Trail and financial compliance requirements.

Where Each of the Three Currencies Appears

Multi-currency settlement has to keep three currency roles at once. The charging currency is the currency the operator or the rate card uses to price usage. It often changes with the country or the contract. The settlement currency is the currency the platform and the customer have agreed for summarizing the invoice. Many local charges in a month fold into that one book. The payment currency is the currency the customer actually pays, and it may differ again from the invoice currency. Technically, every amount must store the original currency, the converted currency, the rate used, the rate timestamp, and the amount after conversion. If any of the five is missing, the difference cannot be explained later.

Enable it when the rate source, the rounding rule, and who bears the exchange difference are already written into the contract. Price the CDR first in the charging currency, then convert to the settlement currency at the agreed close. Do not reprice the whole month at that day’s rate every time a late CDR arrives. If the payment stage allows the customer to pay in a local currency, the amount paid must be traceable back to the settlement amount on the invoice and to the channel fee. Do not mix the usage unit on the CDR with the monetary amount in one field. Traffic still accumulates in bytes or in the agreed unit. Currency appears only on the priced result.

Book Differences from the Wrong Rate Timestamp

The easiest mistake is to rewrite an invoice already issued with the rate on the day of payment. After the invoice goes out, a rate movement belongs in foreign-exchange gain or loss, or on the next adjustment, not in a change to the original invoice. Another mistake is to keep only the converted figure and overwrite the original-currency amount. Reconciliation with the operator then cannot produce the currency on the other party’s bill. If rounding is done per CDR while the contract says to round a daily total, cent-level differences accumulate into a visible amount on a large-usage customer.

A further bias is to convert tax-inclusive and tax-exclusive amounts back and forth through the same rate field, so the tax is converted twice. Each multi-currency record should fix the tuple of amount type, currency, rate, and timestamp. After close, only an additional adjustment is allowed. The original value is not overwritten. The invoice the customer sees, the payment the bank receives, and the bill the operator sends can then be matched segment by segment.

An adjustment should have its own number and point at the original invoice and the original rate. Do not quietly add the difference into the usage amount of the next invoice. When a customer pays in another currency, bank fees and the exchange difference should be listed on their own, so they are not mixed into one total with the connectivity charge. For a CDR that arrives only after close, whether to use the original close rate or the rate on the day of the late record must be fixed by the contract, and that CDR should state which timestamp was chosen.

Decimal places differ by currency. Some currencies are exact to a cent. Some have no decimals. Convert first in the smallest unit of the original currency, then round to the smallest unit of the settlement currency, and use the same rounding rule throughout. Turning an amount into a unitless decimal and multiplying the rate back and forth lets sub-cent remainders accumulate across a large number of CDRs. The rounding difference should be visible on its own. It should not be stuffed into one usage line and presented as a traffic charge.

A triangular conversion introduces a second rate. When the operator prices in a local currency and the contract requires a conversion into an intermediate currency and then into the settlement currency, both rates and both timestamps must be stored. Keeping only the last leg cannot explain why the result differs from a direct conversion. If the contract specifies a published rate from a given source on a given day, a late record must not switch to another source on the day the money arrives. If the source is unavailable, pause the close. Do not type in a rate that has no record.

When the payment currency and the settlement currency differ, the fee the bank deducts is not connectivity usage. It belongs in the collection difference, and it should point at the original invoice. An overpayment or an underpayment is handled by an adjustment or an open balance. Do not rewrite the converted amount already fixed on the invoice. What an audit then sees is an original value that is not overwritten, plus a later difference, not a total that keeps changing.

An amount shown to a customer should carry the currency name. A bare number does not say whether it is the local charging amount, the settlement amount, or the amount actually paid. When all three appear together, note the rate timestamp used for each, so a converted result is not read as the figure on the operator’s original bill.

Related Terms

Return to International IoT Cloud Platform Terminology