オマーンの電子インボイスFawtara、2027年開始：独自のERPとPOSに必要なこと

山を背にしたマスカットのマトラ海岸

オマーンは、紙やPDFの請求書を、認定サービスプロバイダーを経由してオマーン税務庁（OTA）に報告される構造化XMLの電子インボイスに置き換えようとしています。この制度はFawtaraと呼ばれます。年間の供給額が500万オマーン・リアル（OMR）を超える納税者は 2027年4月1日 に、それ以外のすべてのVAT登録納税者は 2027年10月1日 に開始します。

最も影響が大きいのは小売です。消費者向けの販売も事業者向けと同じ日から対象になり、販売1件ごとに個別の電子インボイスが必要です。レジのソフトウェア、ERP、請求エンジンを自社で開発したか、大きくカスタマイズしているなら、そうした文書を出力する作業は自社の仕事です。

日程と、自社に適用されるのはどちらか

根拠は、2026年8月31日に最終更新されたOTAのFawtara FAQです。判定基準ははっきり書かれています。次のいずれかに当てはまれば、2027年4月1日から導入します。

2026年4月1日から2027年3月31日までの供給額が500万リアルを超える。
2027年4月1日から2028年3月31日までの見込み供給額が500万リアルを超える。

「どちらにも当てはまらない場合は、2027年10月1日から電子インボイスを導入する必要がある」とされています。

金額に算入されるのは、資本的資産、リバースチャージの対象となる物品とサービス、GCC域内の供給を除いた課税供給です。VATグループは、メンバーごとではなくグループ単位で判定されます。非居住者は、オマーン国内で行った供給だけを算入します。

2つ目の条件に注意してください。500万リアルに向けて成長している事業者は、見込みだけで4月の組に入ることがあります。基準に近いなら、4月だと考えておいてください。

OTAは、VATINと現在および見込みの供給額の区分を入力すると、導入時期の見込みを表示する導入時期の確認ツールを提供しています。このツールは周知と準備のためのものとされているので、その結果は目安として扱い、ルールとしてはFAQに従ってください。

日程はすでに一度動いている

OTA自身のHTML版FAQページには、いまも古い計画が載っています。2026年8月から大企業100社、2027年2月からすべての大企業、2027年8月からそれ以外のすべて、というものです。PDF版はこれらの日付を2027年4月と10月に置き換えています。選定された大規模納税者の第1グループ（Rollout 1）については、2026年8月が引き続き公式の稼働開始日で、パイロットの一環として2026年10月末までの猶予期間があります。

PDF版のスケジュールの節には、500万リアル超の義務化が「April 1st 2026」（2026年4月1日）から有効だと書かれた一文があります。同じ文書のほかの箇所は、上で引用した詳細な対象範囲の回答も含め、すべて2027年4月1日としています。誤記と読めますが、誰かの要約（当社のものも含めて）ではなく一次資料に基づいて作業すべき理由として十分です。

Fawtaraの仕組み

FawtaraはPeppolの上で動き、5コーナーモデルを使います。

コーナー1：売り手である自社が請求書を発行します。
コーナー2：自社の認定サービスプロバイダー（ASP）がオマーンのルールで検証し、次に渡します。
コーナー3：買い手のサービスプロバイダーが受け取ります。
コーナー4：買い手。
コーナー5：OTAが、サービスプロバイダーから税務データを受け取ります。

フォーマットはXMLで、OpenPeppolが公開しているPINT Omanの仕様（執筆時点ではBilling Processのバージョン1.0.1）に沿って作ります。FAQは「PDFの請求書は電子インボイスではない」とはっきり書いています。紙に印刷することは引き続きできますが、税務上有効な請求書は電子インボイスだけです。

FAQにある3つの点が、技術的な設計を左右します。

検証するのはプロバイダー、責任を負うのは自社。 ASPはオマーンのSchematronルールで各請求書を検査しますが、「請求書の適合性に関する責任は納税者に残る」とされています。
接続するプロバイダーは一度に1社。 Fawtaraポータルで接続を申請し、後から切り替えることもできます。
納税者向けの標準APIはない。 FAQの言葉では、納税者との接続は「標準化されておらず、サービスプロバイダーのシステムによって異なる」とされています。ERPがやり取りするのはOTAではなく、プロバイダーのインターフェースです。

買い手が消費者や、まだネットワークに参加していない事業者の場合も、プロバイダーは税務データをOTAに報告し、顧客は現在と同じ方法で請求書を受け取ります。輸出は、自社からプロバイダー、プロバイダーからOTAへと流れます。

すでに対応できている企業

ERPやPOSのベンダー自身が認定プロバイダーであるか、認定プロバイダーへのコネクターを提供しているなら、この記事の大部分は自社の問題ではありません。FAQは、ERPシステムは「納税者と認定サービスプロバイダーとの取り決めに基づいて維持できる」としており、パッケージシステムの場合、その取り決めを実現するのはベンダーです。自社の作業はマスタデータとテストです。

自社がサービスプロバイダーになるという道もあります。認定基準には、IT事業を含むオマーンの商業登記、最低払込資本、事業実績、ISO/IEC 27001認証などが含まれ、FAQはさらにPeppol eDeliveryとPINT OMのテストスイートの合格を挙げています。ソフトウェア会社には向いていますが、小売業者にとっての近道ではありません。

この記事はそれ以外のすべての企業のためのものです。請求書を独自のERP、自社開発のレジシステム、古いデータベースに後付けした請求エンジンから出している企業や、いまも手書きで請求書を作っている支店がある企業です。

ソフトウェアで変えなければならないこと

請求データをPINT Omanに対応づける

マッピングについてのFAQの指針は、オマーンのPINT仕様を使うこと、の1行だけです。意味モデルでは、オマーン固有の項目（接頭辞BTOM）に作業の大半が費やされます。

すべての文書にUUID（BTOM-002）。RFC 4122のバージョン5、つまり名前ベースのものでなければなりません。法人、支店、レジ、文書番号のような変わらないものから導出すれば、送信を再試行しても2通目の請求書ではなく同じUUIDになります。
請求取引種別（BTOM-001）。各桁がフラグになっている20桁の文字列で、完全な税務インボイス、簡易税務インボイス、自己請求、第三者による請求、輸出、みなし供給、サービス輸入のリバースチャージ、利益マージン、Eコマース、物品の輸入、特別区域での供給、前払いなどがあります。複数のフラグを立てられます。システムは、各請求書にどれが当てはまるかを知っていなければならず、ほとんどのERPはそれを保存したことがありません。
売り手と買い手の識別子とスキームコード。商業登記、納税者番号、市民ID、パスポート、輸入者の税関ID、特別区域の許可番号です。
通貨。 請求通貨、VAT会計通貨、その間の為替レート、会計通貨でのVAT合計に、それぞれ独自の項目があります。
コードリスト。 VATの非課税、ゼロ税率の理由、サービスの種別、国の下位区分のためのものです。

請求書の明細行はきれいに対応づけられても、マスタデータはそうはいかないと考えておいてください。VATINのない顧客レコード、欠けているCR番号、自由テキストの非課税理由、地域コードのない住所は、最初の本番請求書より前にすべて整備しなければなりません。

販売1件ごとに文書として扱う

POSシステムを変えるのはこのルールです。「B2C取引ではまとめ請求書は認められない。請求書ごとに個別に電子インボイスを発行しなければならない」。日次の集計はありません。1日に3,000件を売り上げる店舗は、1日に3,000通の電子インボイスを送ります。

FAQは、B2Cの送信期限を 24時間、B2Bの送信を リアルタイム としています。レジにとっては次のことを意味します。

POSが販売の時点でUUID付きのXMLを組み立てる（または、それを行うサービスに販売を渡す）。B2Cには、別にレシートのUUIDの項目（BTOM-004）があります。
ネットワークやプロバイダーが止まっているときは、ストア・アンド・フォワードのキューが文書を保持し、24時間以内に送り切る。
文書が送れないままになっているときは、23時間後ではなく数時間後に誰かにアラートが届く。

契約する前に、プロバイダーの料金を自社の件数に照らして確認してください。FAQによれば料金体系は各プロバイダーが決め、「サブスクリプション料金、取引件数に応じた料金、その他の料金体系を含みうる」とされています。小売の件数では、文書ごとの料金は予算の1項目になります。

リアルタイムのB2B

事業者向けの請求書は、リアルタイムで送信します。ERPが請求書を計上し、プロバイダーが検証し、結果が戻ってきます。これは請求のワークフローを2つの点で変えます。検証エラーが計上の瞬間に表に出るようになるので、経理の誰かに、差し戻しを表示して修正できる画面が必要です。そして、請求書の採番、UUID、再試行のロジックは初日から正しくなければなりません。タイムアウトの後にやみくもに再送することが、重複した請求書が生まれる原因だからです。

流れは逆方向にもあります。自社が買い手になるときは、すでにFawtaraに参加している仕入先からの電子インボイスがプロバイダーを通じてXMLで届き、買掛金にはそれを取り込む方法が必要です。

印刷したレシートのQRコード

QRコードを生成するのはプロバイダーではなく自社（コーナー1）です。QRコードは、完全か簡易かを問わずすべてのB2C取引で必須で、XMLの中ではなく人が読む請求書に載ります。OTAは、モバイルアプリで請求書を検証するのにこれを使う予定です。内容について、FAQはPeppol Oman Architecture文書（バージョン1.0.2）の付録Dを参照するよう示しています。誰かがレシートのデザインを変える前に、その付録を入手してください。レシートのテンプレートとプリンタードライバーも、このプロジェクトの一部です。

クレジットノート、返品、訂正

発行済みの電子インボイスは、電子クレジットノートまたは電子デビットノートを発行して調整します。仕様には元の請求書のUUIDと理由コードの項目（BTOM-031とBTOM-032）があるので、レジでの返金処理は元の販売を探し出せなければなりません。

輸入と自己請求

物品とサービスの輸入は、自己請求書として報告します。調達の流れで、文書を一切作らずに輸入を計上しているなら、そこに新しい手順が加わります。

保存

保存は自社の責任のままです。FAQによれば、OTAは請求書の情報を納税者に返すことはせず、Peppolも文書を保存しません。検証済みのXML、プロバイダーの応答、印刷した版をまとめて、VAT法令の保存ルールに従って保管してください。

期限から逆算した計画

FAQによれば、OTAは導入対象者に対し、オンボーディングの少なくとも6か月前に連絡します。4月の組にとっては、それはいまです。

2027年4月1日に開始する場合：

2026年10月：導入時期の確認ツールとFAQの判定基準で、自社の組を確認します。請求書を発行するすべてのシステムを洗い出します。ERP、各POS、ECの決済画面、レンタルやサブスクリプションの請求、手書きの請求書帳です。
2026年11月：プロバイダーを選びます。契約前にAPIのドキュメントとサンドボックスを求め、B2Cの件数、文書ごとの料金、オフライン時の扱い、検証の応答がどんな形かを尋ねます。Fawtaraポータルで接続を申請します。
2026年12月から2027年1月：構築します。項目のマッピング、UUIDの生成、取引種別のロジック、POSのキュー、QRコード、クレジットノートの流れ、受信する請求書です。PINT Omanのダウンロード資料にあるオマーンのSchematronルールを自社のテストパイプラインで実行し、不合格がプロバイダーではなく開発の段階で出るようにします。
2027年2月：実際に発行するすべての取引種別の実サンプルを使い、扱いにくいもの（輸出、レシートなしの返品、外貨）も含めて、プロバイダーのサンドボックスでエンドツーエンドのテストを行います。
2027年3月：1つの支店または事業部門で本番のリハーサルを行い、切り替え計画と、最初の数週間のサポート当番表を用意します。

2027年10月1日に開始する場合も、手順は同じで、6か月後ろにずれるだけです。第1四半期の終わりまでにプロバイダーを選び、第2四半期に構築し、8月までにテストを終えます。余裕を使い切らないでください。データの整備は、いつも誰の見積もりよりも時間がかかります。

まだ不確かなこと

日付は一度動いており、また動く可能性があります。2026年8月31日付のPDFに沿って計画し、ニュース記事に頼らずに毎月OTAの文書を確認してください。法的な根拠は、VAT法の施行規則を改正する決定189/2026です。FAQは、義務化が始まればVAT法令に基づいて罰則が適用されるとしていますが、金額は挙げていないので、当社もここでは挙げません。

仕様にもバージョンがあります。Peppolのサイトにある現在のPINT Omanのパッケージは、リリース日が2026年7月29日です。構築の基準にするバージョンを固定し、リリースノートを追ってください。

ご相談先

当社は、実際に運用しているシステムと、義務化が求めるフォーマットとの間をつなぐコネクターを構築しています。項目のマッピング、UUIDと採番のロジック、POSのキュー、パイプラインでの検証、そして選んだプロバイダーとの連携です。この仕事は電子インボイス連携サービスで扱っており、ERPそのものが障害になっている場合はERPモダナイゼーションから始めます。

4月の組に該当していて、まだプロバイダーを選んでいないなら、office@c9group.devまでご連絡ください。