米国向けにEC・卸売・SaaS・デジタル商品を販売する日本企業にとって、売上税（Sales Tax）は「税率を調べれば終わる論点」ではありません。全米共通の売上税は存在せず、課税の有無・課税範囲・登録義務の発生条件がすべて州単位で決まるためです。さらに2018年のSouth Dakota v. Wayfair判決以降、米国内に拠点を持たない事業者にも徴収義務が及ぶ枠組みが定着しました。本記事では、制度の基本構造、ネクサス判定、マーケットプレイス対応、登録・申告実務までを、実務で使える順序に整理します。
米国Sales Taxの基本構造｜「全米共通の売上税」は存在しない
米国の売上税は州法に基づく制度であり、州ごとに税率・課税ベース・免税要件が独立しています。日本の消費税のように単一の制度を前提に設計すると、初期段階で判断を誤る可能性があります。
州税と地方税の二層構造
一般売上税を課す州の多くは、州率に加えて市・郡・特別区（special district）の地方税が上乗せされます。したがって実際の適用税率は、州率ではなく配送先住所ごとの合算税率で決まります。地方税の階層が複雑な州では、郵便番号単位の判定では不十分となり、ストリートレベルの住所検証が求められる場面があります。
一方で、州全体の一般売上税を持たない州も存在します。ただし「州税がない＝完全に非課税」とは限らず、自治体レベルで地方売上税が課される例があるため、システム上で一律0%と固定するのは危険です。
名称が異なる取引税（TPT・GET・GRT）
「Sales Tax」という名称だけを検索すると見落としが生じます。州によっては Transaction Privilege Tax（TPT）、General Excise Tax（GET）、Gross Receipts Tax（GRT）といった別名称・別構造の税が、実務上は売上税エンジンで管理すべき対象になります。これらは課税ベースが一般的な売上税より広く、B2Bサービスを含む取引が課税範囲に入る場合があるため、通常の売上税と同一のロジックで処理しないことが重要です。
ネクサス（Nexus）判定｜Wayfair判決以降に何が変わったか
ネクサスとは、州が事業者に徴収・納税義務を課せるだけの結び付きを指します。ここを誤ると、税率設定がどれほど正確でも義務違反になります。
フィジカル・ネクサス（物理的な結び付き）
Wayfair判決は物理的接点の概念を廃止したのではなく、「物理的接点がなければ課税できない」という排他的ルールを覆したものです。したがって現在も、州内の在庫・倉庫・オフィス・従業員・請負業者・展示会出展・設置修理対応などがあれば、売上規模にかかわらず登録義務を検討する必要があります。FBA等のフルフィルメント在庫が州内倉庫に置かれることで、この物理的接点が成立する可能性がある点は特に見落とされやすい論点です。
エコノミック・ネクサス（売上高・取引件数基準）
現在、一般売上税を課すすべての州が、州外事業者に対する経済的基準を設けています。多くの州は年間10万ドル前後を基準としますが、より高い金額基準を採用する州、金額と取引件数の両方を満たす必要がある州など、例外的な設計も存在します。加えて、基準の分母が「gross sales」「retail sales」「taxable sales」のいずれかによって判定結果が変わり得るため、共通ロジックで一括処理するのではなく州別に定義を保持すべきです。
取引件数200件基準は縮小傾向にある
近年、取引件数基準を廃止し金額基準のみに一本化する州が続いています。少額の消費者向け取引を大量に扱う事業者にとっては負担軽減となる一方、依然として件数基準を維持する州も残っているため、「件数判定は不要になった」と全社的に断じることはできません。廃止済みの州について古いERP設定が残っていると、不要な登録・申告を続けてしまう可能性があります。
マーケットプレイス徴収と販売者責任の切り分け
Amazonなどのマーケットプレイス事業者が販売者に代わって税を徴収・納付する制度は広く導入されています。ただし、これで販売者側の管理が完結するわけではありません。
実務上は、次の三つを別々の問いとして扱う必要があります。第一に、プラットフォームが税を徴収するか。第二に、そのマーケットプレイス売上をエコノミック・ネクサスの判定額に含めるか。第三に、販売者自身に州登録や申告（売上ゼロの場合を含む）が求められるか。これらは州ごとに答えが異なり、自社EC・展示会・電話注文といった直販チャネルの徴収義務は販売者に残ります。プラットフォームが納税している州について自社EC分まで除外すると、徴収不足につながる可能性があります。
商品・サービスの課税判定（Taxability）
有形資産は原則課税とする州が多い一方、サービスの扱いは州差が非常に大きい領域です。「サービスだから非課税」と推定することは避けるべきです。
実務では、ソフトウェアライセンス、SaaS、データ処理、情報サービス、広告、修理・保守、設置、人材派遣、デジタル商品などを州別の課税コードに分解し、契約書・請求書の記載と一致させます。請求書に「Consulting Services」とだけ記載していると、監査時に非課税判断の根拠を示しにくくなります。近年はサービスへの課税範囲を拡大する州の動きも見られるため、改正の発効日付きで課税マトリクスを更新する運用が必要です。
登録・申告・免税証明書の実務対応
三層の登録戦略
すべての州に一律登録するのは合理的ではありません。登録後は売上がゼロでも申告が求められる州が多く、期限を過ぎれば税額ゼロでも通知を受ける可能性があるためです。実務的には、①物理的ネクサスが確定した州、②経済基準を超過した州、③基準の6〜8割に接近している監視対象州、という三層で管理する方法が扱いやすくなります。加えて、Streamlined Sales Tax加盟州については共通の登録システムを利用できますが、申告自体は各州へ行う点に留意します。
ERP・ECシステムに保持すべきデータ
取引単位で、配送先住所、請求先、商品・サービスコード、課税区分、免税ステータス、マーケットプレイス区分、出荷元、請求日、金額、送料、徴収税額、管轄IDを保持することが望まれます。住所精度は単なるIT品質の問題ではなく、税務統制上の論点です。
免税証明書の取得と保管
再販売や製造用途の免税は、顧客の口頭申告では足りません。証明書の様式や受理要件は州によって異なり、監査時に不備があると販売者が税を負担する結果になり得ます。免税証明書は販売時点で取得し、有効期限・対象品目まで含めて一元管理するのが安全です。
申告頻度と照合
申告頻度は州が売上額や税額に応じて指定し、途中で変更されることもあります。一般的な目安は計画段階では有用ですが、最終的に従うべきは各州から自社に通知された頻度です。月次では、ERPの徴収税額、税計算エンジン、マーケットプレイス報告、州申告、総勘定元帳の売上税負債を突合します。
監査対応とリスクの優先順位
監査で問題化しやすいのは、税率の誤りよりも「なぜ非課税と判断したか」「なぜその州で登録しなかったか」を説明できないことです。ネクサス判定メモと課税判定メモを毎年日付入りで残し、証憑を同一のリポジトリで紐付けておくことが有効です。
リスクの確認順序としては、未登録の物理的ネクサス、経済基準超過後の未登録、課税対象サービスの非課税処理、地方税率・課税地判定の誤り、免税証明書の欠落、マーケットプレイス照合差異、申告漏れ、という優先順位が合理的です。未登録期間が複数年に及ぶ場合は、通常登録を行う前に自主開示制度（VDA）の利用可能性を検討する余地があります。州から既に接触を受けていないことなどの適格要件があるため、社名を開示する前に専門家に相談することが望まれます。
まとめ
米国のSales Taxは、単一の税率表で管理できる制度ではありません。実務の要点は、①物理的ネクサス、②経済基準、③マーケットプレイス売上の扱い、④商品・サービスの課税判定、⑤配送先ベースの税率、⑥免税証明書、⑦申告頻度、⑧改正の発効日、という項目を州別のマスターデータとして保持し、継続的に更新することにあります。
Wayfair判決以降のコンプライアンスは、税率計算の問題からデータとプロセスの管理問題へと移行しました。まず着手すべきは、直近の米国売上を「州×チャネル×売上区分×取引件数」で再集計し、物理的ネクサスの棚卸しを行うことです。そのうえで、近年に制度変更があった州のシステム設定を優先的に見直すことで、登録漏れと過剰登録の双方を抑えられる可能性があります。
