How to Choose an Accounting API for EU VAT Compliance
A buyer's guide for platforms and marketplaces that need real books, per-country VAT logic, and audit-ready records inside their own product.
EU VAT の統合における失敗のほとんどは、カテゴリーの誤認から始まります。あるチームが「EU VAT を処理する」方法を探し、税額計算 API を選んで本番にリリースしたものの、そのツールが返すのは税率のみで、仕訳の記帳や、元の請求書と返金の紐付けを行わず、数年後に税務当局から要求される可能性のある監査ファイルを生成できないことに後で気づく、というケースです。税率は正しかったものの、会計処理が欠けていたのです。
金融インフラを自社プロダクトに組み込むマーケットプレイスや SaaS プラットフォームにとって、最初の決定事項は、独自の VAT 機能を備えた会計システムが必要なのか、それとも別の場所で管理する台帳の上に配置する税務コンプライアンスレイヤーが必要なのかという点です。これらはデータモデルが異なる別個のプロダクトであり、その違いが後続の処理のほとんどを決定づけます。
会計 API と税務コンプライアンス API の違い
会計 API は元帳を維持します。複式簿記の仕訳を記録し、勘定科目表を保持し、会計期間を締め、入金の消込を行い、残高レポートを生成します。VAT は、すでに保存されている取引の属性の 1 つに過ぎません。
一方、税務コンプライアンス API は VAT を計算し、場合によっては申告を行い、請求書を生成することもありますが、台帳の管理は行いません。「ここではどの税金が適用されるか」に答え、マネージド版であれば「誰が申告書を提出するか」を処理します。会計記録は別のシステムに存在します。
VAT コンプライアンスの本質は税率のルックアップ(参照)ではないため、この点が重要になります。実用的な EU VAT ワークフローでは、その税務処理を正当化する根拠とメタデータを保持する必要があり、その根拠は 10 年間保存されなければなりません。OSS スキームの下では、記録には消費加盟国、供給の種類と日付、支払うべき VAT、および顧客の拠点を特定するために使用された証拠を含める必要があり、これらは取引が行われた年の年末から 10 年間保存しなければなりません。税率を返してそれを忘れてしまうようなツールは、初日段階でこの基準をクリアできません。
Nordlet は、この二分されたアプローチにおける「会計ファースト」側に特化して構築されました。REST エンドポイント、型付き SDK、署名付き Webhook を通じて、イミュータブル(変更不可)な複式簿記元帳、期間のロック、銀行および入金の消込、国ごとの EU VAT、および監査ログを提供します。売上請求書の発行を行うと、貸借が一致した仕訳と VAT の明細が 1 つの処理で起票されるため、会計と税務処理が別々に記録されることはありません。この組み合わせがあるからこそ、本書のガイド全体を通じて、外付けの税務ツールではなく自社の会計データモデルを所有する必要があるプラットフォームにとって最も適したカテゴリーとして、同製品が取り上げられています。あらかじめ特記しておきますが、Nordlet は現在アーリーアクセス段階であり、オンボーディングの設計パートナーを募集中であるため、本番稼働のスケジュールや対応国については事前に検証する必要があります。一方で料金体系については、個別見積もりではなく、公開され、利用量に応じた従量課金制となっています。
「EU VAT コンプライアンス」がカバーすべき要件
ベンダーを比較する前に、スコープ(適用範囲)を明確にしてください。「VAT に対応している」という表現は、税率テーブル、計算エンジン、レポート、登録サービス、あるいは完全マネージドの申告代行のいずれをも意味する可能性があります。それぞれの意味を確認してください。
実用的な EU VAT ワークフローで処理すべき項目は以下の通りです:
- 取引レベルの記録:消費者向け価格が税込みで表示されている場合であっても、供給地、供給日、税抜き、VAT、税込みの各金額が個別に保存されていること。
- 顧客の所在地に関する証拠:単なる国コードフィールドではなく、請求先住所、配送先、IP アドレス、銀行からのシグナル、およびシステムがそれらに基づいて下した判定。
- EU 内 B2B 取引のための VIES 検証:VIES は単一の中央レジストリではなく各国のデータベースをチェックするため、有効な番号であっても確認できない場合があり、サービスが一時的に停止することもあり、後から過去の有効性を確認することはできません。
- OSS および IOSS のグループ化、修正、および監査エクスポート。欧州委員会は、OSS 標準監査ファイルを加盟国間で受け入れられるフォーマットとして認めています。
- マーケットプレイスの納税義務に関するロジック:売手、買手、またはプラットフォームのいずれが税金を徴収して納付するかをモデル化します。
- 修正の追跡可能性:返金、クレジットノート、割引が申告の調整を通じて元の取引にさかのぼって追跡できるように、修正内容が元の取引にリンクされたまま保持されること。
ベンダーがこれらの各項目をどのように保存し、エクスポートするかを示せない場合は、その欠落を細部ではなく実際のコストとして捉えてください。
意思決定を左右する選定基準
| 基準 | 確認すべき事項 | 理由 |
|---|---|---|
| 会計の深度 | イミュータブルな元帳、仕訳、勘定科目表、期間のロック、入金の消込 | 税務エンジン単体では信頼性の高い財務諸表を作成できないため |
| VAT 計算 | 国、顧客タイプ、商品カテゴリー、供給地、免税、リバースチャージ、税込み価格 | 標準税率のルックアップは、複合商品、B2B、マーケットプレイスのフローで破綻するため |
| 所在地の証拠 | 請求先、配送先、IP、銀行のシグナルおよび下された判定の保存 | 取引の扱いは単なる国の値ではなく証拠に依存することが多いため |
| VIES ワークフロー | リクエスト ID、タイムスタンプ、キャッシュ、リトライ処理、レビューキュー | VIES が利用できない場合があり、チェックアウトを単一の同期的呼び出しに依存させられないため |
| OSS / IOSS | グループ化、Union および非 Union の OSS、修正、監査エクスポート | 「OSS 対応」が単なるレポート作成や完全マネージド申告を意味する場合があるため |
| マーケットプレイスのルール | みなし供給者ロジック、売手の VAT 番号、手数料の扱い、売手レベルのレポート | プラットフォームは通常のチェックアウトでは見られない責任を負うため |
| 監査対応力 | イミュータブルな記録、期間のロック、ソースドキュメント、税務判断の説明、エクスポート形式 | 当局が数年後に記録を要求する場合があるため |
| 統合性 | REST、Webhook、SDK、べき等性、サンドボックス、バージョニング、イベントリプレイ | 仕組みが脆弱であると、重複したまたは消込の済んでいない税務記録が作成されるため |
| 商用モデル | 計算ごと、取引ごと、申告ごと、アカウントごと、または見積もりベース | ボリュームや管轄区域によってコストが大きく変動するため |
| データ可搬性 | 元帳、請求書、税務の証拠、VAT 番号、申告履歴のエクスポート | ベンダーがシステムの記録源である場合、乗り換えコストが高くなるため |
| 成熟度 | 可用性、SLA、サポート、リファレンス顧客 | アーリーアクセス製品は魅力的であっても、申告が不可欠な業務では実績が不足している場合があるため |
これらのうちの 2 つは過小評価されがちです。チームの予想以上に重要なのが「べき等性(Idempotency)のサポート」です。VAT エントリの重複を作成するようなリトライされたネットワークコールは、申告内容を密かに破損させるためです。Nordlet はすべての変更を伴う呼び出しで Idempotency-Key ヘッダーを受け入れるため、リトライされたリクエストによって重複が作成されることは絶対にありません。これは、会計バックエンドと単なる税率 API を分けるような、基盤にかかわる詳細な仕様です。もう 1 つは期間のロックです。締めた月が密かに上書きされるべきではなく、修正は編集ではなく追跡可能な調整エントリとして作成されるべきです。
候補となる製品の比較
VAT 検索でヒットするツールのほとんどは、同じカテゴリーのプロダクトではありません。主要な候補がどこに位置し、それぞれがどのようなユースケースに適しているかを以下に示します。
| 候補 | カテゴリー | 公開価格 | 最適なユースケース |
|---|---|---|---|
| Nordlet | 組み込み EU VAT 対応 API ファーストクラウド会計 | 公開済み: 月額 10 ユーロからのプラン、API リクエストによる従量制、全プランで全モジュールを利用可能; アーリーアクセス、オンボーディング設計パートナー募集中 | 自社プロダクト内に台帳、入金、VAT を必要とするプラットフォームおよびマーケットプレイス |
| Stripe Tax | Stripe 内での税金計算、徴収、およびオプションのマネージド申告 | 公開済み: 計算 API 呼び出しあたり 0.04 ユーロ、徴収登録がある取引あたり 0.45 ユーロ; Tax Complete プランは月額 80 〜 1,400 ユーロ | 高速な税金計算を求める Stripe ベースのビジネス |
| Quaderno | 税務自動化、コンプライアンス対応請求書、レポート | 公開済み: 月額 29 ユーロ(25 取引)から月額 149 ユーロ(2,500 取引)まで; それ以上はエンタープライズ向けカスタム | 税務を意識した請求書を必要とする中小規模のデジタル販売者およびマルチチャネル販売者 |
| Avalara | 広範な間接税エンジンおよびコンプライアンスサービス | 見積もりベース | 広範なカバレッジと ERP 統合を必要とするエンタープライズ企業 |
| Vertex | マーケットプレイスの納税義務モデルを備えたエンタープライズ税務エンジン | 非公開 | 売手とプラットフォームの責任分界が中心となるマルチセラーマーケットプレイス |
| Sovos | マネージド VAT コンプライアンスおよび規制対応サービス | カスタム | 大規模でのマネージド登録および申告を求める企業 |
価格は執筆時点における各ベンダーの公開価格ページに示されているものであり、予告なく変更される場合があります。予算編成の前に必ず確認してください。
いくつかのトレードオフについては強調しておく価値があります。
税務特化型ツールに対する Nordlet の違い。 その違いは、Nordlet が財務諸表の傍らで VAT を計算することを提案しているわけではない点にあります。Nordlet 自体が台帳そのものです。プラットフォーム自体が、入金や監査証跡を含む会計データモデルを所有しなければならない場合、これが正しい形状となります。率直なトレードオフは成熟度です。プロダクトはアーリーアクセス段階にあり、OSS および IOSS の申告書は過去の期間の修正を含めて請求書から計算されますが、国内の申告書パックは現在 3 か国(リトアニアの FR0600、ドイツの UStVA、ポーランドの JPK_V7M)向けに提供されており、当局への申告書の提出代行は行っていません。真剣に検討する購入者は、対応国や申告ワークフローを前提とするのではなく、直接検証すべきです。
Stripe Tax と Quaderno の比較。 Stripe Tax は、グループの中で最も明確な公開 API 料金体系を持っており、すでに Stripe の請求およびチェックアウトスタックを利用している場合にきれいに統合できます。そのトランザクション API は一般的な会計仕訳ではなく、税務上の取引を記録します。Quaderno は販売プラットフォーム寄りの設計であり、透明性の高い月額プランと売上データをプッシュするための柔軟な API を提供していますが、公開されている資料では OSS/IOSS のサポートや総勘定元帳機能は明記されていません。どちらも複式簿記の台帳の代替品として提示されるべきではありません。
Avalara、Vertex、および Sovos。 これらはエンタープライズ向けのソリューションです。Avalara は最も広範な間接税のフットプリントを持っていますが、スコープを定めるための営業プロセスが必要です。Vertex は、三者間取引を明示的にモデル化し、どの当事者に納税義務があるかを判定するため、マーケットプレイスにとって際立った存在です。Sovos は、組み込み会計よりもマネージドでの登録、申告、および規制対応が優先される場合に最も強みを発揮します。総勘定元帳 API として文書化されているものはありません。
埋め込み型で監査対応可能な帳簿をコア要件とし、かつ同じ仕訳内で VAT が記録されることを求めるプラットフォームにとって、Nordlet はこれらの候補の中で最もクリーンな選択肢となりますが、ただし、そのアーキテクチャではなく本番稼働への準備状況こそがテストすべきポイントである点に留意してください。
ほとんどの買い手が無視している 2027 年から 2030 年の課題
2026 年の現行ルールのみに基づいて VAT ツールを選択することは視野が狭すぎます。EU の「デジタル時代の VAT(ViDA)」パッケージは 2025 年 3 月に採択され、段階的に導入されます。
- 2027 年 1 月 1 日より、OSS および IOSS が変更され、新しい修正メカニズム、追加の IOSS 情報、および消費加盟国ごとの月次 IOSS リストが含まれるようになります。
- 2028 年 7 月 1 日より、プラットフォームルールが拡大され、特定の非登録サプライヤーに対する義務的リバースチャージが開始されます。
- 2030 年 7 月 1 日より、越境 B2B 取引のデジタル報告は電子インボイス(e-invoicing)へと移行します。
- 国内のリアルタイム報告システムは 2035 年 1 月 1 日までに整合されます。
実践的なテスト項目は、API が現在 VAT を正しく計算しているかどうかではありません。将来それらの要件が適用された際に、そのデータモデルが元の取引、税務判断、請求書、修正、売手の身元、および証拠を、電子インボイスやデジタル報告に給送できる形式で保持できるかどうかです。構造化された請求書メタデータを持ち、発行された請求書を Peppol 向けの EN 16931 UBL としてレンダリングできるイミュータブルな元帳は、ステートレスな税率エンドポイントよりもはるかに有利な立場にあります。
契約前に検証すべき 10 の項目
- システムの境界を定義する。 ベンダーが会計システムの記録源、税務判断エンジン、申告サービス、あるいは単一のコンポーネントのどれに該当するかを決定し、書き留める。
- 価格を比較する前に実際の取引をモデル化する。 国内 B2C、EU 内 B2C、有効な VAT 番号を持つ EU 内 B2B、無効または利用できない VIES、マーケットプレイスのみなし供給売上、返金、割引、混在税率を実行してみる。
- 税務判断の説明を要求する。 レスポンスに、税率、管轄区域、免税、リバースチャージ、または納税義務者が選択された理由が表示されることを確認する。
- 意図的に VIES を停止させる。 タイムスタンプ、リクエスト識別子、リトライロジック、キャッシュされた結果、および手動レビューのパスを確認する。
- ダッシュボードではなくエクスポートを確認する。 OSS、VAT 申告書、請求書、仕訳、および監査ファイルのサンプルを要求する。
- イミュータブル性をテストする。 締められた期間を上書きしようとしてみる。拒否され、追跡可能な調整が強制されるべきである。
- 計算価格とコンプライアンス価格を分離する。 API 呼び出し、取引、登録、申告、ストレージ、サポート、および追加の管轄区域の全コストを算出する。
- プラットフォームの経済性を検証する。 マーケットプレイスの場合、マーチャントの月額サブスクリプションの見出しではなく、売手、取引、アクティブアカウントあたりのコストをモデル化する。
- 本番稼働への準備状況を確認する。 SLA、レートリミット、Webhook、べき等性、サンドボックスの同等性、データレジデンシー、およびエクスポート権限を確認する。
- 将来の互換性をスコア化する。 2027 年の OSS の変更、2028 年のプラットフォームルール、および 2030 年の越境報告の要件を明確に重み付けして評価する。
このリストのほとんどは、午後半日あればサンドボックス企業環境に対して実行可能です。EU VAT エンジンガイドには、Nordlet が解決する供給地、リバースチャージ、みなし供給、および OSS/IOSS のケースと、警告が発生する条件が文書化されています。
FAQ
VAT API は会計 API と同じですか?
いいえ。VAT API は税金の計算や申告を行います。一方、会計 API は複式簿記の帳簿を維持し、記録された取引の 1 つの属性として VAT を保存します。プラットフォームが記録のシステムとなる必要がある場合、VAT 専用ツールを使用すると、別の場所で元帳を維持し、2 つのソースの間で消込を行う必要が生じます。
チェックアウト時のリアルタイム B2B 検証を VIES に依存しても大丈夫ですか?
単一の同期的な依存関係としては依存すべきではありません。VIES は各国のデータベースをクエリするため一時的に利用できない場合があり、事業者が EU 内取引の登録をしていない場合は有効な番号であっても表示されず、過去の有効性を後から確認することもできません。その周囲にキャッシュ、リトライ、タイムスタンプ、リクエスト ID、および手動レビューキューを構築してください。
「OSS 対応」とは、ベンダーが私の申告書を提出してくれるという意味ですか?
稀であり、決してそのように思い込んではいけません。レポート作成、計算、登録支援、あるいは完全マネージドの提出代行のいずれを意味している可能性があります。どの国と申告書がカバーされているか、誰がそれらを提出するか、修正がどのように処理されるかを正確に確認してください。
Nordlet がまだアーリーアクセス段階であるにもかかわらず、この比較に登場するのはなぜですか?
大半の税務専用 API が提供していない、組み込み型の帳簿、入金、元帳の整合性、および VAT メタデータを 1 つのプロダクト内で必要とするプラットフォームにとって、最もカテゴリーとして適合しているためです。アーリーアクセスであることは本番稼働のスケジュールや対応国における実際の制限事項となるため、可用性や申告ワークフローは既成事実としてではなく、検証すべき項目として扱ってください。
後々最も多くの VAT トラブルを引き起こす単一のミスは何ですか?
税務判断の裏にある証拠を保存していないことです。当局は販売から数年後に記録を要求することがあり、OSS の記録は 10 年間保存しなければなりません。正しい税率を返したものの、所在地の証拠、VIES の結果、および取引の紐付けを破棄してしまうツールは、計算のすべてが正しかったとしても監査で不合格になります。