Invoicing Clients Abroad: A Practical Currency, Tax and Address Playbook

The first time you invoice a client in another country, you discover that "send an invoice" is doing a lot of quiet work. A client in Berlin expects euros, a comma where you put a decimal point, and a tax line that reads like German tax lines read. A client in Toronto wants Canadian dollars and a postal code in a field actually labelled "Postal code," not "ZIP." A client in Tokyo would rather not squint at a document built entirely around your home country's assumptions.

None of this is hard. It is just a collection of small details that, left to chance, make you look amateurish — and that, handled deliberately, make you look like someone who has done this a hundred times. This article is the playbook: how to issue each invoice in the right currency, how to handle tax so the numbers add up the way the client expects, how to print the PDF in the client's own language, and how to get the address right for any of 199 countries. The mechanics below are how it works in InvoiceFlow, but the principles travel to any decent invoicing setup.

Currency: one invoice, one currency, no guessing

The cardinal rule of cross-border invoicing is that the invoice is denominated in one currency, and that currency is the client's, not yours — unless you have a specific reason to do otherwise (some contracts fix the billing currency as USD or EUR regardless of where the client sits; honor the contract). A German agency does not want to receive an invoice in dollars and do the conversion themselves. A US client does not want to puzzle over a total in pounds. Pick the currency once, per client, and stay consistent.

In InvoiceFlow, each invoice can be issued in its own currency, with correct formatting. That last part matters more than it sounds. "Correct formatting" means the currency symbol, its position relative to the number, the thousands separator and the decimal separator all match the convention for that currency. €1.234,56 and $1,234.56 are the same amount written two completely different ways, and getting it wrong is the kind of small tell that makes a finance department raise an eyebrow.

You can also set a default currency per client in their client settings, so the next invoice for that client opens in the right currency automatically. That single setting removes the most common cross-border mistake: sending a euro client an invoice in your home currency because that is what the app defaulted to.

What the app does — and what it doesn't

Here is the honest boundary, because it changes how you work. InvoiceFlow formats and tracks each invoice in its stated currency. It does not perform automatic live FX conversion. You decide the amounts and, where relevant, the exchange rate. The app is not quietly pulling a mid-market rate at send-time and converting your figures behind the scenes.

That is a feature, not a gap, and it reflects how cross-border billing actually works. If you quote a Munich client €2,000 for a project, you invoice €2,000 — full stop. There is no conversion to perform; that is the price in their currency. Your own bookkeeping back home, where you record what €2,000 landed as in your local currency on the day it cleared, is a separate exercise that happens after payment, at the rate your bank actually gave you. Conflating the two — invoicing in one currency but secretly thinking in another — is where freelancers tie themselves in knots.

So the workflow is clean:

• You agree a price in the client's currency. Either you quoted in it directly, or you converted your rate once, at quote time, and locked it.
• You invoice that exact figure. The app formats it correctly for that currency.
• You track the balance in that currency until it is paid, recording partial payments against it if they come in chunks.
• You reconcile to your home currency after the money arrives, using the real rate from your bank statement — not an estimate.

If you do want to show the client a courtesy conversion ("approximately $2,150 at today's rate"), put it in the invoice notes as a line of text, clearly marked as indicative. The billed amount stays in the client's currency.

Tax: inclusive, exclusive, multiple rates, and net-of-tax

Tax is where cross-border invoices most often go quietly wrong, because countries do not agree on the basics — not the rate, not the name, and crucially not whether prices are normally shown with tax baked in or without.

Inclusive vs exclusive — pick the one the client expects

InvoiceFlow supports both tax-inclusive and tax-exclusive pricing, and the choice is not cosmetic — it changes which number the client reads as "the price."

• Tax-exclusive: line items show the pre-tax price, tax is added as a separate line, and the total is the sum. This is the norm for B2B work in much of the world — businesses think in net figures because they reclaim the tax anyway.
• Tax-inclusive: the price shown already contains the tax, and the invoice breaks out how much of that price was tax. This is common for consumer-facing pricing in many countries, where the law or the custom is that the sticker price is what the customer pays.

Get this right per market. A B2B German client reading a tax-exclusive invoice with a clearly separated VAT line is seeing exactly what they expect. The same client receiving a tax-inclusive invoice may have to reverse-engineer your net figure for their own books — friction you created for no reason.

Multiple rates on one invoice

Real invoices are not always single-rate. You might bill a client for consulting (one rate) and a physical product (a different rate), or work that straddles a reduced rate and a standard rate. InvoiceFlow handles multiple tax rates on a single invoice, applying the correct rate per line and summarizing the tax by rate. The client sees a clean breakdown instead of a single blended number they cannot verify.

Net-of-tax and amount due

Underneath all of this, the app computes the net-of-tax figures and the amount due correctly, so the totals reconcile no matter which combination of inclusive, exclusive and multi-rate you have used. If a payment comes in partially, the amount due updates against the balance. You are not doing this arithmetic by hand at 11pm, which is exactly when arithmetic errors creep onto invoices.

One practical note on cross-border tax that no app can decide for you: whether you charge tax at all on a foreign sale is a legal question, not an app setting. Reverse-charge rules, zero-rating for exports, place-of-supply tests — these depend on your jurisdiction, the client's, and what you are selling. The app will faithfully show whatever tax treatment you tell it to. Knowing the right treatment is your job (or your accountant's). Decide the rule first; configure the invoice second.

Per-invoice locale: print in the client's language

Here is the detail that quietly impresses people. Your app can be running in English while the invoice you hand a client prints in German, or French, or Japanese.

InvoiceFlow supports a per-invoice locale: you set the language for a specific invoice, and the generated PDF — labels like "Invoice," "Due date," "Subtotal," "Tax," "Total," the date format, and so on — renders in that language, regardless of the language your app is set to. You work in your comfortable interface; the client receives a document that reads as though it were made for them.

This pairs with the app's PDF rendering, which handles non-Latin scripts correctly — Cyrillic, Arabic, CJK — using bundled NotoSans fonts plus user-selectable fonts. A document destined for a client in Tokyo or Riyadh will not come out as a row of empty boxes where the script should be. If you have ever received a PDF with garbled characters, you know how instantly it erodes trust; getting this right is a small thing that signals competence.

The practical move: set each foreign client's preferred invoice locale once. From then on, their invoices come out in their language automatically while you never leave your own interface.

Addresses: 199 countries, and the fields actually fit

The unglamorous truth of international invoicing is that addresses are wildly inconsistent across countries, and a single rigid address form makes every foreign address look slightly wrong.

InvoiceFlow's address fields are country-aware across 199 countries. Two things happen when you choose the client's country:

• The region and postal labels adapt. What is a "ZIP code" in the US is a "Postal code" in Canada, a "Postcode" in the UK, and a "PIN code" in India. The field is labelled the way that country labels it, so the address reads naturally to the recipient and to their accounts team.
• Some countries hide region and postal entirely. A number of countries do not use a state/region line or a postal code the way others do. Forcing an empty "State" field onto an address from one of those countries just looks like you don't know the country. The form drops the fields that don't apply.

The payoff is an address block on the PDF that looks like it was written by someone local — correct field names, correct fields present, nothing forced. It is invisible when it is right and conspicuous when it is wrong, which is precisely why it is worth getting right.

Putting it together: a worked playbook

Imagine you are a freelance designer with three overseas clients: an agency in Munich (pays in euros, B2B, expects tax-exclusive with a clear VAT line, wants the invoice in German), a startup in Toronto (Canadian dollars, English, postal code), and a studio in Tokyo (Japanese yen, Japanese-language invoice). Here is the one-time setup and the recurring workflow.

1. Set each client up once. For each, set the default currency, the preferred invoice locale, and the country (which fixes the address labels). Munich: EUR, German, Germany. Toronto: CAD, English, Canada. Tokyo: JPY, Japanese, Japan.
2. Decide the tax treatment per client with your accountant, then configure it. The Munich invoice is tax-exclusive with a VAT line; the others according to your rules for those sales.
3. Create the invoice. It opens in the right currency. You enter line items in that currency — the figures you actually agreed, not converted on the fly.
4. Let the app do the totals. Net-of-tax, tax by rate, and amount due all compute correctly.
5. Generate the PDF. It prints in the client's language, formats the currency correctly, and renders the address with the right labels — even if the client's language is in a non-Latin script.
6. Track and reconcile. You follow the balance in the invoice's currency; once paid, you record the real home-currency figure from your bank in your own books.

Three clients, three currencies, three languages — and from your side it is the same handful of taps each time, because the per-client settings carry the differences for you.

The small details that compound

Cross-border invoicing rewards precision in a way domestic invoicing does not. At home, a slightly-off address label or an unfamiliar tax presentation passes unnoticed because everyone shares the same assumptions. Across borders, every mismatch is a tiny signal that you are improvising. The freelancer whose euro invoices arrive in euros, in German, with a VAT line laid out the way German invoices lay it out, and an address block that reads correctly, gets treated as a professional vendor. The one whose invoices need translating, converting and re-formatting before the AP team can process them becomes "the foreign supplier who is a bit of a hassle."

You only have to set this up once per client. After that, the difference between looking like a local and looking like a tourist is built into every invoice you send — and it costs you nothing but the ten minutes it takes to fill in the client's currency, language and country correctly the first time.