Skip to main content
Bill each customer in their own currency, with prices you set per currency and FX rates you control for reporting.

​
How Multi-Currency Works

A customer has one billing currency. Everything they see — subscription pricing, invoices, credit balances, the customer portal — is denominated in it.
1

Set the customer's currency

Every customer carries a currency. It is required when the customer is created and it determines the currency of their subscriptions and invoices.
2

Price in that currency

Give each product a price in every currency you sell in, or let a price book convert from your base currency at a rate you set.
3

Maintain FX rates for reporting

Rates you enter drive the conversion used in revenue recognition, so recognized revenue is comparable across entities.
A subscription’s currency is fixed once it is created. To move a customer to a different currency, end the existing subscription and start a new one.

​
Setting a Customer’s Currency

  1. Navigate to Customers → [Customer]
  2. Edit the customer profile
  3. Set Currency to their billing currency
  4. Save
Every invoice for that customer is then issued in that currency. See Currencies for the supported list. Through the API, currency is a required field on POST /customers.

​
Multi-Currency Pricing

​
Explicit prices per currency

The recommended approach: set the price you actually want to charge in each market, rather than deriving it from a rate. Configure these on the product’s prices, or on a plan.

​
Price books with a conversion rate

A price book can carry a currency with an exchange rate, deriving prices from your base currency instead of listing each one. This keeps a large catalogue in step, at the cost of prices that land on awkward numbers.
Use explicit prices for your headline plans, where the price point matters, and a converted price book for a long tail of products where it does not.

​
FX Rates

FX rates are maintained per legal entity, with a source currency, a target currency, a rate and a validity period. They are used to convert amounts for revenue reporting, so figures from entities billing in different currencies can be compared. To manage them, go to Settings → Billing → FX Rates. Each rate covers a date range, so historical periods keep the rate that was in force at the time rather than being restated at today’s rate.
FX rates affect reporting and revenue recognition. They do not change what a customer is charged: the customer is billed the price set in their own currency.

​
Invoicing

An invoice is issued entirely in the customer’s currency, including tax. Payment is collected in the same currency. What your payment provider does with it afterwards, including any conversion into your bank account’s currency, is handled by the provider rather than by Alguna.

​
Revenue Recognition

Revenue schedules are produced in the currency the subscription bills in, and converted using the FX rate in force for the period. See Recognition.

​
Customer Portal

Customers see everything in their own currency:

​
Common Scenarios

​
European Expansion

  1. Confirm EUR and GBP are enabled for your organization
  2. Set EUR and GBP prices on the products you sell there
  3. Add FX rates for the legal entity that bills them
  4. Configure EU tax treatment. See Tax

​
Regional Pricing

Price for local purchasing power rather than converting a single list price:

​
Best Practices

Set explicit prices

A price you chose beats a price a rate produced, especially at your headline price points.

Keep FX rates current

Rates drive reported revenue. A stale rate quietly distorts every comparison built on it.

Decide the currency up front

A subscription’s currency cannot be changed after it is created.

Offer local payment methods

Local methods convert better than a card form in a foreign currency.

​
Next Steps

Currency Setup

The supported currency list.

Revenue Recognition

How FX rates feed recognized revenue.