1越境ECで「3つの単位」が同時にズレる

「越境ECに挑戦したい」「海外Amazonに出店したい」「Shopifyで海外向けに展開したい」――。国内ECで成果を出した事業者が次のステップとして必ず検討するのが、海外への販売拡大です。

しかし、多くの事業者が踏み出した直後に、想定していなかった3つの問題が「同時に」発生することに気づきます。

• 時差 ―― 注文時刻が9～15時間ズレ、日次集計が国内モールと合わない
• 通貨 ―― 売上はドル/ユーロ建て、原価は円建て、為替差益・差損で利益が見えない
• 日付 ―― 「07/05/2026」が5月7日か7月5日かで2ヶ月の解釈差

個別に見ればどれも対処可能ですが、これらが「同時に」「毎注文ごと」に絡み合うのが越境ECの本当の難しさです。「時差で日付が変わり、その日付の為替レートで売上を換算し、それを国内会計の月次に集計する」――この一連の流れのどこかでロジックを間違えると、毎日数件、月次で数百件のデータが歪んで蓄積されます。

2事故①: 時差 ― 受注時刻と日次集計のズレ

まず時差から。日本（JST: UTC+9）とアメリカ東部（EST: UTC-5、夏はEDT: UTC-4）の時差は14時間（夏時間中は13時間）。日本とロンドン（GMT: UTC+0、夏はBST: UTC+1）の時差は9時間（夏時間中は8時間）。

「日本で5月7日の朝9時に米国Amazonでチェックした受注一覧」と、「米国Amazon側で5月7日の朝9時にチェックした受注一覧」は、同じ瞬間ではありません。これだけで毎日のオペレーションが噛み合わなくなります。

米国Amazonの「日次売上」が日本の管理画面で1日ズレる

もっとも頻発するのがこのパターン。米国Amazon SP-APIから取得した受注データには、すべてUTC基準のタイムスタンプが付いています。これを日本側のシステムで「日付だけ取り出して集計」すると、日本時間の朝0時～9時の注文がすべて前日扱いになります。

毎日数十件しか海外注文がない時期は気づきませんが、月100件を超えるあたりから「数字が微妙に合わない」現象が確実に発生します。詳しくはタイムゾーンの罠で解説していますが、越境ECではこれがさらに「為替換算」と組み合わさるため、修正が困難になります。

セール開始/終了時刻のタイムゾーン指定漏れ

海外Amazonでセールを設定するとき、「2026-05-10 00:00」と書いただけでAPIに送ると、Amazon側はUTCと解釈し、日本時間で5/9の朝9時にセールが始まることになります。

逆に「日本時間の5/10 0時開始」のつもりで「2026-05-10T00:00:00+09:00」と送るのを忘れると、米国の顧客から見ると現地時刻5/9朝10時にセールが始まることになり、想定外の時間帯にセール価格が走り出します。

夏時間切り替えで「年に2回」スケジュールがズレる

米国・欧州・オーストラリアは年に2回、夏時間（DST）の切り替えを行います。日本側は何もしていなくても、3月と11月（米国の場合）に時差が1時間動くため、海外向けに固定スケジュールを組んでいると、その日だけ1時間ズレます。

3事故②: 通貨 ― 為替レートと「いつのレートで換算するか」

次に通貨。海外で売れた商品は、当然ながら現地通貨建て（USD・EUR・GBPなど）で売上が計上されます。この売上を日本円に換算するときに、「いつのレートを使うか」が大きな問題になります。

注文日のレート？ 入金日のレート？ 月末のレート？

たとえば、米国Amazonで100ドルの売上があったとします。日本円換算するときの「その日のドル円レート」は、次のどれを使うべきでしょうか？

基準	例（1ドル=150円～155円）	使われる場面
注文日のレート	5/7のレート 153円 → 15,300円	受注時の見込み売上
出荷日のレート	5/9のレート 152円 → 15,200円	会計上の売上計上日
入金日のレート	5/21のレート 150円 → 15,000円	実際の円換算入金額
月末レート	5/31のレート 155円 → 15,500円	月次決算の換算
Amazonが使うレート	独自の換算レート 151円 → 15,100円	Amazon送金時の実際レート

つまり、同じ100ドルの売上が、基準によって14,900円～15,500円まで変動します。1件で500円のズレが、月100件、年1200件積み重なれば、年間60万円以上の数字が「どう集計するか」だけで変わることになります。

為替差損益の管理 ― 売上と入金の「タイムラグ」

米国Amazonは売上が即日入金されるわけではありません。通常は2週間ごとに送金されます。この間に為替レートは確実に動きます。

この「2週間の為替変動による差額」は、毎送金ごとに必ず発生します。年間数百万円の海外売上があれば、為替差損益だけで数十万円～数百万円のブレになり、税務上も「為替差益」「為替差損」として分けて記録する必要があります。

原価が円・売上がドル ― 利益率が見えなくなる

もうひとつ厄介なのが、原価は円建て・売上はドル建てという構造です。

• 商品の仕入れは日本国内 → 円建て（5,000円/個）
• 米国Amazonへ出品し売上発生 → ドル建て（$50/個）
• FBA手数料・広告費はドル建てでAmazonに引かれる
• 送金時にドル → 円に変換

「1個あたりの粗利」を出そうとした瞬間、複数の為替レートが絡みます。「為替が1ドル150円のときは利益率20%だったのに、145円になったら15%に落ちた」――こういう変動が、店主が何もしていないのに発生します。海外取引における利益管理は、ほぼ間違いなくPQ会計の落とし穴と同じレベルの「数字の見方」のリテラシーが必要になります。

4事故③: 日付 ― フォーマットの読み違い

3つ目が日付フォーマット。詳しくは世界の日付フォーマット完全マップで解説していますが、越境ECでは「読み違い」が即座に金銭的損失に繋がります。

米国モール「03/04/2026」を日本式DMYで読むと1ヶ月ズレる

米国Amazon・米国eBay・米国Shopifyから取得したデータの日付欄は、米国式MDY（月/日/年）。これを日本のシステムが「自動判別」モードで取り込み、05/07/2026を「7月5日」と誤読。気づくのは月次レポートを集計するときで、すでに数百件の受注データに間違った日付が入っています。

欧州サプライヤーの請求書「07.05.2026」

ドイツ・フランスなどの欧州サプライヤーから届くインボイスには「07.05.2026」と書かれます（DMYでドット区切り）。これを「アメリカ式MDY」と勘違いして「7月5日」と読み込み、支払期日を2ヶ月後ろにズラして処理。結果、欧州サプライヤーから遅延損害金の請求が来ます。

納期通知メール「07/05/2026」が相手国で誤読される

日本側から海外取引先へ「納期: 07/05/2026」とメール。日本人は「7月5日」のつもりでも、相手が欧州DMY読みなら「5月7日」。相手は2ヶ月早く納品を準備し始めます。

これを防ぐには、海外への納期通知は必ず「2026-07-05」（ISO 8601）か「July 5, 2026」（月名スペル）にする社内ルールが必要です。

53つが同時に絡む ― 越境ECで一番怖いシナリオ

ここまで時差・通貨・日付を個別に見てきました。越境ECで本当に怖いのは、これら3つが同時に1件の注文に絡むことです。

シナリオ: 「2026年5月の米国売上」を集計したい

シンプルな業務命令です。「先月の米国Amazon売上を円換算で出してください」。一見3分の作業に思えますが、実際には次の判断を全て行わなければなりません。

1. 「5月」とはいつのことか？ ―― 米国時間の5月？ 日本時間の5月？ UTC基準の5月？ 月初・月末で1日ズレる
2. 注文の「日付」をどう判定するか？ ―― SP-APIから取れるUTCタイムスタンプを、JSTに変換して日付を切り出すか、米国時刻に変換して切り出すか
3. 「円換算レート」をどう選ぶか？ ―― 注文日のTTMレート？ 入金日のレート？ Amazonの送金時実レート？
4. 5月末の最終日のレートを使う場合、「5月末」も時差で揺れる
5. キャンセル・返金が発生した場合、その日のレートで再計算が必要

1件の注文を「5月の売上」に算入するかどうかが、時差・日付フォーマット・通貨換算ロジックの3つの判定に依存します。これを毎月100件、200件と処理していくと、「ロジックを少し変えただけで月次売上が10万円単位で変わる」事態が普通に起きます。

「正しい数字」は1つではない ― 定義を決める覚悟

越境ECにおいて、「絶対に正しい売上数字」は存在しません。あるのは「どの定義で集計するか」という社内ルールだけです。

• 会計上の売上計上日 ＝ 出荷日のJSTレート換算
• キャッシュフロー管理 ＝ 入金日のJSTレート換算
• マーケティング分析 ＝ 米国現地時刻の注文日基準
• 税務申告 ＝ TTMレートの月次平均

これらを最初に決めて文書化していないと、月次レポートを作るたびに「先月と数字の出し方が違う気がする」「Amazonの管理画面と合わない」「税理士に提出した数字と自社のExcelの数字が違う」という事態が永久に続きます。

6越境ECに踏み出す前のチェックリスト5項目

越境ECに踏み出す前に、最低限これだけは決めておきたい5つのチェック項目を挙げます。これらが決まっていない状態で出店すると、半年後に「数字が何も信用できない」状態に陥ります。

チェック1: 売上計上の「タイムゾーン基準」を決める

「米国Amazonの売上は、何時時点での日付で集計するのか」を最初に決定。JST基準か米国現地基準かUTC基準か。これを決めないとレポートが作れません。一般的には「会計はJST基準、マーケティングは現地基準」と用途別にダブル基準で運用するケースが多いです。

チェック2: 為替レートの「換算ルール」を決める

売上の円換算に使うレートを、「注文日のTTMレート」「出荷日のレート」「入金日の実レート」「月末レート」のどれにするかを決定。会計士・税理士と相談して決めるのが望ましいです。

一度決めたら社内で統一する。Excel職人ごとに「私はその日のレートを使ってます」「私は月末レートです」とバラバラだと、後で誰の数字も信用できなくなります。

チェック3: 海外宛の日付表記ルールを徹底する

海外取引先・海外サプライヤー・海外SaaSへの日付通知は、必ずISO 8601（2026-07-05）か月名スペル（July 5, 2026）。「07/05/2026」のような数字＋スラッシュ表記は社内禁止にする。

チェック4: 内部DBはISO 8601 + UTCで統一

自社の受注DBやレポート基盤では、すべての日時をISO 8601形式 + UTCで保存。表示するときだけJSTに変換する。これはタイムゾーンの罠の鉄則と同じです。

「とりあえず日本のシステムだから日本時間でいいだろう」で始めると、海外モール追加のときに過去データを全部やり直すことになります。

チェック5: 月次集計のロジックを「文書化」する

「米国売上はこう集計する」「為替はこう換算する」「タイムゾーンはこう判定する」――これを社内ドキュメント（Notion・Wiki・Excelシート何でもよい）に明文化。担当者が変わったとき、数年後に税務調査が入ったとき、Amazon側のレポート定義が変わったときに、「過去にどういう定義で集計していたか」を再現できる状態にしておく。

チェック項目	決めること	決めないと起きること
1. タイムゾーン基準	JST or 現地 or UTC	月次売上が毎月数万円ブレる
2. 為替換算ルール	注文日 / 出荷日 / 入金日 / 月末	会計と税務とAmazon数字が永久に合わない
3. 海外宛日付表記	ISO 8601 or 月名スペル	納期誤読・支払い遅延・遅延損害金
4. 内部DBの形式	ISO 8601 + UTC統一	モール追加時に全データ作り直し
5. 集計ロジック文書化	Notion / Wiki / Excel	担当者変更で数字の出し方が変わる

7自力対応の限界と、プロに任せるという選択肢

ここまで読んで「想像以上に決めるべきことが多い」と感じた方は正しい感覚を持っています。越境ECは「出店すること」より「数字を正しく扱う仕組みを作ること」の方が圧倒的に難しいのが実態です。

国内ECなら、楽天もAmazonもYahoo!も全部JSTで動いていて、すべて円建て、日付フォーマットも基本「2026/05/07」で揃っています。違いはモール仕様の差くらいで、「単位」のズレは存在しません。

越境ECに踏み出した瞬間、この前提が全て崩れます。

• 時差で毎日1時間～15時間のズレが発生
• 為替で毎日数%の変動が発生
• 日付フォーマットで解釈の揺れが発生
• これらが毎注文ごとに掛け算で蓄積する

「とりあえずまず始めてみよう」「動きながら考えよう」というスタンスは、国内ECなら通用します。海外ECでは、動き始めた後でルールを変えると、過去データが全部使い物にならなくなるため、踏み出す前の設計品質が後の運用負担を決めます。

「越境ECに興味があるが、どこから手をつけてよいか分からない」「すでに海外Amazonを少しやっているが、毎月の数字が信用できない」「自社のシステム会社に相談しても、EC現場の事情まで分かってもらえない」――こうした相談は、EC実務とシステム設計、そして会計の数字感覚の三方を理解した人間に投げるのが、結果的にいちばん早く片付きます。

関連記事もぜひあわせてご覧ください。タイムゾーンの罠（時差編）、世界の日付フォーマット完全マップ、日付フォーマットの罠、PQ会計の落とし穴、EC業務の自動化、その落とし穴。