執筆:Kristijan Sekereš

UAEの電子インボイス、2027年7月1日開始:自社開発ERPをPeppolに対応させる

夜のドバイのスカイライン。水面にブルジュ・ハリファが映っている

2027年1月1日から、年間売上高が5,000万ディルハム(AED)以上のUAE企業は、B2BとB2Gの請求書を構造化されたXMLとして発行・受領し、認定サービスプロバイダーを通じてPeppolネットワークで送らなければなりません。この基準を下回る企業は2027年7月1日に続き、2027年3月31日までにプロバイダーを選任する必要があります。政府機関の稼働開始は2027年10月1日です。

稼働開始日からは、XMLそのものが税務インボイスになります。いまシステムがメールで送っているPDFが必要なのは、まだネットワークに参加していない顧客向けに、XMLと併せて送る場合だけです。

請求書をZoho、Tally、Wafeqなどのパッケージ製品から出しているなら、作業の大半はベンダーの仕事です。 この3社はいずれも、財務省の認定プロバイダー一覧に載っています。自社でやるべきことは、プロバイダーを選び、EmaraTaxでオンボーディングを済ませ、顧客データを整備することです。

この記事は、自社で保有するシステムから請求書を出している企業向けです。自社開発のERP、アップグレードできないほどカスタマイズを重ねた導入環境、内製の請求エンジンなどです。こうしたシステム向けのコネクターは、誰も用意してくれません。UAE電子インボイスガイドラインもそのとおりのことを書いており、企業は「自社システムのカスタマイズを完了し、請求データの送信テストを開始」しなければならないとしています。

日程

各フェーズは、改正後の2025年閣僚決定第244号で定められています。

対象プロバイダーの選任期限稼働開始
売上高5,000万ディルハム以上2026年10月30日2027年1月1日
売上高5,000万ディルハム未満2027年3月31日2027年7月1日
政府機関2027年3月31日2027年10月1日

1行目の期限は、もともと2026年7月31日でした。2026年閣僚決定第66号がこれを2026年10月30日に移し、稼働開始日はそのままにしました。ガイドラインの表にはいまも古い日付が載っているので、2つを突き合わせて読んでください。

任意導入は2026年7月1日から誰にでも開かれており、これは後述の計画で効いてきます。

対象範囲

電子インボイスは、VAT登録の有無にかかわらず、UAEで事業を行うすべての者に適用されます。VAT登録をしていない事業者は、税務インボイスではなく電子商業インボイスを、同じネットワークを通じて発行します。

B2B、B2G、G2B、G2Gの取引が対象です。消費者向けの供給は、大臣が別段の決定をするまで対象外です。消費者にしか販売しない事業者は、当面この制度の対象になりません。主権的な政府活動、航空旅客券、VAT非課税の金融サービスについては、狭い範囲の除外があります。

VATグループを運営している場合、重要な緩和措置が1つあります。同じグループのメンバー間の取引には、2027年1月1日から24か月の猶予期間があります。ただし各メンバーは自らのTINで個別にオンボーディングし、グループ外の相手への請求書は通常の日付から対象になります。

ERPから見た5コーナーモデル

UAEは5コーナーモデルを採用しています。

  1. コーナー1:自社(売り手)。
  2. コーナー2:自社の認定サービスプロバイダー(ASP)。
  3. コーナー3:買い手のASP。
  4. コーナー4:買い手。
  5. コーナー5:連邦税務庁(FTA)。

自社システムがやり取りする相手は、自社のASPだけです。 請求データは、ASPと合意した形式で送ります。ASPはそれを検証し、必要ならUAEのXMLに変換して買い手のASPに届け、並行して税務データをFTAに報告します。買い手のASPも受け取ったものを検証し、同じく報告します。確認応答は、この経路を逆にたどって自社に戻ってきます。

この報告には、UAE Tax Data Documentという別のPeppol文書が使われます。Peppolの仕様では、「請求書の発行者と受領者の双方が請求書を報告するために使用する」ものとされています。これを作るのはASPです。自社が作るのは、戻ってくるものの処理です。買い手側が請求書を受理したという確認、FTAが税務データを受け取ったという確認、そしてそのどちらかが失敗したという通知です。

ASPは、転送、暗号化、参加者の検索、各請求書を一意に識別するUUIDを受け持ちます。請求書上のすべての値を計算する責任は、引き続き自社にあります。 買い手のPeppol識別子を集めるのも自社です。プロバイダーは請求書を検証しますが、訂正はしません。

ASPは送信と受信の両方を兼ねて、1社だけ選任します。

自社システムが出力しなければならないもの

フォーマット

UAEはPeppol PINT-AEを使います。UBLのXMLで、請求用の仕様と、それとは別の自己請求(セルフビリング)用の仕様があります(執筆時点ではどちらもバージョン1.0.4)。QRコードはありません。独自の項目は追加できず、業界固有の事項はASPと合意して扱います。

レガシーシステムに欠けがちな項目

財務省は必須項目の一覧を公表しており、電子税務インボイスでは51項目です。手を入れる必要が出やすいのは次の項目です。

  • 双方の電子アドレス。 自社のエンドポイントは0235に10桁のTINを付けたもので、TINはTRNの最初の10桁です。買い手のエンドポイントも同じ形式なので、すべての顧客レコードに新しい項目が必要になり、その値を集める担当者も必要になります。例外的なケースには、あらかじめ定められたエンドポイントがあります。買い手がまだシステムに参加していない場合は0235:9900000098、Peppol IDを持たない輸出先の買い手には0235:9900000099、みなし供給には0235:9900000097です。
  • 売り手の法的登録。 登録番号とその種別で、種別は決められたセットから選びます。TL(営業許可)、EID(エミレーツID)、PAS(パスポート)、CD(内閣決定)のいずれかです。商業インボイスでは、買い手の登録も必須です。
  • 構造化された住所。 売り手と買い手の両方について、国の下位区分(首長国)まで含めます。
  • データとしての支払条件。 すべての請求書に、支払期日と支払手段コードが必要です。
  • すべての明細行に、コード化された単位と完全な価格データ。 単位コード、総額単価、正味単価、価格基準数量です。単位を自由テキスト(「pcs」「12個入り」など)で保存している場合は、対応表が必要になります。
  • 明細行ごとの税区分と、区分ごとの内訳。標準税率、非課税、課税対象外、リバースチャージ、ゼロ税率、マージンスキームです。国内リバースチャージの請求書には、説明文と物品の種類も記載します。
  • 金額は常にAED建て。 請求通貨にかかわらず、各明細行のVAT額と支払額をAEDで記載します。外貨建ての請求書には、税務会計通貨と、VAT込み合計額のAED換算額も必要で、換算には中央銀行のレートを使います。
  • 取引種別フラグ。 8つの桁があり、それぞれ1か0です。フリーゾーン、みなし供給、マージンスキーム、サマリーインボイス、継続的供給、開示代理人による請求、Eコマース、輸出です。1枚の請求書に複数のフラグを立てることができ、立てたフラグごとに固有の要件が加わります。たとえばフリーゾーンの顧客には、受益者の詳細も必要です。

独立したテストケースを用意すべきルールが1つあります。端数処理は請求書の合計額で、小数点以下2桁に対して行います。明細行や税区分の単位では行いません。請求処理のコードが行ごと、またはVAT税率ごとに丸めているなら、プロバイダーに指摘される前に実際の請求書で検証してください。

HSN品目コードは当面任意で、必須化の日付はまだ発表されていません。物品を販売しているなら、どのみち品目マスタに手を入れるのですから、この機会に追加しておいてください。

クレジットノート、前受金、留保金

  • 合計がマイナスの請求書は認められません。減額は電子クレジットノートとして発行しなければならず、差し引きで減額になるサマリーインボイスも同じ扱いです。
  • 1枚のクレジットノートで過去の複数の請求書を参照することも、1枚の請求書の一部だけを対象にすることもできます。数量割引は、対応する理由コードを付けたクレジットノートで処理します。
  • 仮請求書という区分はありません。仮請求書はすべて正式な電子インボイスであり、後からクレジットノートまたは追加の請求書で調整します。
  • 前払いを受けたときは、受領時に税務インボイスを発行します。最終請求書は残額だけを対象とし、前払い分の請求書を参照します。
  • 留保金は、留保分を差し引いた額で請求し、留保額の支払期日が来たときに別の請求書を発行する方法で処理できます。

誰もが忘れる受信側

仕入先からの請求書も、同じASPが受け取ります。稼働開始後はそれらがXMLで届き、買掛金に取り込まなければなりません。1つの帳票テンプレートの話ではなく、購買照合や承認に関わるため、作業量はこちらのほうが大きいことがよくあります。

大手の仕入先は2027年1月1日に稼働を開始し、自社の識別子を尋ねてきます。自社が稼働するまでは、仕入先はあらかじめ定められたエンドポイントに送り、通常の税務インボイスも別に渡してくれるので、自社側で何かが止まることはありません。

認定サービスプロバイダーとの付き合い方

財務省の一覧には、2026年10月2日時点で60社の認定プロバイダーが載っていました。オンボーディングを始めるのは、プロバイダーではなく自社です。EmaraTaxのアカウント管理者が電子インボイスのセクションを開いてプロバイダーを選ぶと、そのプロバイダーのポータルに引き継がれます。先に契約を結び、EmaraTax上の会社情報が最新であることを確認しておいてください。

カスタムシステムの場合、プロジェクトの成否を決めるのは技術的な問いです。

  1. 何を受け付けるか。 プロバイダー独自のAPIペイロードか、ファイル交換か、自社で生成したPINT-AEのXMLか。独自形式のほうが当面の作業は少なく済みます。自社でPINT-AEを生成すれば、マッピングを作り直さずにプロバイダーを替えられます。
  2. 確認応答はどう戻ってくるか。 Webhookか、ポーリングか、ファイルか。2種類の確認はどちらも、ASPが割り当てるUUIDとともに請求書レコードに記録すべきものです。
  3. 再送したときに何が起きるか。 タイムアウトは起きます。請求書を再送して2通目ができてはいけないので、重複をどう検出するかを合意し、何を送ったかの記録として自社の送信ログを持ってください。
  4. サンドボックスはあるか。 正常系だけでなく、差し戻しも試せるものかどうか。
  5. 受信する請求書はどう届くか。 自社側が停止している間はどうなるか。
  6. アーカイブを代行してくれるか。 契約次第で可能ですが、保存義務は自社に残ります。記録は、完全で読める状態のままFTAに提出できる限り、UAE国外に置いても構いません。

ガイドラインは、テストで扱うべき範囲を挙げています。ASPへの請求データの送信、買い手への配信、交換の確認、仕入先の請求書の受信、ASPからFTAへの報告、そして報告の確認です。それぞれについて、成功だけでなく失敗の経路もテストしてください。

罰則

罰則は2025年内閣決定第106号で定められています。

  • 制度を導入しないこと(期限内にプロバイダーを選任しないことを含む):1か月ごと(1か月未満の端数も1か月とする)に5,000ディルハム。
  • 電子インボイスまたは電子クレジットノートを発行・送信しないこと:1件につき100ディルハム、上限は暦月あたり5,000ディルハム。
  • システム障害をFTAに通知しないこと、または登録データの変更をASPに伝えないこと:1日につき1,000ディルハム。

いずれも、義務化の日より前に任意で発行した請求書には適用されません。

2027年7月1日までの9か月計画

2026年10月初めの時点で、基準を下回る企業には9か月あります。いま着手すれば、カスタムシステムでも足りる期間です。

  1. 2026年10月から11月:ギャップ分析。 1年分の請求書とクレジットノートを書き出し、区分、シナリオ、税区分、通貨で分類したうえで、各必須項目をどこから取るかを書き留めます。
  2. 2026年11月から12月:プロバイダーの選定。 上記の技術的な問いで候補を絞り、契約し、サンドボックスへのアクセスを得ます。2027年3月31日は最終期限であって、目標ではありません。
  3. 2026年12月から2027年2月:構築。 マスタデータの変更と顧客識別子の収集、マッピング、送信前の検証、確認応答の処理、担当者を決めた失敗キュー、そして受信処理です。
  4. 2027年2月から3月:EmaraTaxでのオンボーディング。 参加者識別子を取得した時点で完了です。3月31日より十分前に終えてください。
  5. 2027年4月から5月:プロバイダーとのエンドツーエンドテスト。 6つのステップすべてを、失敗とクレジットノートも含めて試します。
  6. 2027年5月から6月:任意での稼働開始。 任意の請求書には罰則が適用されないので、最後の問題を見つけるには最も安上がりな場です。順序はプロバイダーと合意してください。
  7. 2027年7月1日:義務化。 最初のVAT申告が終わるまで、失敗キューの担当者を置き続けてください。

大企業の区分に該当していて、まだ着手していないなら、プロバイダーの選任期限は2026年10月30日で、稼働開始までは3か月を切っています。同じステップを数週間に圧縮して進めることになり、プロバイダー独自の入力形式を使うほうがおそらく早道です。

まだ動きうること

日付はすでに一度変わっています。ガイドラインはバージョン1.1で、PINT-AEのバージョンも変わり、プロバイダーは最新版を使うことが義務づけられています。マッピングは自社のインターフェースの背後にある1つのモジュールにまとめ、仕様が更新されても請求処理のコードに手を入れずに済むようにしてください。HSNコードはいずれ必須になり、B2Cが対象外なのも、次の決定が出るまでの話です。

どれも、待つ理由にはなりません。決定はすでに効力を持ち、罰則表も公表されています。

ご相談先

当社は、請求書を作るシステムと、それを送るプロバイダーとの接続を構築しています。データマッピング、マスタデータの変更、検証、確認応答と再送の処理、買掛金への受信処理までが範囲です。進め方は電子インボイス連携サービスでご説明しています。義務化がシステム刷新の途中に重なる場合は、ERPモダナイゼーションもご覧ください。

コネクターをどこも販売していないシステムから請求書を出しているなら、office@c9group.devまでご連絡ください。