What changes for you
A customer in another country sees your prices, their totals and their invoices in a currency they actually use, and the prices are the ones you set for that currency.
The moment usually comes without warning. Your product was built for one market, so every price, every total and every invoice carries the same currency sign. Then a promising customer abroad asks a simple question: can we pay in our own money? Their finance team does not want to convert your figures by hand. Their purchasing department may need an invoice in their currency before it will approve anything. Suddenly a detail nobody planned for stands between you and a signature.
The workarounds are familiar. Someone quotes a price in an email and hopes the figure on the invoice matches. A one-off invoice is made outside the product. The customer is told to accept your currency and absorb the difference. Each of these works once and wears thin by the third customer, and none of them looks like a product that was made with that customer in mind.
With this work done, the currency becomes part of the product. A customer abroad meets your prices in their currency, the totals they agree to are in that currency, and the invoice that follows says the same thing. The work lands in your own code repository. The code we build for you is yours.
This is about money, not language. If your next market also reads a different language, adding a second language is its own piece of work, and it fits alongside this one. If customers cannot yet pay inside your product at all, adding subscriptions so you can start charging comes first.
What you decide
You decide which currencies your product offers. One extra currency for one important customer is a perfectly good start.
You decide the price in each currency. A price that reads well to a buyer in one country may look odd when copied across from another, and how you price for a market is a commercial choice that belongs with you.
You decide who sees which currency. Some companies let the customer choose, others tie the currency to the customer’s account or contract. That rule is yours to set.
You decide what happens to the customers you already have, and what they are told.
You decide when it goes live. You decide what ships. Nothing reaches your users without your approval.
What you see along the way
The work reaches your repository as small changes, and each one says in plain words what it changes for your prices or invoices.
Questions that only you can answer come to you instead of being guessed at: which currency a returning customer sees, how a price is labelled, what an invoice should say when the customer and your company sit in different countries. Where a question touches tax or accounting, you are asked to bring in your own adviser, because that judgement is not ours to make.
What it costs you in time
A first conversation about which customers and which currencies matter, then short decisions as they come up. The decision that deserves the most care is the price list itself, and it may be worth an hour with whoever owns pricing and whoever looks after invoices on your side.
What if you want to stop
Whatever is finished is already in your repository, and nothing you have not approved is in front of your customers. Your code and your product stay yours to take anywhere.
Starting small
We have not published a delivered example of adding a currency, so we will not hint at one. A sensible first piece is one extra currency for the customer who asked: one product, one price you set, a total and an invoice they can read in their own money. Every engagement is tailored to your product and your goals. It starts with a conversation, with no obligation.
