How to Invoice International Clients as a Developer

Your first invoice to a client in another country looks almost exactly like a domestic one, and that is the problem. The differences are small, boring, and expensive. To invoice international clients as a developer: bill in the currency the client's accounts-payable team already pays in (usually theirs, unless your costs are in yours), state the three-letter currency code next to every amount, add your tax ID and the client's, add a one-line explanation of why no VAT or sales tax is charged, give complete bank details for that specific corridor including who pays the transfer charges, and find out before you invoice whether the client's country requires them to withhold tax at source. Get those right and a cross-border invoice is no harder than a local one. Get them wrong and you spend three weeks emailing a finance department in a different timezone about a payment that arrived short.

Everything below is general information for freelance and contract developers, not tax or legal advice. Rules differ meaningfully by country, by the pair of countries involved, and by whether you trade as an individual or a company. For your specific situation, an accountant licensed where you live is the right call, and a cheap one.

What changes on an invoice when the client is abroad?

The structure does not change. Everything in what belongs on a software development invoice still applies: identity block, invoice number, dates, line items, totals, terms. What changes is the audience. A domestic invoice is read by one person who knows you. An international invoice is read by that person, then by an accounts-payable clerk who has never heard of you, then sometimes by a compliance system looking for reasons to hold the payment.

That audience needs nine things a domestic invoice can leave out.

#	Field	Why it matters abroad
1	Your country, written out in full	AP systems route and classify by country. "Dublin" without "Ireland" is ambiguous to a US clerk, and abbreviations are worse.
2	The client's full legal entity and its country	Not your contact's name. Multinationals pay from a specific registered entity, and the wrong one gets the invoice bounced back weeks later. Ask at kickoff.
3	Your tax identification number	VAT number, GST or ABN, EIN, PAN, whatever your jurisdiction issues. Many countries require the supplier's tax ID on an invoice before their buyer can deduct the cost.
4	The client's tax registration number	Needed whenever the transaction is treated as business-to-business under the buyer's VAT or GST rules. Request it in writing and keep the reply.
5	The three-letter currency code beside every amount	"$1,200" means four different things depending on who is reading. "USD 1,200" means one. Put the ISO code on the total at minimum, ideally on rates too.
6	A one-line tax-treatment statement	If you are not charging VAT, GST, or sales tax, say why. Something like "Reverse charge: VAT to be accounted for by the customer". A blank tax line reads as an omission and gets queried.
7	Complete bank details for that corridor	IBAN plus BIC or SWIFT for Europe. Account plus routing number for US ACH or wire. Local clearing codes elsewhere. The exact set that corridor uses, not a generic dump.
8	Your bank's name and full address	Wire forms ask for the beneficiary bank's address. If it is not on the invoice, someone emails you for it and the payment waits until you reply.
9	Who pays the transfer and intermediary charges	Wires carry a charge-bearer instruction (OUR, SHA, or BEN in SWIFT terms). Say it plainly: "All bank and intermediary transfer charges are payable by the client." Silence defaults to you paying, quietly.

Field 9 is the one developers skip and then re-learn. A wire passing through correspondent banks can be shaved at each hop, and nobody tells you it happened. You just see a total smaller than the invoice and cannot explain the difference.

Which currency should you invoice in?

There is a genuine decision here, and the honest answer is that it depends on where your costs sit and who is better at absorbing movement.

Invoice in the client's currency when you want to remove every excuse for delay. A finance team paying an invoice denominated in its own currency does not have to request an FX quote, does not have to get a second approval for a rate, and does not have to explain a variance to its own bookkeeping. This is the default for most freelance developers billing a larger company, and it is the reason so many contractors bill US clients in USD regardless of where they live.

Invoice in your own currency when your costs are in your own currency and the contract is long. If you pay rent, salaries, or subcontractors in EUR and you bill a twelve-month retainer in USD, you have taken on a currency position you did not ask for and are not being paid to hold. Billing in your own currency pushes that risk to the client, who is usually larger and better equipped to carry it. Expect to negotiate it.

Invoice in a third currency (usually USD) when neither side's currency is easy to move. For corridors where both local currencies are thinly traded or capital-controlled, USD is often the practical settlement currency, and both parties convert at their own end.

Two rules regardless of which you choose. Fix the currency in the contract, not on the invoice, so it is never a surprise. And if you bill in the client's currency but price in yours, put the exchange rate assumption in the contract with a re-pricing trigger for long engagements. That is the same discipline as the rest of your commercial terms, covered in hourly vs fixed price billing for developers.

How do you get paid without losing a chunk of it to fees?

Money leaves a cross-border payment in three separate places, and they are easy to confuse with each other.

The exchange-rate margin. The spread between the mid-market rate and the rate you are actually given. This is usually the largest cost and the least visible one, because it is not itemised anywhere. It is buried in the number of your-currency units you receive.

The explicit transfer fee. The flat or percentage charge the sending or receiving provider names on its pricing page. This is the smallest number and the one everyone compares, which is why providers compete on it and make their money on the margin instead.

Intermediary and lifting fees. On a traditional SWIFT wire, correspondent banks in the middle can each deduct a handling charge, and your receiving bank may add an inbound fee. These are the ones that make a payment arrive at an odd number nobody can reconstruct.

Published fee schedules move often enough that any specific percentage quoted in an article is stale within months. So compare on landed amount, not on advertised fee: send a small test payment on the corridor you will actually use, then compare what hits your account against the mid-market value of the invoice on the day it settled. That single number captures margin, fee, and intermediary deductions together, and it survives every pricing change.

A few structural moves that reduce all three costs, whatever provider you use:

Invoice less often for more. Fixed per-transfer costs hurt small invoices most. Monthly beats weekly on the same total.
Receive on local rails wherever you can. An account that gives you local receiving details in the client's country turns a wire into a domestic transfer at the client's end, which removes the intermediary layer entirely.
Do not accept card payment for large invoices. Card processing plus a cross-border assessment plus an FX conversion is the most expensive way to move a four-figure amount, and it also carries chargeback exposure you do not want on services already delivered.
Put the charge-bearer instruction on the invoice. Field 9 above. It is free and it works.

Fee mechanics are only half of getting paid. The other half is terms, deposits, and follow-up discipline, which matter more across borders because escalation is harder. Net terms, deposits, and late fees covers that side, and I would add one international-specific rule: take a deposit on the first engagement with any overseas client, without exception. It is the cheapest possible test of whether their payment process actually works before you have delivered anything.

What is withholding tax and why did the payment arrive short?

Withholding tax is tax the payer is legally required to deduct from your invoice and remit to their own government on your behalf. It is not a fee and it is not the client shortchanging you. It is the client obeying a law that says money leaving the country to a foreign supplier gets taxed at source.

The mechanism is easiest to see in the US rules, which are published clearly. The IRS states that most types of US-source income received by a foreign person are subject to US tax of 30%, collected by the payer, who then reports it on Forms 1042 and 1042-S. That rate can be reduced or eliminated by an income tax treaty between the US and your country of residence, but only if the paperwork exists before the payment is made.

The paperwork is a W-8 form. The IRS describes Form W-8BEN as the certificate a foreign individual gives to the withholding agent or payer to certify foreign status, including where the individual is claiming a reduced rate of or exemption from withholding. Individuals use W-8BEN; a foreign company uses the entity version. Fill it in when the client asks, or better, offer it with your first invoice so their AP team never has to chase you.

The second thing worth understanding is sourcing. US tax applies to nonresident individuals on income effectively connected with a US trade or business, or on US-source fixed or determinable annual or periodic income. Foreign-source income generally falls outside it, and for services the source usually follows where the work was physically performed. That is why a developer sitting in Lisbon writing code for a company in Austin is frequently in a different position than the same developer flying to Austin to do the work on site. This is exactly the kind of question where a local accountant earns their fee in one conversation, and where you should not act on a blog post, including this one.

The US is not the only country that does this. Several jurisdictions require their businesses to withhold on payments to foreign service providers, sometimes at rates that make the engagement uneconomic unless a treaty applies. So ask one question at contract stage: "Will you be withholding any tax at source on our invoices, and if so, at what rate and under which treaty?" Ask before you agree the rate, not after the first payment lands light.

What records should you keep for cross-border income?

More than you would domestically, and for longer. The minimum set:

The invoice itself, in the currency invoiced, with its number from your invoice numbering system unbroken across domestic and international clients. One sequence, not two.
The settlement record, showing the amount actually received, the date it settled, and the rate applied. This explains any gap between the invoice and your bank balance.
The contract, because it establishes the currency, the terms, and where the services were performed.
Any tax certificates. A W-8BEN you submitted, a withholding certificate the client issued, a treaty residency certificate your own tax authority gave you. Withholding you cannot document is withholding you probably cannot credit against your own tax bill.
Your conversion basis. The IRS notes that it has no official exchange rate and that in general you use the rate prevailing when you receive, pay, or accrue the item, publishing yearly average currency exchange rates as a reference. Other tax authorities have their own conventions. Whichever your jurisdiction expects, apply it consistently and write down which one you used.

On the VAT and GST side, the general rule for business-to-business services in most VAT systems is that the supply is treated as taking place where the customer belongs, and the customer accounts for the tax themselves under a reverse charge. HMRC's guidance on the place of supply of services sets this out for the UK, and the EU operates on the same underlying principle. The practical consequence for you is the one-line statement in field 6 of the checklist, plus keeping evidence that your customer really is a business, which normally means their VAT number and a record that you validated it.

Frequently asked questions

Should I put both currencies on the invoice?

One currency is payable, and that one belongs on the total. If the client genuinely wants a reference figure in another currency, add it as a clearly labelled estimate with the rate and date you used, positioned away from the amount due. Two equally prominent totals invite an AP clerk to pay whichever is smaller, and gives you nothing to point at when you dispute it.

Who pays the transfer fees, me or the client?

Whoever the invoice says, which is why you say it. The convention worth asking for is that the client bears all sending, intermediary, and correspondent charges so the full invoice amount lands in your account. Most clients agree without comment when it is written on the invoice, and almost none volunteer it when it is not. Your own receiving-bank fee is normally yours to absorb.

Do US clients need anything special from a foreign developer?

Usually a W-8BEN (or the entity equivalent) on file before they pay you, so they can document your foreign status and apply any treaty rate. Larger companies will also want the legal entity name matching your bank account exactly, an address without abbreviations, and often a vendor-onboarding form. Send the W-8 unprompted with your first invoice and you skip a round trip.

How long do international payments take?

It depends entirely on the rail. Local-rail transfers into a receiving account in the client's own country clear on domestic timelines, often same or next business day. Traditional SWIFT wires typically take a few business days and can take longer when they route through multiple correspondents or land on a weekend or a public holiday in either country. Whatever the corridor, add a few days of buffer to your expectations before you send a chase email, and set your due dates with that buffer already built in.

Cross-border invoicing punishes vagueness. Name the currency, name the tax treatment, name who pays the charges, and most of the friction disappears before it starts. Billable formats USD, EUR, GBP, CAD, AUD and INR correctly, with the right symbol placement and separators for each, and everything stays in your browser rather than on someone's server. Generate your international invoice free, or start from the free invoice template for developers if you would rather see the finished layout first. If you are new to billing on your own, how to invoice as a freelance developer is the place to start.