Expanding an MVNO into another country is rarely just a matter of adding a new currency symbol to the checkout page.
The difficult part starts behind the customer interface. An MVNO may sell plans in GBP, EUR, USD, or another local currency while paying an MNO, roaming partner, payment provider, or other supplier under completely different commercial terms. The billing system has to keep those transactions consistent without losing track of exchange rates, taxes, settlement amounts, refunds, and margins.
For an MVNO operating across markets, multi-currency billing is really a revenue-management problem, not just a formatting problem.
Why Multi-Currency Billing Is Difficult for MVNOs
A simple example shows the challenge.
Suppose an MVNO sells a monthly plan to a customer in Europe for €20. The same business may have wholesale network costs denominated in USD, while its payment processor settles funds in EUR and its corporate finance team reports consolidated results in GBP.
The billing platform therefore has to preserve several monetary perspectives at the same time. Converting everything into one currency too early can make customer billing easier, but it can make wholesale reconciliation, accounting and margin analysis much harder.
The system needs to know what currency was charged, what exchange rate was applied, when that rate was effective, and what the original transaction amount was.
That last point is particularly important. A converted amount should not replace the original monetary value. Both values should remain auditable.
Separate Customer Currency From Settlement Currency
One of the first design decisions should be to distinguish between customer billing currency and partner settlement currency.
A subscriber might always see and pay €20 for a plan. The underlying wholesale agreement could require settlement in USD. The MVNO shouldn’t simply overwrite the €20 with a converted dollar amount and lose the original commercial transaction.
Instead, the billing architecture should maintain something closer to:
Customer charge → Original currency → Exchange-rate source/date → Converted settlement value → Accounting/reporting currency
This makes reconciliation much easier when finance needs to explain why a transaction appearing on the customer invoice doesn’t match the amount appearing in a partner settlement report.
TM Forum’s current Billing Account Management specification includes billing-account configuration, payment plans, payment methods, account balances, taxes/fees and billing preferences. Its Bill Calculation component is responsible for calculating charges, credits, fees and taxes during or on demand from billing cycles. These capabilities provide useful building blocks for a billing architecture where currency is treated as part of the billing context rather than as a presentation-layer attribute.
Build Exchange-Rate Management Into the Billing Architecture
Exchange rates shouldn’t be buried inside application code.
An MVNO operating across several markets needs a controlled mechanism for defining which exchange rate applies to a transaction. Depending on the commercial agreement, that might be the rate at the time of charging, the invoice date, a predefined daily rate, or another agreed methodology.
The important thing is consistency.
If customer transactions use one rate while wholesale reconciliation uses another without a clearly defined rule, the MVNO can create artificial gains and losses that look like billing discrepancies.
For each conversion, the platform should retain information such as:
-
Original transaction amount
-
Original currency
-
Target currency
-
Exchange rate used
-
Rate effective date/time
-
Rate source
-
Converted amount
-
Rounding rule
-
Transaction or invoice reference
That audit trail becomes especially useful when a customer disputes a charge or finance investigates a difference between billing and settlement.
Don’t Mix Currency Conversion With Rating
This is another architectural mistake worth avoiding.
Rating determines what a service costs. Currency conversion determines how that amount is represented or settled in another currency.
Those are related but separate functions.
For example, a data plan might have a retail price of €15 per month and a usage-based roaming charge calculated according to a separate tariff. The rating engine should first determine the applicable charge according to the product and usage rules. Currency conversion can then be applied according to the defined commercial process.
Keeping those responsibilities separate makes pricing easier to maintain.
It also prevents an exchange-rate change from accidentally changing the underlying product tariff.
Roaming Makes Multi-Currency Billing Even More Complicated
International roaming is one of the clearest examples of why currency handling needs to be designed carefully.
When a subscriber roams, the visited network records usage and sends the relevant information to the home operator. GSMA explains that the home operator aggregates roaming charges and converts foreign-operator charges into the subscriber’s home currency for billing.
For an MVNO, that creates another reconciliation layer.
The operator may have:
Visited network → wholesale roaming charge → MVNO settlement currency → retail roaming tariff → subscriber currency
Each stage can involve different commercial rules.
GSMA’s billing and settlement work also includes standardized roaming interfaces for billing, invoicing and settlement, while the newer Billing and Charging Evolution (BCE) process is designed to support more flexible wholesale roaming settlement models and reconciliation.
This is particularly relevant as MVNOs expand into IoT and 5G-related roaming scenarios, where usage models can become more granular and wholesale relationships more complex.
Taxes and Local Pricing Need Their Own Layer
Currency isn’t the only market-specific variable.
An MVNO entering a new country may also need different tax treatment, invoice requirements, payment methods, pricing conventions and telecom fees. These shouldn’t be hard-coded into the currency conversion logic.
A better model treats the market as a configuration layer.
For example:
Market → Currency → Product catalog → Rating rules → Tax rules → Payment methods → Invoice format → Settlement rules
That architecture allows an MVNO to launch a new market without rebuilding the entire billing engine.
TelcoEdge’s current platform positioning follows this broader model, combining billing, payments, customer operations and multi-market capabilities. Its Edge Checkout offering specifically states support for multi-currency and multilingual experiences and describes global payment and tax automation for MVNO-oriented commerce.
Multi-Currency Billing Must Protect Margin, Not Just Revenue
A customer paying €20 doesn’t automatically mean the MVNO earns the equivalent of €20 in economic value.
Suppose wholesale connectivity costs increase in the MVNO’s settlement currency while the retail price remains fixed in the customer’s local currency. The exchange-rate movement can reduce the operator’s margin even though the customer’s invoice hasn’t changed.
This is where billing needs to connect with revenue assurance and margin intelligence.
The operator should be able to answer questions such as:
-
What did we charge the customer?
-
What did the network partner charge us?
-
Which exchange rate was used?
-
What was the actual converted cost?
-
What margin remained after wholesale cost, payment fees and taxes?
-
Which markets are becoming less profitable because of currency movements?
Without this visibility, an MVNO can grow subscribers while quietly losing margin in particular markets.
Amdocs’ Kenan platform, for example, includes capabilities for multinational, multi-currency enterprise billing, illustrating how currency support can sit within broader account and billing management rather than being treated as a standalone feature.
Keep the Original Transaction Data for Reconciliation
A common implementation mistake is storing only the final converted value.
That’s risky.
Imagine a customer was charged 100 EUR and the billing platform converted that transaction into USD. If the original EUR value disappears, finance may struggle to reproduce the calculation later when the exchange rate has changed.
The safer approach is to preserve the transaction in its original currency and record the conversion as a separate financial representation.
This becomes even more important for refunds, chargebacks and billing adjustments. A refund should reference the original transaction and the applicable currency rules rather than simply applying today’s exchange rate to yesterday’s charge.
Real-Time Billing Helps, But It Doesn’t Solve Currency Management Alone
Real-time billing can improve visibility into usage, balances and charges, but it doesn’t automatically solve multi-currency accounting.
The exchange-rate policy still needs to be defined.
The billing platform still needs an auditable currency model.
The finance team still needs reconciliation between retail transactions, payment settlement and wholesale costs.
TelcoEdge Inc positions real-time billing and automated reconciliation as part of its MVNO platform, with its current MVNO offering emphasizing real-time processing rather than overnight batch billing.
The important architectural point is that real-time charging and multi-currency financial control should work together without being treated as the same function.
A Practical Multi-Currency MVNO Architecture
For a growing MVNO, I’d structure the flow roughly like this:
Network usage → Mediation → Rating/Charging → Customer currency → Invoice/Payment → Settlement conversion → Wholesale reconciliation → Financial reporting
The currency service should be available to the relevant billing and settlement components, while the original transaction data remains immutable and auditable.
That gives the operator flexibility to support local retail pricing while maintaining centralized financial control.
It also makes market expansion less painful. Adding a new country should primarily mean configuring a new market, currency, tax model, payment setup and commercial rules—not creating another completely separate billing stack.
What MVNOs Should Check Before Expanding Into a New Currency
Before launching in a new market, the billing and finance teams should agree on several questions:
-
What currency will customers see and pay in?
-
What currency does the MNO or wholesale partner use?
-
Which exchange-rate source and methodology will be used?
-
At what point is the exchange rate locked?
-
How are refunds and chargebacks handled?
-
How are taxes calculated and displayed?
-
How are rounding differences handled?
-
What currency does finance use for consolidated reporting?
-
How will retail and wholesale records be reconciled?
-
Can every conversion be reproduced during an audit or dispute?
These questions are much more useful than simply asking whether a billing platform “supports multiple currencies.”
The real test is financial control
Multi-currency billing becomes difficult when an MVNO treats currencies as a UI feature.
It should instead be treated as part of the commercial architecture.
Customer currency, rating, exchange rates, taxes, payments, wholesale settlement and financial reporting all need clear boundaries and traceable relationships. That becomes increasingly important as an MVNO moves from one market into several and starts dealing with multiple MNOs, roaming partners and payment providers.
The goal isn’t just to let someone pay in euros instead of dollars.
The goal is to know exactly what that euro transaction means to the MVNO’s revenue, wholesale cost and margin.