海外クライアントへの請求:通貨・税・住所の実践ガイド
InvoiceFlow 編集部 — 2026年6月16日公開 — 約10分で読めます
初めて海外のクライアントに請求書を送るとき、「請求書を送る」という行為が、実は裏で多くの仕事をこなしていたことに気づきます。ベルリンのクライアントはユーロを期待し、あなたが小数点を打つ場所にカンマがあることを当然と思い、ドイツの税表記らしい税の行を求めます。トロントのクライアントはカナダドルを望み、「ZIP」ではなく実際に「Postal code(郵便番号)」と書かれた欄に郵便番号を入れたいと考えます。東京のクライアントは、あなたの母国の前提だけで組み立てられた書類に目を細めずに済むほうが、ずっとありがたいのです。
これらはどれも難しいことではありません。ただ、放っておくとアマチュアっぽく見えてしまう一方で、意図的に処理すれば「これを何百回もやってきた人」のように見せられる、小さな細部の集まりにすぎないのです。本記事はそのための実践ガイドです。各請求書を正しい通貨で発行する方法、クライアントが期待するとおりに数字が合うように税を処理する方法、クライアント自身の言語でPDFを出力する方法、そして199カ国のいずれにも対応した正しい住所を入力する方法を解説します。以下の操作はInvoiceFlowでの動作を前提にしていますが、その原則はまともな請求環境であればどこにでも当てはまります。
通貨:1枚の請求書につき1つの通貨、推測は禁物
国境を越えた請求の鉄則は、請求書は1つの通貨で表示され、その通貨はあなたのものではなくクライアントのものであるということです——別の理由が特にある場合を除いて(契約によっては、クライアントの所在地に関係なく請求通貨をUSDやEURに固定するものもあります。その場合は契約に従ってください)。ドイツの代理店は、ドル建ての請求書を受け取って自分たちで換算したいとは思いません。米国のクライアントは、ポンド建ての合計額に頭を悩ませたくありません。通貨はクライアントごとに一度だけ決め、一貫して使い続けましょう。
InvoiceFlowでは、各請求書をそれぞれの通貨で、正しい書式で発行できます。この最後の部分は、聞こえる以上に重要です。「正しい書式」とは、通貨記号、数字に対するその位置、桁区切り、小数点の区切りのすべてが、その通貨の慣習に一致していることを意味します。€1.234,56 と $1,234.56 は同じ金額をまったく異なる2通りの方法で書いたものであり、これを間違えると、経理部門に眉をひそめさせる類の小さな手がかりになってしまいます。
さらに、クライアント設定でクライアントごとの既定通貨を設定できるので、そのクライアント向けの次の請求書は自動的に正しい通貨で開きます。このたった1つの設定が、国境を越えた請求で最もよくある間違い——アプリの既定がそうだったからという理由で、ユーロのクライアントに自国通貨の請求書を送ってしまうこと——をなくしてくれます。
アプリがすること——そしてしないこと
ここで正直な線引きをしておきます。これがあなたの作業の仕方を変えるからです。InvoiceFlowは各請求書を、指定された通貨で書式設定し、その通貨で残高を追跡します。自動的なライブの為替換算は行いません。金額は、必要に応じて為替レートとともに、あなたが決めます。アプリが送信時にこっそり仲値レートを取得し、裏であなたの数字を換算しているわけではありません。
これは欠点ではなく機能であり、国境を越えた請求が実際にどう機能するかを反映しています。ミュンヘンのクライアントにプロジェクト料金として €2,000 を提示したなら、請求するのは €2,000 です——それで終わりです。換算する必要はありません。それがその通貨での価格なのです。€2,000 が決済された日に自国通貨でいくらになったかを記録する、自国での帳簿付けは別の作業であり、それは入金後に、銀行が実際に提示したレートで行われます。この2つを混同すること——ある通貨で請求しながら、ひそかに別の通貨で考えること——こそ、フリーランスが自らをこんがらがらせてしまう原因なのです。
ですからワークフローはすっきりしています。
- クライアントの通貨で価格に合意します。その通貨で直接見積もったか、見積もり時にあなたの料金を一度だけ換算して固定したかのどちらかです。
- その正確な金額で請求します。アプリはその通貨向けに正しく書式設定します。
- 支払いが完了するまで、その通貨で残高を追跡します。分割で入金される場合は、それに対して部分支払いを記録します。
- お金が届いた後、自国通貨に照合します。推定値ではなく、銀行の明細書にある実際のレートを使います。
クライアントに参考用の換算額(「本日のレートで約 $2,150」など)を表示したい場合は、目安であることを明記したうえで、請求書の備考にテキストの一行として記載しましょう。請求金額はクライアントの通貨のままにします。
税:内税・外税、複数税率、そして税抜額
税は、国境を越えた請求書が最も静かに狂いやすいところです。なぜなら、国によって基本が一致していないからです——税率も、名称も、そして決定的に、価格が通常、税を含んだ形で表示されるのか、税を含まない形で表示されるのかも、一致していません。
内税か外税か——クライアントが期待するほうを選ぶ
InvoiceFlowは内税(税込)と外税(税抜)の両方の価格設定に対応しており、この選択は見た目だけの問題ではありません——クライアントが「価格」として読む数字そのものを変えるからです。
- 外税(税抜):明細項目は税抜価格を表示し、税は別の行として追加され、合計はそれらの和になります。これは世界の多くの地域でB2B業務の標準です。企業はどのみち税を控除できるので、純額(ネット)で考えます。
- 内税(税込):表示される価格にはすでに税が含まれており、請求書ではその価格のうちいくらが税だったかを内訳として示します。これは多くの国で消費者向けの価格設定によく見られます。法律や慣習により、表示価格こそが顧客の支払う額だからです。
これは市場ごとに正しく合わせましょう。B2Bのドイツのクライアントが、明確に分離されたVAT(付加価値税)の行を備えた外税の請求書を読むとき、彼らはまさに期待どおりのものを目にしています。同じクライアントが内税の請求書を受け取ると、自社の帳簿のために税抜の数字を逆算しなければならないかもしれません——あなたが理由もなく作り出した手間です。
1枚の請求書に複数の税率
現実の請求書は、必ずしも単一税率とは限りません。1人のクライアントにコンサルティング(ある税率)と物品(別の税率)を一緒に請求することもあれば、軽減税率と標準税率にまたがる業務もあります。InvoiceFlowは1枚の請求書で複数の税率を扱い、行ごとに正しい税率を適用し、税率別に税を集計します。クライアントは、自分では検証できない混ぜ合わせた1つの数字ではなく、すっきりとした内訳を目にします。
税抜額と請求額
これらすべての土台として、アプリは税抜額と請求額(支払うべき額)を正しく計算します。そのため、内税・外税・複数税率のどの組み合わせを使っても、合計はきちんと整合します。支払いが一部入金されれば、請求額は残高に対して更新されます。あなたは深夜11時にこの計算を手作業でする必要はありません——計算ミスが請求書に忍び込むのは、まさにその時間帯なのですから。
どんなアプリにも決められない、国境を越えた税についての実務上の注意点を1つ。海外取引にそもそも課税するかどうかは、アプリの設定ではなく、法律上の問題です。リバースチャージのルール、輸出のゼロ税率、供給地判定——これらはあなたの管轄、クライアントの管轄、そして何を販売しているかによって決まります。アプリは、あなたが指定したとおりの税の取り扱いを忠実に表示します。正しい取り扱いを知るのは、あなた(またはあなたの会計士)の仕事です。まずルールを決め、次に請求書を設定しましょう。
請求書ごとのロケール:クライアントの言語で出力する
ここからは、人を静かに感心させる細部です。あなたのアプリは英語で動いていても、クライアントに渡す請求書はドイツ語、フランス語、あるいは日本語で出力できます。
InvoiceFlowは請求書ごとのロケールに対応しています。特定の請求書の言語を設定すると、生成されるPDF——「請求書」「支払期限」「小計」「税」「合計」といったラベルや、日付の書式など——が、アプリの設定言語に関係なく、その言語でレンダリングされます。あなたは使い慣れたインターフェースで作業し、クライアントは自分のために作られたかのように読める書類を受け取るのです。
これはアプリのPDFレンダリングと組み合わさります。このレンダリングは、同梱のNotoSansフォントとユーザーが選択できるフォントを使って、非ラテン文字を正しく扱います——キリル文字、アラビア文字、CJK(中日韓)も。東京やリヤドのクライアント向けの書類が、本来文字があるべき場所に空の四角が並ぶようなことにはなりません。文字化けしたPDFを受け取ったことがあるなら、それがいかに一瞬で信頼を損なうかをご存じでしょう。ここを正しく処理することは、有能さを示す小さな一手です。
実務上の動き方はこうです。各海外クライアントの希望する請求書ロケールを一度だけ設定しておきます。それ以降は、あなたが自分のインターフェースから離れることなく、彼らの請求書は自動的に彼らの言語で出力されます。
住所:199カ国、しかも欄がちゃんと合う
国際請求の地味な真実は、住所が国によって驚くほど不統一であり、1つの硬直した住所フォームではあらゆる外国の住所がどこか少しおかしく見えてしまう、ということです。
InvoiceFlowの住所欄は199カ国にわたって国に対応しています。クライアントの国を選ぶと、2つのことが起こります。
- 地域と郵便番号のラベルが適応します。米国で「ZIP code」であるものは、カナダでは「Postal code」、英国では「Postcode」、インドでは「PIN code」です。その国がラベル付けするとおりに欄が表記されるので、受け取る相手にも、その経理担当チームにも、住所が自然に読めます。
- 一部の国では地域と郵便番号が完全に非表示になります。州/地域の行や、他国のような郵便番号を使わない国はいくつもあります。そうした国の住所に空の「State(州)」欄を無理に押し付けると、その国を知らないように見えるだけです。フォームは、当てはまらない欄を取り除きます。
その成果が、現地の人が書いたかのように見えるPDF上の住所ブロックです——正しい欄名、正しい欄の存在、無理のなさ。正しいときには目立たず、間違っているときには目立つ。だからこそ、正しく処理する価値があるのです。
まとめて実践:具体的なガイド
あなたが、海外に3人のクライアントを抱えるフリーランスのデザイナーだと想像してください。ミュンヘンの代理店(ユーロで支払い、B2B、明確なVATの行を備えた外税を期待、請求書はドイツ語希望)、トロントのスタートアップ(カナダドル、英語、郵便番号)、そして東京のスタジオ(日本円、日本語の請求書)。以下が、一度きりの初期設定と、繰り返し行うワークフローです。
- 各クライアントを一度だけ設定します。それぞれについて、既定通貨、希望する請求書ロケール、そして国(これが住所ラベルを確定します)を設定します。ミュンヘン:EUR、ドイツ語、ドイツ。トロント:CAD、英語、カナダ。東京:JPY、日本語、日本。
- クライアントごとの税の取り扱いを会計士と決め、そのうえで設定します。ミュンヘンの請求書はVATの行を備えた外税。その他は、それぞれの取引に対するあなたのルールに従います。
- 請求書を作成します。正しい通貨で開きます。明細項目はその通貨で入力します——その場で換算した数字ではなく、実際に合意した数字です。
- 合計はアプリに任せます。税抜額、税率別の税、請求額のすべてが正しく計算されます。
- PDFを生成します。クライアントの言語で出力され、通貨を正しく書式設定し、たとえクライアントの言語が非ラテン文字でも、正しいラベルで住所をレンダリングします。
- 追跡と照合を行います。残高は請求書の通貨で追います。支払いが完了したら、自国の帳簿に、銀行からの実際の自国通貨の数字を記録します。
3人のクライアント、3つの通貨、3つの言語——それでも、あなたの側からは毎回同じ数回のタップで済みます。クライアントごとの設定が、その違いをあなたの代わりに引き受けてくれるからです。
積み重なる小さな細部
国境を越えた請求は、国内の請求にはない形で、正確さに報いてくれます。国内では、少しずれた住所ラベルや見慣れない税の表記は、誰もが同じ前提を共有しているために気づかれずに済みます。国境を越えると、あらゆる不一致が、あなたが場当たり的にやっているという小さなサインになります。ユーロの請求書がユーロで、ドイツ語で、ドイツの請求書らしくレイアウトされたVATの行とともに、正しく読める住所ブロックを添えて届くフリーランスは、プロのベンダーとして扱われます。一方、AP(買掛金)チームが処理する前に翻訳・換算・再書式設定が必要な請求書を送るフリーランスは、「ちょっと面倒な外国の取引先」になってしまうのです。
これはクライアントごとに一度設定するだけで済みます。それ以降は、現地の人のように見えるか観光客のように見えるかの差が、あなたの送るすべての請求書に組み込まれます——しかもそのコストは、最初にクライアントの通貨・言語・国を正しく入力する10分間だけなのです。