Getting paid across borders

Fractional work travels. A CFO based in Sydney picks up a client in Singapore. A CMO in London takes on a Series A startup in California. It happens quickly and it happens often, because the thing you’re selling, judgement, at a slice of your time, doesn’t really care where the client’s office is. Getting paid across that border cleanly is a separate skill from winning the work, and it’s one almost nobody teaches you.

Card fees don’t make sense at this size, anywhere

If you’re invoicing a client for a few thousand to tens of thousands a month, the standard advice to “just add a payment link” is worth examining before you take it. Card processing typically runs 2-4% plus a fixed fee per transaction, which on a $10,000 monthly retainer is $200-450 a month, every month, indefinitely, for a convenience the client didn’t specifically ask for.

This isn’t a country-specific quirk. It’s true in the US, the UK, Australia, Singapore, wherever you and your client happen to be. At B2B invoice sizes, bank transfer is already how the overwhelming majority of this money moves, because both sides would rather not pay a toll on it. The right default for a fractional invoice, international or not, is your bank details, not a checkout page.

What actually goes wrong with cross-border bank transfers

The failure mode isn’t the transfer itself, banks move money between countries every day. It’s missing detail on the invoice. A domestic bank transfer inside one country typically needs an account number and a routing code, sort code, or BSB depending on where you are. An international transfer needs more: usually a SWIFT/BIC code identifying your bank, and in most of Europe and much of the rest of the world, an IBAN identifying your specific account.

Miss either of those and the payment doesn’t bounce cleanly, it stalls. The client’s bank asks their finance team for more information, their finance team emails you, you dig out the missing code, and a payment that should have taken two days takes two weeks. None of this is anyone being difficult. It’s just a form with a blank field.

What to actually put on the invoice

For any client paying from a different country to you, make sure your invoice carries:

• Your bank name and account number (or the local equivalent, IBAN in much of Europe, a plain account number elsewhere)
• Your bank’s routing identifier for your own country (sort code, BSB, routing number, transit number, whichever your country uses)
• Your SWIFT/BIC code, so the sending bank can route the payment to the right institution internationally
• Your IBAN if your bank issues one, since a growing number of international payment rails require it even outside Europe

None of this needs to appear on every invoice, only the ones going to a client paying from overseas, and it’s one of the few places where more information on an invoice is unambiguously better than less. A domestic client doesn’t need to see a SWIFT code. An overseas one can’t pay you cleanly without it.

Multi-currency is a separate, related problem

The other half of cross-border billing is currency. Invoicing a US client in USD while your own books run in GBP is normal and shouldn’t require a workaround. What matters is capturing both the invoiced amount and what actually lands in your own currency once the transfer happens and the exchange rate has done what exchange rates do, so your records reflect reality rather than the number on the invoice.

How Quivva handles this

Quivva invoices in your client’s currency with local-amount capture at payment, so a USD invoice and a GBP bank account reconcile properly without manual conversion. Every invoice shows the relevant bank details for the client paying it, including SWIFT/BIC and IBAN, when they’re set, so an international client has everything their bank needs the first time, not after a follow-up email. It shows up when populated and stays out of the way when it isn’t relevant, because the question that matters is where your client is banking from, not which country you happen to be in.