ガイド
UAEでeインボイシング技術提供者またはASPを設立する方法
短い回答
財務省はUAEの電子請求書(eInvoicing)の枠組みを定め、サービスプロバイダーを認定します。連邦税務庁は、交換基盤と、事業者がプロバイダーを選択するためのEmaraTaxシステムを運営します。重要となる許可は、2025年財務大臣決定第64号に基づく認定サービスプロバイダー(Accredited Service Provider、ASP)の資格です。これは標準的なテクノロジー分野のトレードライセンスとは別のものであり、会社は規制対象の交換基盤に一切関与することなくそのライセンスを保有できます。ルートを決める問いは単純です。その会社は四つのコーナーの一つとして請求書を交換するのか、それとも交換を行う者にソフトウェアを提供するのか、という点です。
四者モデル(four-corner model)とあなたの役割を誰が決めるか
この取引は4コーナーモデルで機能する。Corner 1は請求書を発行するサプライヤー、Corner 4はそれを受け取る顧客であり、両者はPDFをメールで送るのではなく、認定された仲介者を通じて構造化された請求書データを交換する。Corner 5は税務目的でFederal Tax Authorityに同じデータを報告し、このレポーティング用コーナーは2026年7月1日に開始されたパイロットに先立って稼働を開始した。
事業者は、自らをこのチェーンの一員と宣言するだけでは参加できません。ASPは財務省によって認定され、クライアントは商業契約を締結し、連邦税務庁のEmaraTaxシステムを通じて選択することでASPを選びます。会社の製品が請求書データの作成または表示のみを行い、交換基盤を通じて伝送しない場合、その会社はコーナー1、4、5のいずれとしても機能しておらず、認定が適用される可能性は低いといえます。ただしこれは、トレードライセンス上の名称ではなく、ソフトウェアが実際に何を行うかという問題です。
Ministry of FinanceとFederal Tax Authorityが実際に求める要件
ここで法的な重みを持つのは三つの大臣決定である。2025年大臣決定第243号(No. 243 of 2025)がeInvoicingシステムを創設し、2025年大臣決定第244号(No. 244 of 2025)がその実施手続きを定め、2025年大臣決定第64号(No. 64 of 2025)が誰がどのようにAccredited Service Provider(認定サービスプロバイダー)になれるかを定めている。Federal Tax Authority(連邦税務庁)はeInvoicingを狭く定義しており、電子的に発行・交換される構造化されたインボイスデータを指し、どれほど整然とした書式であってもPDFやメール送付のインボイスはこれに含まれない。
年間売上高が5,000万AEDを超える事業者について、財務省は二つの期日を定めています。2026年10月30日までにASPを任命すること(当初の2026年7月31日の期限から、2026年5月に延長されました)、および2027年1月1日までにシステムを稼働させることです。財務省は、その他の売上区分および政府機関にはそれより後のスケジュールが適用されると述べていますが、本稿執筆時点では、そのスケジュールは同省自身のポータルに文字ではなく画像として掲載されていたため、本ガイドでは5,000万AEDの基準未満の事業者に関する具体的な日付を繰り返しません。依拠する前に、財務省の電子請求書に関する最新のポータルをご確認ください。
2026年5月までに、省は既に32社のサービスプロバイダーを承認しており、さらに複数が認定の最終段階にあった。また、UAE企業が海外のプロバイダーと提携して基盤となる技術とノウハウを取り入れられるよう、規則を改正していた。
ベンダー、インテグレーター、ASP:答えを変える組織構造の選択
法域(jurisdiction)を比較する前に、その事業が実際にどのモデルに当たるかを確定させておくこと。モデルごとに制度の異なる部分が適用されるためである。
- ERPまたは会計ソフトウェアのベンダー。要件に適合したデータを生成するツールを販売するが、交換網そのものの外に位置する。
- システムインテグレーター。顧客のERPをASPに接続するが、自らはASPにはならない。
- Accredited Service Provider(ASP、認定サービスプロバイダー)。クライアント(client)に代わって、Corner 1、4、または5として交換網を通じてインボイスを運ぶ。
- コンプライアンス、アーカイブ、または分析のレイヤー。データが既に移動した後に、そのデータを中心として構築される。
これに続いて、自社開発、提携、またはホワイトラベルのいずれにするかという判断が必要になります。国内企業が国際的なプロバイダーと提携することを認める2026年5月の改正が存在するのは、UAEへの新規参入者の多くが交換基盤をゼロから構築するのではなく、ライセンスを受けるか、ホワイトラベルとして利用するからです。この選択によって、財務省が誰を認定するか、誰がクライアントとの契約に署名するか、基盤となる技術が機能しなかった場合に誰がコンプライアンス上のリスクを負うかが変わります。これは三つの別個の問題であり、一つの会社名では見えにくくなることがあります。
交換を通じて資金と責任がどのように移動するか
この事業を審査する銀行は、一度きりのトレードライセンスではなく、継続的なソフトウェア収益または取引収益を確認したいと考えます。また、請求書が拒否された場合や誤って伝送された場合に誰が責任を負うのか(ベンダー、インテグレーター、ASP、クライアントのいずれか)を尋ねます。この責任の配分は、紛争が起きた後ではなく、最初の請求書が流れる前にクライアントとの契約に盛り込んでください。
事業が投資家または国際的な技術パートナーから資金提供を受けている場合、資金の出所とパートナーシップの構造は、銀行にとっても財務省の認定審査にとっても重要です。技術的な申請と並行して、後回しにせず資金の出所を文書化してください。認定を申請する前に銀行口座開設の準備状況の評価を行うと、これらの問題をまだ対処しやすい早い段階で洗い出せることが多くあります。ここでの費用は一つの総額ではなく、会社設立、認定、継続的なコンプライアンスという層ごとに積み上げられ、これらに取り組むためのVelarozoneの報酬は業務委託契約書(engagement letter)に項目別に記載されます。Velarozoneの業務の進め方をご覧ください。
よくある失敗
- Ministryがまだ認定を与えていない段階で、承認された認定サービスプロバイダー（ASP）として宣伝したり、認定を受けているかのように示唆したりすること。
- 構造化インボイス交換（structured invoice exchange）を、PDFをメールで送ることと同等に扱うこと。これはFederal Tax Authority自身の定義によって除外されている。
- 拒否または誤送信されたインボイスに関する責任を、クライアント契約の中で定義せずに放置すること。
- ソフトウェアのトレードライセンスだけで、クライアントの収益基準に関する義務を満たせると思い込むこと。
- Ministryが実際にどの事業体を認定しているのかを文書化せずに、ホワイトラベルのパートナーシップを構築すること。
認定から日々の運営へ
認定は一度きりの手続ではありません。財務省が審査を行うため、技術チーム、データホスティングの取り決め、サポート体制は、クライアントを受け入れた後も、申請書に記載したとおりに維持する必要があり、変わってしまってはなりません。主要な技術・コンプライアンス担当者には、通常、運営主体に紐づくUAE居住ビザが必要です。また、会社自体も他のUAE企業と同様に法人税と付加価値税（VAT）の登録を行うため、eインボイスの認定は通常の納税義務に取って代わるものではなく、それと並んで存在します。
認定更新のカレンダーと通常のトレードライセンス更新を分けて整理した文書化された運営計画があれば、いつの間にかずれていく二つのカレンダーではなく、一つのカレンダーで管理できます。交換機能を一つの事業体に置き、ソフトウェア開発を別の事業体に置く場合(パートナー構成やホワイトラベル構成でよく見られます)は、どちらかが申請する前に解決すべき複雑な所有構造の問題として扱ってください。
