Invoice clients worldwide from Spain: 71 countries, 40 currencies, zero drama
How to invoice international clients from Spain without losing tax compliance. 71 countries, 40 currencies, per-currency decimal precision, no spreadsheets.
Key Takeaways
- Invoice clients in 71 countries and 40 currencies with automatic per-currency decimal precision (0, 2, or 3 decimals per ISO 4217)
- Your international clients and your Spanish tax compliance coexist in the same system -- no need for two tools
- PDFs, dashboard, AI chat, and Stripe all adapt automatically to each client's currency
A freelancer in Madrid with clients in San Francisco, Berlin, and Tokyo has a problem that no Spanish ERP solves well: each client pays in their currency, but the Spanish tax authority wants the Modelo 303 in euros.
The usual solution is a parallel spreadsheet where amounts are converted manually, exchange rates copied from the ECB, and a prayer said over decimal precision. Because a yen has no cents. A Bahraini dinar has three decimal places. A euro has two. Getting the decimal precision wrong on a currency can turn a 1,000 invoice into a 100,000 one.
Frihet supports 71 countries and 40 currencies with native precision. Here is what it does and how it works.
71 countries, 40 currencies
Frihet covers four regions:
| Region | Countries | Main currencies |
|---|---|---|
| Europe | 31 | EUR, GBP, CHF, SEK, DKK, NOK, PLN, CZK, RON, HUF, ISK, TRY |
| Americas | 18 | USD, BRL, MXN, CAD, ARS, COP, CLP, PEN, UYU |
| Asia-Pacific | 13 | JPY, KRW, AUD, NZD, INR, SGD, HKD, THB, IDR, VND, TWD |
| Middle East & Africa | 8 | AED, SAR, ILS, ZAR, NGN, EGP, KES, MAD |
The selection is practical: countries where freelancers and SMEs might use a bilingual ERP (Spanish/English), with Stripe available or coming.
The decimal trap
Most ERPs that claim "multi-currency support" treat all currencies as if they had two decimal places. This is incorrect and dangerous.
The ISO 4217 standard defines three precision levels:
Zero decimals (17 currencies): JPY, KRW, VND, CLP, PYG, ISK and 11 more. 1,000 yen is 1,000 yen, not 10.00 yen.
Two decimals (most currencies): EUR, USD, GBP and the vast majority. 10 euros is 10.00 EUR.
Three decimals (7 currencies): BHD, KWD, OMR, JOD, IQD, LYD, TND. 1 Kuwaiti dinar is 1.000 KWD.
This matters especially with Stripe, which works internally in minor units. If software sends "1000" to Stripe to charge 1,000 yen, but Stripe interprets it as 10.00 yen (because the software assumed two decimals), the client pays 100 times less. With Frihet, the conversion is automatic and there is nothing to configure manually.
Frihet solves this with conversion functions applied across the entire system: PDFs, dashboard, Stripe, AI chat, lists. It is not possible to "choose" the wrong decimal precision because the system determines it from the selected currency.
International invoicing + Spanish compliance: no conflict
The real problem is not the currency itself. It is that Spanish ERPs (Holded, Quipu, Billin) are designed for invoicing in euros with VAT. And international ERPs (FreshBooks, Xero) do not understand the Modelo 303 or VeriFactu.
Frihet separates both worlds automatically based on the user's country:
If your country is Spain, the system shows:
- Modelo 303, 130, and 420 calculated in real time
- Tax calendar with deadline alerts
- Full VeriFactu compliance (hash chain, QR, sequential numbering)
- Tax profile (NIF, VAT regime, IAE code)
If your country is anything else, you see full invoicing -- clients, products, invoices, expenses, OCR, AI -- without the Spanish compliance layer.
Both profiles use the same engine. A freelancer in Spain invoicing a client in Japan issues the invoice in yen, but their Modelo 303 is still calculated in euros. A freelancer in Argentina simply does not see the Spanish tax menu.
What adapts automatically
When you set your country and currency in settings, the entire system adjusts:
Financial dashboard. KPIs display your currency. If your currency is Argentine pesos, totals show as "ARS 150,000", not "150,000.00 EUR".
Invoice PDFs. Number formatting and currency symbol adapt per currency. A PDF in yen shows amounts with no decimals. A PDF in Kuwaiti dinars shows three. No manual toggle.
AI chat. Responses and KPI cards are formatted in the user's currency. "How much did I invoice this quarter" returns the correct amount in the correct currency.
Lists and tables. All amount columns (invoices, expenses, products, clients) use the unified currency formatter.
Stripe Connect. Payment links respect the currency. Minor unit conversion is automatic.
Practical example
A developer in Barcelona with three clients:
- A startup in San Francisco paying in USD
- An agency in Berlin paying in EUR
- A company in Tokyo paying in JPY
The flow in Frihet:
- Sets their country to Spain and primary currency to EUR
- Creates invoices for each client in their respective currency
- PDFs format correctly per currency (2 decimals USD, 2 EUR, 0 JPY)
- Dashboard shows totals in EUR
- Modelo 303 calculates automatically on euro amounts
- VeriFactu applies to all invoices regardless of currency
No extra program. No conversion spreadsheet. No remembering that yen has no cents.
What it does not do (yet)
Three things Frihet does not yet solve in the multi-currency flow:
- Automatic exchange rates. Frihet does not query the ECB exchange rate to convert between currencies. The euro equivalent for the 303 is the user's or accountant's responsibility.
- Per-currency dashboard breakdown. Totals use the primary currency. There is no separate panel per currency.
- Per-currency balances. There is no balance per currency. It is on the roadmap.
These are real limitations. Promising features that do not exist is worse than being direct.
Who this is for
Spanish freelancer with international clients. Invoice in each client's currency without losing Spanish tax compliance.
SaaS founder charging via Stripe. Payments arrive in multiple currencies. Revenue Sync imports them as invoices respecting the original currency.
Digital nomad with a tax base in Spain. Pay taxes in Spain, work from anywhere. An ERP that understands both worlds.
Agency with international projects. Each project in a different currency. Each invoice formatted correctly.
Multi-currency invoicing is included in the free plan. A freelancer invoicing three countries should not pay extra for their software to know that yen has no cents.
Frequently Asked Questions
Can I invoice in dollars if I'm a freelancer in Spain?
Yes. You can issue invoices in any currency. Spanish tax obligations (VAT, income tax) are calculated on the euro equivalent at the exchange rate on the date of the transaction. Your ERP should record both amounts.
How does Frihet handle zero-decimal currencies like the Japanese yen?
Frihet uses per-currency decimal precision following ISO 4217. The yen (JPY) and Korean won (KRW) use 0 decimals. The Bahraini dinar (BHD) uses 3 decimals. The euro and dollar use 2. Everything is automatic -- there is no way to misconfigure it.
Do I need a different tool for invoicing in Spain and another for international clients?
No. Frihet automatically separates Spanish tax compliance (VeriFactu, Modelo 303, tax calendar) from international invoicing. If your country is Spain, you see everything. If you are an international user, you see invoicing without the Spanish compliance layer.
Does Stripe Connect work with international currencies?
Yes. When you generate a payment link with Stripe Connect in Frihet, the amount is converted to the correct minor units for that currency (cents for EUR, no decimals for JPY). The conversion is automatic.
