Nordlet

← ブログ

国別のVAT（付加価値税）申告とVIES検証の自動化

クラウド会計APIを活用し、マーケットプレイスやプラットフォームにEU VATコンプライアンスを組み込むための開発者向け実践ガイド。

Nordlet Team · · 1 分で読める

プラットフォームのコードにおけるVATの不具合のほとんどは、ある1つの前提に起因しています。それは、VIESの検証結果が有効であれば売上を税率ゼロ（zero-rate）にできるという思い込みです。実際にはそうではなく、この安易な手法に基づいて構築された申告書は、監査人が「なぜ輸送証明や一貫した供給地（place-of-supply）の記録がないままEU域内免税が適用されたのか」と問いただすまでは問題なく見えてしまいます。「VAT番号の確認が取れた」状態と「この供給が正しく処理されている」状態の間のギャップこそが、大半の連携処理が知らず知らずのうちに破綻する原因です。

本ガイドでは、Nordletの会計 APIを実装の文脈として使い、クラウド会計APIによる国別VAT申告およびVIES検証の自動化手順を解説します。目指すのは、販売時に適切な証拠（evidence）をキャプチャし、改ざん不能な仕訳（immutable ledger entries）を計上し、後からスプレッドシートで合計値を再計算しなくても、スキームおよび加盟国（Member State）ごとにグループ化された申告用データを生成できるシステムの構築です。

VIESが実際に示すもの、示さないもの

VIESは、EUのVAT情報交換システム（EU VAT Information Exchange System）です。国コードとVAT番号を送信すると、関連する国家データベースをリアルタイムで照会し、そのVAT情報が有効（valid）か無効（invalid）かを返します。これが機能のすべてです。番号が登録されていること、および対応している加盟国についてはEU域内取引に対して有効化されていることを確認します。

これは、EU域内供給（intra-Community supply）を免税する権利を確立するものではありません。欧州委員会（European Commission）はこの点を明確に示しています。有効なVIESのレスポンスは、複数の証拠のうちの1つに過ぎません。顧客が実際の受取人であること、供給がEU域内の要件を満たしていること、輸送または発送の証拠が存在すること、そして請求書に必要なリバースチャージ（reverse-charge）の文言が記載されていることを、引き続き確認する必要があります。

したがって、最初の設計上の決定は構造的なものです。すなわち、VIESのステータスとVATの処理（VAT treatment）を別々のフィールドに保持することです。viesStatus: valid を zeroRated: true に直接配線しては絶対にいけません。これら2つの概念を結合した瞬間、証拠が問題視された際にその処理を正当化する能力を失ってしまいます。

連携コードを書く前の前提条件

APIエンドポイントを呼び出す前に、何を申告対象とするのかそのスコープを定義します。この作業は地味ですが、省略すると後で大きな代償を払うことになります。

  • 事業者が拠点、または固定施設（fixed establishment）を有している国
  • VAT登録を保持している国
  • 販売するのが物品、サービス、デジタルサービス、あるいはそれらの混合であるか
  • 取引がB2B、B2C、あるいはその両方であるか
  • 国内登録、OSS（ワンストップショップ）、IOSS（輸入ワンストップショップ）、リバースチャージ、またはマーケットプレイスの擬似仕入先（deemed-supplier）規則のいずれを使用しているか
  • APIが出力しなければならない成果物：国内申告データ、OSS/IOSSデータ、リトアニアのi.SAFのような請求書台帳（invoice registers）、仕訳の記録のみ、あるいは別個の申告プロバイダ向けのペイロード

OSSがすべての取引を網羅するわけではないため、この点極めて重要です。事業者が拠点を持つ国で提供されるサービスは、通常、OSS申告ではなく、その国の国内申告の対象となります。最初から拠点を個別にモデル化しておかないと、集計時にそれらの供給のルーティングを誤ることになります。

また、国ごとに1つのVAT税率をハードコーディングすることも避けてください。EUには標準税率、軽減税率、超軽減税率、パーキング税率、税率ゼロ、および製品固有の処理があり、これらは変更されます。特定加盟国における特定の製品に対する信頼できる情報源はその国の税務当局であり、欧州委員会のTEDBが国をまたいだ概要を提供しています。後から税率表が更新された際に古い取引の表示方法が密かに書き換わらないよう、各税率の決定の裏にある情報源とバージョンを記録してください。

単なる税率ではなく、税務上の決定をモデル化する

堅牢な連携の中核となるのは、商品と税率の間に位置する税カテゴリ（tax category）層です。商品をカテゴリにマッピングし、カテゴリを国別の税コードにマッピングした上で、適用開始日（effective-dated）を持つ税率に紐付けます。

product/service
    → tax category
    → country-specific tax code
    → effective-dated rate and treatment

申告のズレを引き起こす危険なアプローチは、product SKU → 21% VAT のようなものです。同一の商品であっても国によって異なる税率が適用され、期中に税率が変更されることもあります。Nordlet自身のVATコンプライアンスガイドでも、商品をパーセンテージに直接バインドするのではなく、まさにこのようなカテゴリベースのマッピングを推奨しています。

税カテゴリの体系は、安定した内部のものにする必要があります：標準税率物品、軽減税率物品、電子的に提供されるサービス、一般サービス、非課税供給、税率ゼロ供給、EU域内B2Bリバースチャージ、EU域内遠隔販売、IOSS輸入、擬似仕入先（deemed-supplier）取引。下流の処理はすべてこの体系を基準に動作します。

非同期の証拠ワークフローとしてのVIES検証

公式のVIESサービスは、2文字の国コードとVAT番号を受け取るSOAP/WSDLインターフェースを公開しています。ドキュメント化されているその障害要因は、エラーハンドリングにおいて重要となります：無効な入力、グローバルおよび加盟国の同時リクエスト制限、サービスの利用不可、加盟国の利用不可、およびタイムアウト。これらを単なる「失敗」のバケットとしてまとめるのではなく、別個の結果として扱ってください。

負荷と監査に耐えるワークフローは次のように構成されます。

  1. VAT IDの正規化：プレフィックスを大文字にし、許可されているスペースや句読点を除外し、ユーザーが入力した元の値は別途保持する。
  2. ネットワーク呼び出しを行う前に、国コードと番号の形式をローカルで検証する。
  3. 正規化した番号をVIESに送信する。
  4. 正規化されたID、リクエストおよびレスポンスのタイムスタンプ、有効（valid）/無効（invalid）/未処理（not-processed）の状態、生のレスポンス、サービスエラー、顧客および請求書のID、そしてアプリケーションとしての判断結果を保存する。
  5. 検証に成功した結果は、定義され文書化された期間キャッシュする。
  6. 一時的な技術的障害については、バックオフ（指数バックオフなど）を伴って再試行する。
  7. 未解決または矛盾するケースは手動レビューにルーティングする。
  8. キャッシュされた結果が古くなっている場合、または証拠が重要な取引の前に、再検証を行う。

Nordletは、顧客の追加時にEU VAT番号を確認し、以前の結果が古くなっている場合には請求書発行の前に再確認を行います。この動作は、プラットフォーム上で実行するか、独自のコードで実行するかに関わらず、再現すべき挙動です。

重要なルールとして、チェックアウトプロセスをVIESと同期させてはなりません。サービスの停止は、番号が無効であることを意味しません。セール中にVIESがタイムアウトした場合は、取引をレビュー保留にするか、暫定状態（provisional state）を割り当ててください。欧州委員会のサービスの稼働状況にチェックアウトを依存させるとサポートチケットが大量発生することになり、優良な顧客を誤って無効と判定するほうがはるかに悪影響を及ぼします。

検証ステータスと処理（treatment）の分離

VIESの結果を取得したら、決定エンジン（decision engine）にはさらに行うべき処理があります。これらを別々のフィールドとして保存します。

{
  "viesStatus": "valid",
  "vatTreatment": "intra_eu_b2b_reverse_charge",
  "evidenceStatus": "reviewed",
  "placeOfSupply": "DE"
}

リバースチャージや免税を適用する前に、エンジンは次の項目をテストする必要があります：顧客が真の受取人であるか、顧客の国とVATプレフィックスが一貫しているか、供給がEU域内の要件を満たしているか、特別な供給地規則が適用されるか、輸送の証拠が存在するか、売り手が擬似仕入先（deemed-supplier）として行動しているか、請求書に必要な文言が含まれているか。これら他のテストのいずれも通過しない有効なVIESステータスは、ゴーサインではありません。

請求書発行時における変更不能なVAT決定の作成

請求書を作成する際には、最終的な税率だけでなく、すべての判断内容を請求書と紐付けて永続化します。

invoice
  ├─ line tax category
  ├─ place of supply
  ├─ VAT scheme
  ├─ country-specific rate
  ├─ rate-table version
  ├─ VIES evidence reference
  ├─ location-evidence references
  ├─ legal-basis reference
  └─ marketplace-role flags

EUの請求書ルールでは、供給者および顧客の詳細、請求書番号、説明、課税対象金額、VAT税率、VAT金額、ならびにリバースチャージや免税に関する情報の記載が義務付けられています。クレジットノートや修正には、元の請求書への曖昧さのない参照が必要です。

Nordletの台帳は変更不能（immutable）であるため、修正は閉じたレコードの直接編集ではなく、クレジットノートや逆仕訳（reversing entries）といった新しいエントリを通じて行われます。ストレージの技術的仕様上は上書きが可能であったとしても、このモデルに沿ってシステムを構築してください。閉じられた請求書を編集してしまうと、元の申告と修正の間のリンクが破壊されてしまいます。これこそまさに、監査人が追跡する血統（lineage）そのものです。

投稿（Posting）、Webhook、および冪等性（Idempotency）

販売が発生すると、商業取引と、国およびスキームごとに分割されたVAT負債の両方を保持する複式簿記の仕訳が投稿されます。国内販売の場合は次のようになります。

Dr Accounts receivable / payment clearing
    Cr Revenue
    Cr VAT payable - DE - domestic

EU域内B2Bリバースチャージの販売では、売上高（出力VATなし）とリバースチャージの証拠への参照が計上されます。正確な勘定科目体系は各システム独自のもので構いませんが、重要なのは、加盟国、スキーム、税カテゴリ、税率、期間、元請求書、修正の血統といった報告用ディメンション（dimensions）がすべての投稿に常時添付されていることです。

ポーリングではなくWebhookによって状態変更を駆動します。Nordletは sale_invoice.paid のようなイベントを発行し、配信に署名し、バックオフを伴うリトライを行います。すべての書き込み操作に決定論的な冪等性キー（idempotency key）を付与してください。

sale:{platform_order_id}:invoice:{invoice_version}

コンシューマー側も冪等性を備えている必要があります。Webhookは2回届くことも、遅れて届くことも、元のリクエストがすでに成功した後に発火することもあります。署名の検証、イベントIDの記録、不正な形式のイベントの隔離、耐久性のあるキューを通じた処理、およびスケジュールに沿ったAPIとのWebhook状態の照合を行ってください。もしこれまでに署名付きWebhookと冪等性キーを扱ったことがない場合、ここに最も巧妙な重複計上のバグが潜んでいます。

OSS向けのグループ化と申告用エクスポートの生成

対象となるOSS取引については、スキーム、消費加盟国、供給タイプ、税率カテゴリ、税率、課税対象金額、VAT金額、発送または拠点の加盟国、通貨、および修正期間ごとに台帳データをグループ化します。

Unionスキームの申告では、消費加盟国ごとに供給を分離し、識別加盟国からのサービス、他の固定施設からのサービス、および異なる加盟国から発送された物品を区別します。標準税率と軽減税率について、課税対象金額とVAT金額を別々に報告します。非課税および税率ゼロの供給は、OSS申告から完全に除外されます。

運用上のいくつかの注意点：

  • Unionおよび非UnionのOSS期間は四半期ごとであり、IOSSは月ごとです。申告と支払いは翌月末までに行う必要があります。
  • 該当する供給が行われなかった期間であっても、すべての期間でゼロ申告（nil return）が必須となります。期間ごとのチェックリストを作成し、ゼロ値の申告書を自動生成してください。
  • OSSの申告はユーロ建てで行われ、換算が必要な場合は課税期間の最終日の欧州中央銀行（ECB）基準レートを使用します。原通貨、為替レート、レート適用日、換算後の金額、およびその方法を保存してください。

エクスポートは、サイドスプレッドシートからではなく、必ずロックされた台帳から行う必要があります。スプレッドシートの合計値は、修正、発送国、税率、証拠を欠落させます。エクスポートには、申告期間、スキーム、消費加盟国、発送国、供給カテゴリ、税率、課税対象金額およびVAT金額、通貨と適用された為替レート、当期および前期の修正金額、元請求書ID、クレジットノートの参照、ならびに照合用の合計値を含める必要があります。

APIがここで提供するものについて正確に把握してください。Nordletは、請求書と前期の修正を含む台帳からOSSおよびIOSSの申告データを計算し、リトアニア（FR0600）、ドイツ（UStVA）、ポーランド（JPK_V7M）の国内申告パックを出荷し、リトアニア向けのVMI対応i.SAF台帳を生成します。これが申告用データです。1回のAPIコールであらゆる国のVAT申告を各国の国家ゲートウェイ経由で自動的に提出してくれるわけではなく、いかなる申告も税務当局に対してユーザーの代わりに提出されることはありません。会計、申告書の生成、エクスポート、ゲートウェイへの提出、および支払い確認は、1回の呼び出しですべてが完了すると仮定せず、システム内で別々の状態として扱ってください。EU VATエンジンガイドには、エンジンが解決するケースと警告が発生する条件が文書化されています。

期間のロック

レビューと承認の後、請求書と仕訳の照合、台帳のVAT残高と申告データセットの照合、申告書のエクスポート、申告および支払い参照の記録を行い、その後期間をロックします。Nordletは、API経由を含め、ロックされた月への新規投稿をブロックします。ロック後の修正は、元のドキュメントおよび影響を受ける申告期間への明示的なリンクを持つ、後続の期間で行われます。

よくある障害モードとその回避策

障害モード 原因 対策
有効なVIES結果を税率ゼロ適用の十分な条件として扱う VIESは免税権利を確立するものではない 結果と一緒に、顧客、供給、輸送、および請求書の証拠を保存する
無効な結果を「登録なし」の証明として扱う EU域内取引に対して番号が有効化されていないか、データベースが遅延している可能性がある 無効、未処理、技術的障害を区別し、紛争はレビューにルーティングする
チェックアウトをVIESと同期させる 同時接続制限、タイムアウト、障害 非同期検証、短期キャッシュ、バックオフ、暫定状態の活用
結果を永久にキャッシュする 登録および有効化のステータスは変化する タイムスタンプと有効期限を保存し、古い場合は請求書発行前に再確認する
商品をVATパーセンテージに直接マッピングする 税率や免税は国と日付に依存する 商品からカテゴリ、国コード、適用日付き税率へとマッピングする
スプレッドシートからOSSを再構築する 合計値から修正、発送国、証拠が欠落する すべてのエントリにディメンションを持つ、変更不能な台帳から導出する
国内拠点のサービスをOSSに含める 特定のサービスは国内申告に属する 拠点を個別にモデル化し、集計前にスキームでルーティングする
ゼロ申告（nil return）を省略する OSSは毎期の申告を義務付けている チェックリストを作成し、ゼロ値申告を自動生成する
修正のためにクローズされた請求書を編集する 申告と修正のリンクが破壊される 後続の期間でクレジットノートや逆仕訳を使用する

最初に行うべきこと

明日この連携を開始するとしたら、reportingエンドポイントに触れる前に、まず税カテゴリ層とVAT決定のレコードを構築します。体系を安定させ、商品をカテゴリにマッピングし、生の国のシグナルと供給地が選択された理由を捉える決定レコードを確立させます。VIES、投稿、OSSグループ化、エクスポートなど、その他すべての要素は、このモデルが正しいかどうかに依存しています。

その上で、VIESを4つの状態に分離された非同期の証拠取得ステップとして配線し、プロダクション環境に近づける前に、厄介なケース（タイムアウト、未処理の結果、プレフィックスの不一致）のフィクスチャを備えたサンドボックス企業環境に対してテストを実行します。上記の障害モードは、データモデルが最初の投稿時から証拠と報告用ディメンションを保持していれば、ほぼ完全に回避可能です。

FAQ

有効なVIESレスポンスがあれば、EU域内B2B販売に税率ゼロを適用できますか？

いいえ。VIESは、VAT番号が登録されていること、および対応している場合にEU域内取引に対して有効化されていることを確認するものです。EU域内供給を免税する権利は、顧客が実際の受取人であること、輸送または発送の証明、正しい供給地、および必要な請求書の文言といった追加の証拠に依存します。VIESの結果は判断そのものではなく、1つの入力として保存してください。

VIES検証によってチェックアウトをブロックすべきですか？

ブロックすべきではありません。VIESはタイムアウトや同時接続制限に達することがあり、サービスの停止は番号が無効であることと同義ではありません。非同期で検証し、文書化された期間成功結果をキャッシュし、一時的な障害を再試行し、曖昧なケースは販売を失敗させるのではなく暫定状態でレビュー用に保留してください。

クラウド会計 APIはVAT申告を自動的に行ってくれますか？

スキームおよび加盟国ごとにグループ化され、修正が反映された変更不能な台帳から計算された申告用データを生成することは可能です。各国の申告ゲートウェイを通じて実際に提出まで行うかどうかは、製品や国によって異なります。NordletはOSSおよびIOSSの申告書を計算し、リトアニア、ドイツ、ポーランドの国内申告パックを出荷し、リトアニア向けのVMI対応i.SAF台帳を生成しますが、税務当局に対してユーザーの代わりに何かを提出することはありません。会計、申告書の生成、エクスポート、ゲートウェイへの提出、および支払いは、1回の呼び出しですべての国で完了すると仮定せず、別々の状態として扱ってください。

期間がロックされた後の修正はどのように処理すればよいですか？

元のドキュメントおよび影響を受ける申告期間への明示的なリンクを付与して、後続の期間に投稿します。Nordletは、API経由を含め、ロックされた月への新規投稿をブロックするため、修正は直接の編集ではなくクレジットノートや逆仕訳を通じて行われます。これにより、最初の申告と調整の間の血統が維持されます。

さらに詳しく