為替換算はスプレッドシートに任せている ― GOOGLEFINANCEで実際に組んでいる式と、月末だけ #N/A になった話

輸出や越境ECをやっている顧問先の月次では、外貨建ての売上・残高を円に換算する作業が毎月そのまま残ります。件数が増えるとレートを都度調べて手入力するのは現実的ではないので、私が見ている先では、この換算をGoogleスプレッドシートの GOOGLEFINANCE 関数に任せています。

国内の銀行口座やクレジットカードは連携で明細が自動で取れますが、eBay・Shopeeの売上金やPayoneer経由の入金は、そもそも自動連携の対象外です（この入金がなぜ売上と一致しないのかは前回の記事で書きました）。「いくらの円として記帳するか」は、こちらで決めて入力するしかありません。

この記事は、その一般論ではなく実際に組んでいる式と、運用していて実際にハマったところの記録です。関数の使い方そのものより、月末の締めで壊れる場所がどこかのほうが、たぶん役に立ちます。

実際に使っている式

売掛金の内訳シートで使っているのは、この形です。

=INDEX(GOOGLEFINANCE("CURRENCY:USDJPY","price",A43),2,2)

A43 に対象日を入れておくと、その日のレートが返ります。ポイントは2つあります。

1つ目は「今のレート」を取っていないこと。 月次の集計で必要なのは月末時点のレートで、締め作業をしている日の相場ではありません。GOOGLEFINANCE は引数に日付を渡せるので、行ごとに対象日を指定しています。そもそも、日付を指定しない書き方で取れる相場はGoogle公式のヘルプによれば最大20分程度の遅延が発生する場合があるとされていて、締めの数字を取りにいく用途には向きません。

2つ目は INDEX で囲んでいる理由。 日付を指定すると、GOOGLEFINANCE は数値ではなく見出し行つきの表を返します。公式ヘルプにも「Historical data, even for a single day, will be returned as an expanded array with column headers」と書かれているとおりで、1日分でも2行×2列で返ってきます。そのままだと隣のセルを踏み潰すので、INDEX(...,2,2) で2行目・2列目の数値だけを抜き出しています。

シートの形

売掛金の内訳は、月末日ごとに1行、こういう列構成にしています（実際には複数年分を縦に積んでいます）。

見出しを「日付」ではなく、「日付(アメリカ)」にしているのは、あとで書く理由からです。

この形にしている一番の理由は、右端の元帳残高の列です。換算した円合計のすぐ横に会計ソフト側の残高を置いておくと、差が出た月がその場で分かります。換算シートと帳簿を別々に持っていると、ズレに気づくのが決算のときになります。

決済サービスと銀行では入出金日が前後することがあるので、ズレた行には摘要欄に理由を書き残しています。翌月の自分か、確認する側の私が読む前提のメモです。

月末行だけ #N/A になった ― 日米の休場日

運用していて実際に起きたのが、ある月の行だけ為替レートのセルが #N/A になっていたことです。しかも通貨はドル円という、最もメジャーで流動性の高いペアでした。

原因は通貨ではなく、日付でした。GOOGLEFINANCE が見ているのはアメリカ側の市場のデータなので、指定した日付がアメリカの休場日（週末・現地の祝日）に当たると、その日のレートは存在せず #N/A が返ります。日本の営業日カレンダーとアメリカの営業日カレンダーは一致しないので、日本側の感覚で月末日を機械的に渡していると、この差に気づきません。列の見出しを「日付(アメリカ)」にしているのは、この一件があったからです。

厄介なのは、壊れ方が連鎖することです。レートのセルが #N/A になると、それを掛けている円換算列が全部 #N/A になり、小計も円合計も #N/A になります。行の数が多いと、パッと見では月末の合計行が空欄に見えるだけなので、そのまま次の作業に進んでしまいます。

対策として入れているのは次の2つです。

=IFERROR(INDEX(GOOGLEFINANCE("CURRENCY:USDJPY","price",$A43),2,2),
         INDEX(GOOGLEFINANCE("CURRENCY:USDJPY","price",$A43-1),2,2))

前日にフォールバックする形です。ただし黙って前日に落とすのは危険なので、隣に「どの日付のレートを使ったか」を出す列を立てて、指定日と違う場合が目で見て分かるようにしています。どの日のレートを使ったかは、あとから説明を求められる可能性がある情報です。自動で穴埋めして記録が残らない組み方にはしないほうがいいと考えています。

もう1つは、締めのチェック工程です。月次を締める前に、シート全体で #N/A と #REF! が残っていないかを確認します（行の挿入・削除をすると #REF! のほうが出ます）。合計セルの下に =COUNTIF(範囲,"#N/A") のような検知セルを1つ置いておくだけでも違います。

多段換算 ― 現地通貨 → USD → 円

東南アジア系のマーケットプレイスを使っていると、換算が1回では終わりません。入金レポートは現地通貨（シンガポールドルなど）で出て、そこから決済用の通貨（多くはUSD）に換えられ、最終的に円で着金します。

なので、こちらのシートも列を2本持っています。現地通貨→USDのレートと、現地通貨→円のレートです。設計としては次の2択になります。

私が見ているシートは後者です。売上と入金が合わない相談を受けたときに、「どの段階で差が出たのか」を分けて説明できるほうが、結局やり取りが早く終わります。

多段にすると、端数の関係で最後にどうしても数円〜数十円の差が残る行が出ます。ここは摘要に「為替計算のため入金微調整」と明記して調整しています。調整すること自体より、調整した行に必ず理由が書いてある状態のほうが大事です。書いていないと、翌年の自分が同じ計算をやり直す羽目になります。

仕訳に落とすときの形

換算まで終わったら、仕訳の形にします。プラットフォームの売上は、だいたいこの形になります。

売掛金        xxx,xxx / 売上(輸出ビジネス)  xxx,xxx   消費税区分: 輸出売上0%   摘要: eBay(1月分)
支払手数料     xxx,xxx                              課税仕入10%             摘要: ebay手数料(1月分)

売上は手数料を引く前の総額で立てて、プラットフォーム手数料は別途費用に計上します。手数料はシート側で料率の列（0.0222... のような実効率）を確認用に持たせていて、月ごとに極端に動いていないかを見ています。料率が変わったときに気づけるのは、明細を1件ずつ見るよりこの列を見るほうが早いためです。

決済サービスの手数料と為替差損益をまとめて1行で処理している運用も見かけますが、分けるか一緒にするかは最初に決めて、毎月同じにしておくほうがいいです。月によって処理が変わっていると、差の原因を追うときに、まずそこから調べ直すことになります。

なお上の消費税区分は、あくまで一例です。輸出売上として扱えるかどうかは取引の内容と証憑によって変わるので、区分の当否は個別に確認してください。

よくある誤解 Q&A

Q. GOOGLEFINANCEは対応していない通貨ペアがあるのでは？

公式ヘルプに「does not support most international exchanges（多くの海外の取引所には対応していない）」と書かれているのは、株価の取引所についての話で、為替の通貨ペアの制限ではありません。私も最初この2つを混同していました。実際、#N/A で詰まったのはドル円です。通貨がマイナーだったからではなく、日付がアメリカの休場日だったからでした。

Q. このレートを帳簿や申告の数値に使っていいのですか？

通達は、この手のやり方を頭から否定してはいません。むしろ条件付きで幅を持たせています。

法人税基本通達13の2-1-2は、外貨建取引の換算について原則を取引日の電信売買相場の仲値（TTM）としたうえで、継続適用を条件に、売上その他の収益・資産はTTB（電信買相場）、仕入その他の費用・負債はTTS（電信売相場）によることを認めています。さらに注書きで、継続適用を条件として、取引の内容に応じてそれぞれ合理的と認められる為替相場も使用できるとされ、前月・前週の末日や当月・当週の初日のレート、1か月以内の一定期間の平均値といった例が挙げられています。

相場の入手先についても、原則はその法人の主たる取引金融機関のものとしつつ、同一の方法により入手等をした合理的なものを継続して使用している場合には、これを認めるという書き方になっています。つまり「銀行が公表しているものでなければ一切だめ」という作りではありません。

条件は2つです。同一の方法で継続して使っていることと、合理的と認められる相場であること。前者は、スプレッドシートで組んでいれば満たしやすい部分です。毎月同じ式が同じ手順で取りにいくので、人が都度レートを探してくるより、むしろ方法は一定になります。

詰めるべきは後者のほうです。GOOGLEFINANCE が返すのは市場の相場であって、銀行が公表する対顧客電信相場そのものではありません。ここをどう位置づけるかは、取引の内容や金額の規模によっても変わります。だからこの記事では「使ってよい／だめ」を一律には書きません。取得元と取得方法を先に税理士と決めてから走らせる、というのが実務上の順番です。取得日・取得元・実際に使った日付をシートに残しておけば、決めた方法どおりに続いていることは示せます。

Q. 為替差損益が数千円ズレるくらい、誤差の範囲では？

金額の大小より、原因が説明できる状態かどうかです。件数が多い事業者ほど積み上がりますし、原因が分からないまま残った差額は、決算のときに結局全部さかのぼって調べることになります。

明日からできること

• 為替換算に使っているシートの日付列が、どちらの国の日付かを確認する。月末日をそのまま渡している場合、アメリカの休場日と重なる月がある
• レートのセルを IFERROR で囲み、実際に使った日付を出す列を隣に立てる（黙って前日に落とさない）
• シート内に #N/A / #REF! の検知セルを1つ置き、締める前に必ず見る
• 換算後の円合計の横に、会計ソフト側の残高を並べる。ズレた月にその場で気づける
• 現地通貨→USD→円のように多段になる経路は、どの段階でどのレートを使うかを決めて固定し、月ごとに変えない
• レートの取得元と取得方法を、税理士と一度すり合わせておく

為替換算の自動化そのものは、月次の手間を確実に減らします。ただ、壊れるのはたいてい関数そのものではなく、日付の扱いと、壊れたことに気づく仕組みがないことのほうです。

参考

• Google：GOOGLEFINANCE関数 - Google Docs エディタ ヘルプ
• 国税庁：法人税基本通達 第2節 外貨建資産等の換算等（13の2-1-2ほか）
• 法人税基本通達13の2-1-2 条文（税研 法令データベース）

※本文中の税務上の取り扱いは一般的な原則を整理したものです。個別の判断は、必ず顧問税理士にご確認ください。