【ITニュース解説】Stripe's VAT Verification Happens After Checkout, Not Before

多くの企業がオンライン決済プラットフォームStripeを利用しているが、特にEU（欧州連合）圏内での企業間取引において、付加価値税（VAT）の処理は複雑になることがある。このニュース記事は、StripeがEU VAT番号をどのように検証しているのか、そしてそのプロセスがシステムエンジニアにとってどのような意味を持つのかを詳しく解説している。StripeのVAT検証は、ユーザーが入力した直後ではなく、決済が完了した「後」に「非同期」で行われるという点が重要だ。

Stripeの決済処理において、顧客がVAT番号を入力する際、システムはまずその番号が「正しくフォーマットされているか」だけを確認する。これは、例えば国コードが先頭にあるか、適切な文字数や文字種に沿っているかといった、あくまで形式的な整合性をチェックする作業だ。この段階では、入力されたVAT番号が実際に有効で、登録された企業に属しているか、といった実在性や有効性までは確認しない。そのため、形式的には正しいものの、実際には存在しないVAT番号であっても、この初期のチェックは通過してしまう。

この形式チェックが完了すると、Stripe Taxはすぐにリバースチャージ（購入者がVATを自己申告する仕組み）を適用するかどうかを決定してしまう。つまり、まだStripeがEUのVAT情報交換システム（VIES）に問い合わせていない段階で、税金の扱いが決定されるのだ。

VIESによる本格的なVAT番号の有効性検証は、決済が完了した「後」に「非同期」で行われる。非同期とは、ある処理の完了を待たずに次の処理を先行させる方式のことで、顧客は決済をすぐに終えることができる。顧客が決済を終え、すでに料金が請求された後、StripeはVIESにVAT番号の有効性を問い合わせる。この検証には数秒かかることが多いが、VIESシステムの可用性によってはそれ以上かかる場合もある。この検証結果は、Stripeのダッシュボードで顧客のVAT番号にカーソルを合わせると表示されるツールチップや、「customer.tax_id.updated」というウェブフックイベントを通じてシステムに通知される。しかし、この非同期で得られた検証結果が、すでに発行された請求書の内容や、適用されたリバースチャージの決定を自動的に変更することはない。つまり、後からVAT番号が無効だと判明しても、Stripeが自動的に請求書を修正することはないのだ。

さらに重要な点として、StripeによるVAT番号の有効性検証は、一度番号が収集され、有効または無効と判断されると、その後自動的に繰り返されることはない。つまり、ある企業が決済時には有効なVAT番号を持っていたとしても、数ヶ月後に事業を停止してVAT登録が解除されたとしても、Stripeはその変更を自動的に追跡しない。一度Stripeに登録されたVAT番号は、Stripeが最後に確認した時点のステータスのまま保持され続けるため、定期的な再検証が必要な場合は、システム側で別途対応する必要がある。

これらのStripeのVAT検証プロセスから、いくつかの重要な「ギャップ」が見えてくる。第一に、リバースチャージの適用はVAT番号の「形式」だけに基づいて行われ、StripeがVIESに問い合わせる前に行われること。第二に、実際の有効性チェックは決済後に完了するが、もし結果が期待と異なっても、すでに適用されたリバースチャージを取り消したり、請求書を再発行したりする自動的な仕組みがStripeにはないこと。第三に、VAT番号は一度しか検証されないため、収集後にステータスが変更されても、Stripeはそれを捕捉しないことだ。

これらの点はStripeの欠陥ではない。オンライン決済を迅速に進めるためには、VAT番号の有効性をリアルタイムで厳密に検証すると、決済処理が遅れてしまい、顧客体験を損なう可能性がある。Stripeは、VAT番号の形式チェックと請求書発行、決済処理のインフラを提供するものであり、税務上の有効性検証サービスそのものを目的としているわけではないと明言している。顧客情報の有効性を確認する最終的な責任は、事業主側にあるというスタンスだ。また、StripeはVIES検証時に発行される「consultationNumber」（照会番号）を提供しない点も挙げられる。これは、特定の検証がいつ、誰によって行われたかの証拠となる重要な情報だが、Stripeが提供するのは単なるステータスと名前・住所のスナップショットのみであり、税務監査官に提示できる公式な証拠とはなりにくい場合がある。

これらのギャップを埋め、より確実な税務処理を行うためには、Stripeの決済フローをそのまま利用しつつ、システム側で追加の処理を実装することが推奨される。具体的な解決策は、Stripeの「checkout.session.completed」というウェブフックイベントを利用することだ。このイベントは、顧客が決済セッションを正常に完了した直後に発生し、顧客が入力したVAT番号がStripeから提供されるタイミングである。

このウェブフックを受け取った際に、システムは独自のVAT検証API（例えば、ニュース記事で紹介されているvatnode.devのような外部サービス）を呼び出し、同期的に（つまり、結果が返ってくるのを待ってから次の処理に進む形で）VIESに対してVAT番号の有効性を問い合わせる。このとき、検証結果には「consultationNumber」などの証拠情報も含まれるため、これを請求書情報と紐付けてデータベースに保存することで、後日の税務監査に備えることができる。

具体的な実装例として、システムはcheckout.session.completedイベントを受け取った後、セッション情報からVAT番号を取得し、外部のVAT検証APIにリクエストを送る。APIからの応答が成功であれば、その結果（VAT番号が有効かどうか、関連する会社名、住所、そして重要なconsultationNumberなど）をデータベースに保存する。もしVAT番号が無効だと判明した場合でも、自動的にすでに発行された請求書を修正するのではなく、「レビュー待ち」としてフラグを立てることで、手動での確認を促す対応が考えられる。これは、自動的な税務処理の変更が既存の請求書に混乱を招く可能性があるため、慎重な対応が求められるからだ。 もしAPI呼び出しが失敗した場合（例えば、VIESが一時的に利用できない、APIがタイムアウトするなど）、それはVAT番号が無効であるとは限らないため、すぐに処理を中止するのではなく、後で再確認する仕組み（リトライキューなど）を用意することが賢明である。

このアプローチは、一度きりのVAT番号検証に関するギャップを解消するが、時間が経ってからのVAT番号の変更（例えば、登録の無効化など）には対応できない。そうした長期的な監視には、VAT IDを継続的に監視する別の定期的なチェックシステムを導入することが必要となる。

StripeのVAT番号検証は、決済処理の高速性を優先するため、形式チェックを先行させ、実際の有効性検証は非同期で後から行う仕組みになっている。この設計は決済体験を損なわない一方で、税務処理の厳密性という点でシステムエンジニアが考慮すべき「ギャップ」を生み出す。このギャップを埋めるためには、Stripeが提供する「checkout.session.completed」ウェブフックを活用し、独自の同期的なVAT検証APIを呼び出すことで、リアルタイムに近い形でVAT番号の有効性を確認し、その証拠情報を自身で管理することが効果的な解決策となる。これにより、リバースチャージの決定に強固な根拠を持たせ、税務監査にも対応できる体制を構築できる。VIESの利用可能性に依存して決済をブロックすることは避けるべきであり、一時的なシステム障害は「無効」とは異なるものとして扱う必要がある。最終的な税務処理の判断は、必ず専門家と相談することが重要である。