AmazonのIOSSとVATの解説とIOSS番号の確認ポイント

スポンサーリンク

AmazonIOSSVATで調べているあなたは、たぶん「AmazonでVATを払ったのに受取時にVAT請求された」「通関手数料まで乗ってきた」「出品者としてIOSS番号どこにあるの?」みたいな、現場のモヤモヤを今すぐ解決したいはずです。ここ、気になりますよね。

私も日本から海外発送(FBM/MFN)をやっていると、150ユーロやintrinsic valueの判定、同梱consignmentの扱い、deemed supplier(みなし供給者)でAmazonがVATを徴収する条件あたりで、つまずきやすいなと感じます。さらに、注文詳細でIOSS番号が表示されない、IOSSラベルが表示されない、DHLなどでelectronic transmission(電子送信)運用だった、みたいな「仕様」を知らないと、VAT二重請求っぽく見える事故が起きがちです。

この記事では、IOSSとは何か、OSSとIOSSの違い、22ユーロ免税廃止の背景も含めつつ、SP-APIのIossNumber、IM44系の表示の話、フランスの150ユーロ制限、UK VAT(£135の別ルール)やEORIが絡むパターンまで、出品者・購入者どちらの視点でも整理します。

先に言っておくと、税務・通関は「絶対こう」と断定できない場面が普通にあります。だからこそ、この記事では考え方とチェックポイントをガチガチに固めて、あなたの現場で迷いにくい形にしていきますよ。

  • AmazonIOSSVATとIOSSの基本構造
  • 150ユーロとintrinsic valueの判定
  • IOSS番号の確認と配送会社への渡し方
  • VAT二重課税に見える原因と対処
スポンサーリンク

AmazonIOSSVATの仕組み

まずは全体像をつかみます。AmazonIOSSVATは「AmazonがチェックアウトでVATを徴収する」場面がある一方で、条件を外すと輸入時課税(+通関手数料)に戻ります。ここを分けて理解すると、トラブル原因の切り分けが一気にラクになります。

私の感覚だと、EU向けの発送で揉める人の多くは「制度を知らない」よりも「制度は聞いたけど、現場データがどこでズレたか分からない」パターンです。なので、この章では“ズレが生まれるポイント”を先に潰していきます。

IOSSとはとVATの違い

VATは、ざっくり言うとEU内の消費にかかる付加価値税です。日本の消費税に近い存在ですが、越境ECでややこしいのは「消費地(配送先国)で課税される」考え方が強い点なんですよ。つまり、あなたが日本にいて日本から発送しても、買い手がEUのどの国に住んでいるかで、課税の扱いが変わり得ます。

ここで登場するのがIOSS(Import One Stop Shop)です。IOSSは、EU域外からEUの消費者(B2C)へ輸入される低額(原則150ユーロ以下)の通販に対して、輸入時にVATを取られないよう、販売時点(チェックアウト)でVATを徴収して月次で申告する仕組みです。つまり、受取時に「追加でVAT払ってね」とならないように、先に徴収しておく発想ですね。

ただし、ここで勘違いしやすいのが「AmazonがVATを取った=自動でIOSSが適用されて、税関も全部理解してくれる」という思い込みです。現場では、税関に渡る申告データにIOSS情報が正しく乗っていないと、VATが輸入時に請求されることがあります。いわゆる「二重課税っぽく見える」事故の入口はここです。

なぜIOSSが重要になったのか

以前は22ユーロ以下の輸入品が免税だった時代もありましたが、EUでは原則として輸入品にもVATがかかる方向に整理されています。だから、低額商品でも受取時課税のトラブルが起きやすくなったんですよね。IOSSは、その摩擦を減らすための仕組み、と理解すると腑に落ちます。

注意:税務・通関は国、配送会社、申告方法、商品の種類や記載内容で結論が変わります。ここで書くのは一般的な整理なので、正確な情報は公式案内や配送会社の要件を確認してください。迷ったら通関業者・税務専門家に相談するのが安全です。

なお、制度の一次情報としては、EU側の「低額貨物の通関とVATの扱い」をまとめた公的ページが一番話が早いです。制度の前提(22ユーロ免税廃止、150ユーロ以下の扱い、IOSSなど)が整理されています。(出典:欧州委員会 税制・関税総局『Customs formalities for low value consignments』

私があなたに一番伝えたいのは、IOSSは「番号があるかどうか」だけじゃなく、税関に届くデータとして成立しているかが重要ってことです。後半で、出品者として何を渡せば事故が減るか、かなり具体的に書きますね。

150ユーロとintrinsic value

IOSSの境界で一番揉めるのがここです。IOSSは原則として、1梱包(consignment)の固有価値(intrinsic value)が150ユーロ以下のB2C輸入に使われます。逆に言うと、ここが150ユーロを超えた瞬間に、IOSSの前提が崩れて輸入時課税(+関税の可能性)に寄りやすくなります。購入者側はここで「AmazonでVAT払ったのに、また取られた!」ってなりがちで、出品者側はクレーム対応がしんどくなります。

intrinsic valueは「モノそのものの価格」が基本で、輸送費や保険料は原則として除外されます。ただし実務では、価格表示が送料込みで別立てがない場合など、除外しづらいケースがあります。ここがブレると、税関側の評価(申告内容の受け止め方)が変わって、150ユーロ超と判断されることがあります。つまり、あなたとしては150以下のつもりでも、税関が見る数字が150超になってしまうことがある、って話です。

「送料を含めるべきか」の迷いは超ある

ここ、気になりますよね。私も最初は「送料って商品代金に入れるの?入れないの?」で何回も手が止まりました。結局のところ、配送会社の申告画面やインボイスの書き方で、送料を分離できるか、総額に含めるしかないかが変わることが多いです。送料の扱いで迷いやすい人は、先にサイト内の実務記事も読んでおくと整理しやすいです。国際郵便での税関申告:商品代金に送料を含めるべきか?注意点は、この論点にかなり寄っています。

私の結論:出品者側は「150ユーロ以下のつもり」で動くより、インボイス(商業送り状)と申告データで固有価値が誤解されない形を作る方が事故が減ります。

論点 見られやすいところ 私がやりがちな対策
150ユーロ基準 1梱包(consignment) 同梱で超えそうなら分割も検討
intrinsic value 物品価格(表示方法でブレる) 送料や割引の表記を整えて誤解を防ぐ
対象外品 品目の性質 酒・たばこ等は別ルート前提で考える
税関の評価修正 内容物説明・価格の妥当性 説明を具体的にして「よく分からない」状態を避ける

あと地味に効くのが、内容品の説明です。たとえば「Gift」「Sample」みたいな曖昧な書き方をすると、税関が慎重になって確認が増えたり、評価がブレたりしやすいです。商品名・用途・数量・単価を淡々と書く。これだけでも通関の摩擦が減ることがありますよ。

同梱consignmentの判定

「1商品が安いから大丈夫」と思いがちですが、IOSSは基本的に1梱包(consignment)単位で見られます。つまり、同じ注文でも同梱でまとめた結果、合算で150ユーロを超える可能性があります。これが本当にややこしくて、出品者の“善意の同梱”が、結果的にIOSSの条件を外す引き金になることもあるんですよ。

同梱の何が危ないのか

同梱自体が悪いわけではないです。ただ、150ユーロに近い注文で同梱すると、合算で超えてしまって輸入時課税に寄る。さらに、配送会社の扱いで「同じ差出人・同日・同宛先だからまとめて見られた」みたいなケースが疑われることもあります。私の体感としては、同梱ミスより「同梱した結果、申告の見え方が変わって税関が迷う」パターンが多いです。

私が運用で意識しているのは、以下の2点です。

  • 150ユーロ付近の注文は、同梱・分割の判断を慎重にする
  • 商品価格と送料の見せ方が固有価値の誤解につながらないようにする

分割発送は万能じゃない

「じゃあ分割すればOKじゃん」と思うかもですが、分割にも注意点があります。たとえば、分割したせいで送料が二重にかかって購入者の不満が増えることもありますし、配送会社側で申告が重複しやすくなることもあります。さらに、分割したつもりでもラベル作成やマニフェストの運用が雑だと、税関側の見え方が変わらず疑われる可能性もゼロではないです。

補足:私が迷ったときは「この荷物、税関が見たら一発で理解できる?」を自問します。迷う要素(曖昧な品名、合算で150超えそう、送料込み表示で見え方が悪い)があるなら、梱包と申告の設計を見直す方が早いです。

そして、配送会社側のシステム都合で「まとめ申告」っぽく処理されるケースもあるので、出荷前に送り状作成画面や申告項目の入力単位を確認しておくと安心です。ここができると、購入者から「税関で止まった」「追加で請求が来た」って言われても、冷静に原因を潰せますよ。

deemed supplierとみなし供給

AmazonIOSSVATを理解するうえで大事なのが、マーケットプレイス課税の考え方です。一定条件下では、マーケットプレイス(電子的インターフェース)がVAT上「売り手(みなし供給者)」として扱われます。これがいわゆるdeemed supplier(みなし供給者)で、AmazonがVATを徴収する背景になっています。

なぜAmazonがVATを取ってくるのか

出品者としては「いや、売ってるの私なんだけど?」ってなりますよね。でもEUのルール設計としては、消費者への通販で税の取りっぱぐれを防ぐために、プラットフォーム側に責任を寄せる場面があるんです。だから、EU域外からEU消費者へ、150ユーロ以下の輸入販売を“促進”するようなケースでは、AmazonがVATを徴収してきます。

で、ここで勘違いしやすいのが、「AmazonがVATを取った=全部終わり」です。現実は、通関側にIOSS情報が正しく伝わって初めて輸入時VATが回避されるという構造です。Amazonが徴収しても、配送会社が税関申告のデータにIOSS情報を載せない(または載せられていない)と、税関は「普通の輸入」だと認識してVATを請求しにいきます。

出品者の役割は「税金の計算」より「情報の橋渡し」

私が実務で強く感じるのは、出品者がやるべきことは税率を暗記することじゃなくて、Amazonが徴収したVATに紐づくIOSS情報を、配送会社・通関の流れに落とすことです。要するに橋渡し役ですね。

現場での合言葉:deemed supplierだからこそ、税金の“徴収者”と“発送者”が分かれやすい。だから、情報連携がズレると事故になる

この視点を持っておくと、購入者から「二重請求された」と言われたときも、感情に引っ張られず「対象外だった?」「IOSSデータが乗ってない?」のどっちかに切り分けできます。クレーム対応の精神衛生がだいぶ良くなりますよ。

OSSとIOSSの違い

名前が似ていて混乱しますが、OSSは主にEU域内取引のVAT申告をまとめる仕組みで、IOSSはEU域外からの小口輸入(原則150ユーロ以下)のB2Cに寄せた仕組みです。つまり、あなたが日本からEUへ直送する現場で関わるのは、基本的にIOSS側の話が中心になります。

22ユーロ免税廃止の影響

さらにややこしいのが、EUでは2021年以降、22ユーロ以下の輸入VAT免税が廃止されて、低額でもVATがかかる前提になったこと。だからこそIOSSが重要になって、AmazonIOSSVATのトラブルも目立つようになった、という流れです。安い商品を売ってるほど「税金なんて関係ないでしょ」と思いがちなんですが、EUはそこが逆で、安いほどIOSSの話が刺さってきます。

UKは別ルールで動くことがある

あと、UKが絡むと話がさらにズレやすいです。IOSSはEUの仕組みなので、UK向けはUK VAT側の基準(£135など)で見られることが多く、EUと同じテンプレで考えると混乱します。UKのVAT登録番号(VRN)やHMRCの話まで踏み込むなら、サイト内のUK記事も参考になると思います。amazonイギリスVRNとは?VAT登録番号の必要条件と取得手順まとめは、UK特有の論点を整理しています。

補足:EU向けでも、B2B宛や条件外(150ユーロ超、対象外品)だとIOSS前提では動きません。相手が事業者か個人かで、必要情報がガラッと変わることがあります。

私のおすすめは、まず「宛先がEUかUKか」を最初に分けること。次に「B2CかB2Bか」。最後に「150ユーロ基準と品目条件」。この順番でチェックするだけで、見当違いの対応が減ってラクになりますよ。

AmazonIOSSVATの実務対応

ここからは出品者目線で「何を確認して、何を配送会社に渡せばいいか」を具体化します。購入者からクレームが来たときの切り分けにも直結するので、テンプレ化しておくと強いです。

私は「発送前チェック」と「トラブル発生時チェック」を分けて運用しています。発送前に7割潰せるので、後半でその型も紹介しますね。

注文詳細でIOSS番号確認

まずは「その注文がAmazon側でVAT徴収されているか」を確認します。ここがズレると、いくらIOSSの話をしても噛み合いません。購入者がVATを払っていない注文で「二重課税だ!」と言われることもありますし、逆に払っているのにIOSS番号が通っていないケースもあります。だから最初に“事実確認”を固めます。

私が見る順番(テンプレ)

私のおすすめは、注文ごとに次の順で見ることです。難しいことはなくて、チェックリストで機械的に潰す感じです。

  • 注文詳細でVAT徴収の表示があるか
  • EU向けB2Cで、非EU在庫から直送になっているか
  • 150ユーロの境界を超えていないか(同梱含む)

IOSS番号が「出ない」ケースもありますが、その場合は対象外注文である可能性が高いです。逆に対象のはずなのに表示が揺れるなら、出荷方法やストア、ツール連携の仕様も疑います。たとえば、同じ商品でも発送元(在庫所在地)や宛先の国によって、IOSSの対象になったりならなかったりすることがあります。

注文詳細で確認できたら、次は“渡す準備”

ここで終わりにしないのが大事です。確認できたら、その番号が「配送会社に渡る形」になっているかを整えます。私はメモとして、注文ID・商品価格(VAT抜きの考え方を含む)・IOSS番号(表示されているなら)をセットで残しています。後で問い合わせが来たときに、探す時間がゼロになるので楽です。

注意:購入者にIOSS番号をそのまま渡して「これ見せて」とやるのは、ケースによっては揉めます。相手の国・配送会社のオペレーションで必要な提示物が変わるので、まずは請求の内訳(VATか手数料か)を確認してから動く方が安全です。

もし税関で止まったり、購入者が受取拒否しそうだったりするなら、「輸入取止め」系のパターンも視野に入ります。国際発送の止まり方はVATだけじゃないので、困ったとき用にこの記事も置いておきます。国際郵便の輸入取止めとは?原因と対処を徹底解説

SP-APIのIossNumber取得

自社の出荷管理をツール化している人は、SP-APIでの取得が現実的です。注文アイテムにIossNumberが返る設計になっているため、「AmazonがVATを徴収した注文=IOSS番号を配送会社へ渡す」という流れをシステムに組み込みやすいです。私も、手作業でコピペしているとミスが出るので、できる範囲で自動化に寄せる派です。

番号だけ取っても事故る理由

私が実装・運用で意識しているのは、番号だけで完結させないことです。通関側は照合ができないと意味がないので、IOSS番号と合わせて注文IDなどの参照情報も一緒に持たせます。これがあると、配送会社に問い合わせるときも「IOSS番号はこれ、注文参照はこれ」と一発で話が通ります。

配送会社に渡す情報の考え方

配送会社や契約形態で要求はブレますが、最低限セットで揃えたいのはこのあたりです。

  • IOSSのVAT識別番号(Amazon提供)
  • 固有価値(intrinsic value)としての物品価格
  • 注文IDや参照番号(突合用)

私はこれを「税関向け3点セット」って呼んでます。これを揃えておくと、購入者から「受取時にVAT請求された」と来ても、原因が「対象外」なのか「連携漏れ」なのかの切り分けが早いです。

データ 目的 ないと起きがち
IOSS番号 輸入時VAT免除の根拠 輸入時VATが請求されやすい
注文ID/参照 税関・配送会社の突合 「どの取引?」で時間が溶ける
物品価格 150ユーロ判定の基礎 税関評価がブレて超過扱いのリスク

ポイント:APIで取れるものは取って、出荷データに紐づけておくと、あとからの説明コストが激減します。

もちろん、SP-APIや連携ツールはバージョンや仕様変更で挙動が変わることもあります。だから、導入後は「テスト注文でIossNumberが取れているか」「配送ラベル作成時に反映できているか」を必ず確認してください。ここをサボると、運用開始直後に事故ります。

配送ラベルと電子送信

地味に多いのが「IOSSラベルが表示されない=失敗」って思い込むパターンです。これ、めちゃくちゃ分かります。私も最初はラベルに何か印字されていないと不安でした。でも現実は、DHLなどではIOSS番号をラベルやインボイスに印字せず、申告データとして電子送信(electronic transmission)で税関に渡す運用があり得ます。つまり、目で見える場所に出なくても、裏で通っていることがあるんですよ。

私がチェックする2点(印字より大事)

なので、私がチェックしているのは「印字されているか」よりも、次の2点です。

  • 送り状作成時の電子申告項目にIOSS関連の入力があるか
  • 出荷データ(CSVやAPI連携)にIOSS番号が載っているか

この2点が揃っていれば、ラベルに印字されていなくても「申告データに乗っている可能性が高い」と判断できます。逆に、ここが空欄なら、ラベルに何か印字されていても不安です(結局税関に届くのはデータ側なので)。

注意:配送会社の画面で「IOSS」と書いていなくても、別の項目名(税番号、参照番号、VAT関連フィールドなど)に入るケースがあります。契約プランや国別テンプレでUIが違うこともあるので、最終的には配送会社の要件に合わせてください。

問い合わせするときの言い方(テンプレ)

配送会社のサポートに問い合わせるときも、「ラベルに印字されていません」より「税関申告データにIOSSが送信されているか」を聞く方が話が早いです。私はだいたい、次の情報をまとめて投げます。

  • 追跡番号
  • 出荷日
  • 宛先国
  • 注文参照(注文IDなど)
  • IOSS番号(分かる範囲で)

これだけ出すと、相手も「調べる材料」が揃うので、無駄な往復が減りますよ。

VAT二重課税と通関手数料

購入者からの相談で一番多いのが、いわゆるVAT二重課税です。ただ、実際には「VAT」じゃなくて通関手数料(立替手数料)だけが請求されているケースもあり、ここを混同しがちです。ここ、気になりますよね。私も購入者に説明する時、まずここを分けないと話が進まないと痛感しました。

切り分けのコツ:請求書の内訳にVAT(税)と手数料が分かれているかを見る。手数料だけなら「二重課税」ではなく、立替業務のコストの可能性があります。

二重に見える典型パターン

  • IOSS対象外(150ユーロ超、B2B、対象外品)で輸入時課税が発生
  • IOSS対象なのに申告データにIOSS番号が載っていない/紐づいていない
  • 税関側で価格評価が修正され、150ユーロ超と判断された

この中で一番多いのは、体感では「対象外だった」か「IOSS情報が乗ってない」です。価格評価修正は頻度としては少ないですが、発生すると説明が大変です。なぜなら「税関がそう判断した」で強制力があるので、出品者側で覆しにくいんですよね。

出品者としての現実的な動き方

出品者としてできる現実的な対処は、「対象外なら対象外で説明できる材料を揃える」「対象のはずならIOSS情報の連携を再確認する」の2択です。私がやる順番はこうです。

  • 請求がVATなのか、手数料なのかを確認する
  • 注文がIOSS対象条件を満たしていたかを再確認する(150ユーロ、B2C、品目)
  • 配送会社にIOSSが送信されていたか(データ)を確認する

購入者が還付や返金を狙うなら、注文詳細の課税情報、配送伝票、通関時の請求明細など、証拠になりそうなものを保全してもらうのが基本かなと思います。ここで雑に「返金します」って言うと、あなたが全部かぶる形になって危ないので、まずは事実確認が先です。

国・地域差の注意点

フランス向けは、EU域外在庫から個人宛で150ユーロ超の販売が制限されるような運用が入ることがあり、他国と同じ感覚でやるとハマります。UK向けもIOSSではなくUK VATの別ルール(£135など)が絡むので、同じテンプレで捌かない方が安全です。

B2B寄りの発送や通関主体が変わるケースではEORIが論点になることもあるので、ここは配送会社・通関業者に寄せて確認してください。私はこの手の話に踏み込みすぎると沼るので、「誰が通関主体か」「誰に請求が行く設計か」だけ先に確認して、あとはプロに寄せることが多いです。

大事な一言:金額や税の扱いはケースで変わるので、この記事の内容はあくまで一般的な目安です。正確な結論は、各国当局や配送会社、通関業者、税務専門家の案内を優先してください。

AmazonIOSSVATとIOSS番号総括

最後にまとめです。AmazonIOSSVATでつまずく原因は、だいたい「IOSS対象の条件」と「通関データへの反映」のどちらかに寄っています。ここを分けて考えられるようになると、購入者対応も、発送フローも、一気に安定します。

私の“結論チェック”はこの3つ

  • 対象条件:B2C、固有価値150ユーロ以下(1梱包単位)、対象外品でない
  • 実務:AmazonがVATを徴収しているなら、IOSS番号を配送会社へ渡し、税関申告データに乗せる
  • 切り分け:二重課税に見えても、VATではなく通関手数料だけのことがある

そして、よくある誤解もここで潰しておきます。IOSSラベルの印字がなくても、電子送信で成立することがある。逆に、見た目に印字があっても、申告データが送れていなければ意味が薄い。ここは「目に見えるもの」より「税関に届くデータ」が正義です。

実務の型(私がやってるやつ)

  • 発送前:注文がIOSS対象か確認 → IOSS番号・注文参照・物品価格の3点セットを出荷データに保存
  • 発送時:配送会社の電子申告項目にIOSSが入っているか確認(印字は参考程度)
  • トラブル時:請求内訳(VAT/手数料)→ 対象条件 → データ送信の順で潰す

さらに、制度や運用は今後も変わる可能性があります。たとえば、しきい値や通関の仕組みがアップデートされると、今日うまくいっている運用が、来年そのまま通るとは限りません。だからこそ、公式情報を定期的に確認しつつ、配送会社の要件に合わせて運用を更新するのが一番安全です。

この記事は一般的な整理なので、最終的な判断は配送会社・通関業者・税務の専門家に確認してください。あなたの現場に当てはめるときは、「この注文は対象か」「申告データにIOSSが乗っているか」を軸に見ていけば、かなり迷いが減ると思いますよ。

コメント

タイトルとURLをコピーしました