【ITニュース解説】Automating tax calculation from Amazon VAT reports: a system design for VAT service providers

越境ビジネスの拡大に伴い、海外での商品販売にかかる付加価値税（VAT）の計算と申告は、各国で異なる税率や規制のため、非常に複雑な課題となっている。Amazonのような大手マーケットプレイスを通じた販売では、提供されるVAT取引レポートには大量のデータが含まれる。これまで、これらのレポートから税金を手作業で計算する作業は、会計担当者がExcelスプレッドシートを使い、取引を国別、税率別、控除項目別に分類し、各国の申告書に手入力するという、時間と労力がかかるものだった。取引量や対象国が増えるほど、間違いが発生しやすくなり、申告書作成にかかる時間も大幅に増加するという問題が顕著だった。

このような課題を解決するため、今回紹介するシステムは、AmazonからのVAT取引レポートをもとに、税金計算を自動化するオンラインプラットフォームとして開発された。このシステムは、VAT登録代行から税金計算、申告、支払い、環境保護サービス（EPR）まで、越境ビジネスの税務コンプライアンス全般をサポートするように設計されているが、特に「税金計算」の自動化に焦点を当てて解説する。これは、税務サービス提供企業が、手作業のサービスを効率的な「プロダクト」に変えることを目指している。

システムの入力は、Amazonが提供する「Amazon VAT取引レポート」だ。このレポートは、各取引を一行で記録し、取引タイプ、税金徴収者（Amazonか出品者か）、購入者の有効なVAT登録番号の有無、発送元・発送先国、税率、税込み・税抜き金額、通貨など、税金計算に必要な詳細情報を含んでいる。税金計算の核となるのは、このレポートの各行から「どの国で、どのような種類の販売として、どの税率で申告すべきか」を判断し、その後、国別および申告期間別に合計していく作業である。

このシステムの中心設計は、「まず取引を分類し、その後に計算を行う」というアプローチを採用している。国ごとに異なる複雑な税務ルールを個別にプログラミングするのではなく、まず全ての取引を事前に定義された7つの販売カテゴリーに分類するのだ。この分類は、主に「税金徴収者（Amazon/出品者）」「購入者のVAT登録番号の有無」「発送元・発送先国（国内、EU圏内、EU圏外輸出）」という三つの情報源を組み合わせて行われる。これにより、例えば「国内販売」「EU圏内距離販売」「VAT登録事業者への供給」「輸出」「マーケットプレイス徴収販売」といったカテゴリーに各取引が割り当てられる。

カテゴリー分類が完了すると、それぞれのカテゴリーに対して、あらかじめ決められた税務上の処理が適用される。例えば、あるカテゴリーの取引は現地国での通常の税率で「出力税」（売上にかかる税金）として課税され、別のカテゴリーは「ゼロレート」で報告、マーケットプレイスが税金を徴収した販売では、出品者自身は追加税を支払わないが報告は必要、といった具合だ。この設計の利点は、国ごとの複雑な税務ルールが「各国の税制がそれぞれのカテゴリーをどう扱うか」という一つのシンプルなテーブル（表）に集約されることだ。これにより、多くの条件分岐（if-else文）を国ごとに書く手間が省け、新しい国を追加する際も、このテーブルに必要な情報を記述するだけでシステムを拡張できる。現在、システムはEU加盟27カ国全ての越境取引ルールを内蔵し、英国とEU圏内のドイツ、フランス、イタリア、スペイン、ポーランド、チェコ、オランダ、オーストリアの8カ国については、税金計算が稼働している。

Amazonレポートには含まれない、別途処理が必要な輸入VAT関連の税金もある。特に英国の輸入VATは、見落とされやすい部分だ。このシステムは、「C79」（輸入VAT証明書）、「C88」（輸入申告書）、そして「PVA（Postponed VAT Accounting）」の三種類の書類を個別に処理する。C79は輸入VAT還付の根拠となり、システムは申告期間ごとにその金額を収集し「入力税」（仕入れにかかる税金）とする。PVAは輸入時にVATを支払わず、申告書上で出力税と入力税の両方に計上することで実質納税額をゼロにする仕組みで、システムはこれを正確に処理する。これらの書類は出品者が別途システムにアップロードする必要があり、申告作業画面では不足があればリマインダーが表示され、申告漏れを防ぐ。

計算された税金は、各国のVAT申告書に合わせた形式で出力される。例えば英国のVAT申告書にはBox 1からBox 9まで、出力税、EU圏内仕入れ税、入力税、純納税額、総売上高、総仕入れ高、EU圏内供給・仕入れといった固定項目がある。システムが取引をカテゴリー分類し、輸入関連情報も処理を終えれば、会計担当者が手作業でExcelを突き合わせることなく、これらのボックスに必要な数字を直接導き出せる。EUの8カ国についても、各国の申告書構造に合わせた合計値を出力する。

越境取引では多通貨が使われるため、システムは毎日為替レートを取得し、取引が行われた日付のレートで申告通貨に換算する。使用されたレートの出典と換算日は計算結果と共に保存され、レビュー担当者が計算根拠を追跡可能だ。

税金計算は、申告プロセス全体を管理する「ファイリングワークスペース」と呼ばれるワークフローの一部として組み込まれている。このワークフローは、「レポートアップロード待ち」から「税金確認待ち」「提出待ち」「会計事務所による申告中」「支払い待ち」を経て「申告済み」となる。出品者はレポートと控除書類をアップロードし、計算された税額を確認・提出する。運営側は計算と申告をレビューし、支払い管理を行う。役割に応じたアクセス権限や監査ログも備わっている。この統合されたワークフローにより、出品者は複雑なExcelを解釈することなく、「今期いくら納税すべきか、その内訳は何か」を直感的に理解できる。

税務データの間違いは企業に大きな損失をもたらすため、システムには複数の技術的な安全策が導入されている。主要な計算経路を網羅する20以上の「エンドツーエンド自動テスト」により、機能が期待通りに動作するかを継続的に検証する。また、システム更新前にはデータベース構造（スキーマ）を比較し、重要なデータフィールドの誤削除を防ぐ。さらに、計算結果は、合計金額がどの個別の取引データから導き出されたか、その関連性（マッピング）を保持している。これにより、レビュー担当者は申告書の合計値の計算根拠を、元の取引まで遡って詳細に確認できるため、計算の正確性に対する信頼性が高まる。

このプラットフォームは約4ヶ月で300回以上の改善（イテレーション）を重ねて開発された。約44のビジネス画面、77のAPIエンドポイント、19種類のデータモデルが構築された。技術スタックは、ユーザーインターフェースにReact 19とTypeScript、サーバーサイドにKoa、データベースにMySQLを使用。OCR機能とオブジェクトストレージにはAlibaba Cloudのサービスが活用されている。

手作業での税金計算プロセスをシステム化しようと考えているVATサービスプロバイダーにはいくつかのアドバイスがある。まず、プログラミングを始める前に、税務ルールを「カテゴリーと国のマトリックス（表）」として明確に書き出すべきだ。これにより、ルール内の曖昧な点や例外を早期に特定できる。次に、マーケットプレイスレポートとC79のような控除関連書類は情報源も提供タイミングも異なるため、システム内でこれらを別々のデータとしてモデル化し管理することが重要だ。また、システムが導き出すすべての計算結果が、元の個々の取引データまで遡って追跡できるような仕組みを構築すること。これにより、レビュー担当者が安心して計算結果を承認し、申告にサインオフできる。最後に、最初からすべての国に対応しようとするのではなく、英国とEU圏内の1～2カ国といった限定された範囲からシステム構築を始め、基本的なワークフローが機能することを確認してから、徐々に対象国を増やしていくのが賢明なアプローチである。

このシステムを開発したFXTechは、中国の深圳を拠点とするeコマーステクノロジーエージェンシーで、VATサービスプロバイダー、税務代理店、越境eコマースチーム向けにVATコンプライアンスシステムを構築している。同社は税務申告を直接行うわけではなく、Shopifyストア構築やヘッドレスDTCストアフロント開発、ウェブパフォーマンス最適化なども手掛けている。