Facturation électronique Fawtara à Oman en 2027 : ce dont les ERP et les caisses sur mesure ont besoin

Oman remplace les factures papier et PDF par des factures électroniques en XML structuré, qui transitent par un prestataire de services accrédité et sont déclarées à l'Autorité fiscale d'Oman (OTA). Le programme s'appelle Fawtara. Les contribuables dont les opérations annuelles dépassent 5 millions d'OMR démarrent le 1er avril 2027. Tous les autres contribuables immatriculés à la TVA démarrent le 1er octobre 2027.

C'est dans le commerce de détail que cela fait le plus mal. Les ventes aux consommateurs entrent dans le champ le même jour que les ventes entre entreprises, et chaque vente, sans exception, exige sa propre facture électronique. Si votre logiciel de caisse, votre ERP ou votre moteur de facturation a été développé en interne ou lourdement personnalisé, le travail de production de ces documents vous revient.

Les dates, et celle qui vous concerne

La source est la FAQ Fawtara de l'OTA, mise à jour pour la dernière fois le 31 août 2026. Le critère y est exposé clairement. Vous démarrez le 1er avril 2027 si l'une de ces conditions est remplie :

• vos opérations du 1er avril 2026 au 31 mars 2027 dépassent 5 000 000 OMR, ou
• vos opérations prévues du 1er avril 2027 au 31 mars 2028 dépassent 5 000 000 OMR.

« Si aucune des deux conditions n'est remplie, vous devez mettre en œuvre la facturation électronique à partir du 1er octobre 2027. »

Ce qui entre dans le calcul : les opérations taxables, hors immobilisations, hors biens et services relevant de l'autoliquidation et hors opérations intra-CCG. Un groupe TVA est apprécié au niveau du groupe, et non membre par membre. Un non-résident ne compte que les opérations réalisées à Oman.

Notez la seconde branche. Une entreprise en croissance qui approche les 5 millions d'OMR peut se retrouver dans la cohorte d'avril sur la seule base de ses prévisions. Si vous êtes proche du seuil, partez du principe que ce sera avril.

L'OTA met à disposition un outil de vérification du déploiement qui prend votre VATIN et vos tranches d'opérations actuelle et prévue, et affiche une période de mise en œuvre potentielle. Il est présenté comme destiné uniquement à la sensibilisation et à la préparation : considérez sa réponse comme une indication, et la FAQ comme la règle.

Le calendrier a déjà bougé une fois

La page FAQ en HTML de l'OTA décrit toujours l'ancien plan : cent grandes entreprises à partir d'août 2026, toutes les grandes entreprises à partir de février 2027, tous les autres à partir d'août 2027. Le PDF remplace ces dates par avril et octobre 2027. Pour un premier groupe de grands contribuables sélectionnés (Rollout 1), août 2026 reste la date officielle de démarrage, avec un délai de grâce jusqu'à fin octobre 2026 dans le cadre d'un pilote.

Une phrase de la section calendrier du PDF indique que la conformité obligatoire au-dessus de 5 millions d'OMR prend effet « April 1st 2026 ». Tout le reste du même document dit 1er avril 2027, y compris la réponse détaillée sur le champ citée plus haut. Cela ressemble à une coquille, mais c'est une bonne raison de travailler à partir du document source plutôt que du résumé de qui que ce soit, le nôtre compris.

Comment fonctionne Fawtara

Fawtara s'appuie sur Peppol, selon un modèle à cinq coins :

1. Coin 1 : vous, le vendeur, émettez la facture.
2. Coin 2 : votre prestataire de services accrédité (ASP) la valide au regard des règles omanaises et la transmet.
3. Coin 3 : le prestataire de l'acheteur la reçoit.
4. Coin 4 : l'acheteur.
5. Coin 5 : l'OTA, qui reçoit les données fiscales des prestataires.

Le format est du XML, construit selon les spécifications PINT Oman publiées par OpenPeppol (Billing Process en version 1.0.1 au moment où nous écrivons). La FAQ est catégorique : « une facture PDF n'est pas une facture électronique ». Vous pouvez toujours imprimer sur papier, mais seule la facture électronique est une facture valable sur le plan fiscal.

Trois détails de la FAQ orientent l'ingénierie :

• Votre prestataire valide, vous restez responsable. L'ASP contrôle chaque facture au regard des règles Schematron omanaises, mais « la responsabilité de la conformité des factures reste celle des contribuables ».
• Vous vous raccordez à un seul prestataire à la fois. Vous demandez la liaison par le portail Fawtara et vous pouvez en changer par la suite.
• Il n'existe pas d'API standard pour les contribuables. Selon les termes de la FAQ, le raccordement d'un contribuable « n'est pas normalisé et variera selon le système du prestataire ». Votre ERP dialogue avec l'interface de votre prestataire, pas avec l'OTA.

Lorsque l'acheteur est un consommateur ou une entreprise qui n'est pas encore sur le réseau, votre prestataire déclare tout de même les données fiscales à l'OTA, et le client reçoit la facture comme aujourd'hui. Les exportations vont de vous à votre prestataire, puis à l'OTA.

Qui est déjà couvert

Si l'éditeur de votre ERP ou de votre caisse est lui-même un prestataire accrédité, ou livre un connecteur vers l'un d'eux, l'essentiel de cet article ne vous concerne pas. La FAQ indique que les systèmes ERP « peuvent être conservés selon l'arrangement que les contribuables ont conclu avec leurs prestataires de services accrédités », et pour un progiciel, c'est à l'éditeur de livrer cet arrangement. Votre travail porte sur les données de référence et les tests.

Vous pourriez aussi devenir votre propre prestataire. Les critères d'accréditation comprennent une immatriculation commerciale omanaise avec des activités informatiques, un capital libéré minimum, un historique d'activité et une certification ISO/IEC 27001, et la FAQ y ajoute la réussite des suites de tests Peppol eDelivery et PINT OM. Cela convient aux éditeurs de logiciels. Ce n'est pas un raccourci pour un commerçant.

Cet article s'adresse à tous les autres : les entreprises dont les factures sortent d'un ERP sur mesure, d'un système de caisse maison, d'un moteur de facturation greffé sur une vieille base de données, ou d'une agence qui rédige encore ses factures à la main.

Ce qui doit changer dans votre logiciel

Mettre vos données de facture en correspondance avec PINT Oman

Les consignes de la FAQ sur le mapping tiennent en une ligne : utilisez les spécifications PINT d'Oman. Dans le modèle sémantique, ce sont les champs propres à Oman (préfixés BTOM) qui concentrent l'essentiel de l'effort :

• Un UUID pour chaque document (BTOM-002). Il doit être conforme à la RFC 4122 version 5, c'est-à-dire fondé sur un nom. Dérivez-le de quelque chose de stable, comme l'entité juridique, l'agence, la caisse et le numéro de document, et une soumission renvoyée produira le même UUID au lieu d'une seconde facture.
• Un type de transaction de facture (BTOM-001). C'est une chaîne de 20 positions dont chaque position est un indicateur : facture fiscale complète, facture fiscale simplifiée, autofacturation, facturation par un tiers, export, livraison présumée, autoliquidation sur importation de services, régime de la marge, e-commerce, importation de biens, livraison en zone spéciale, acompte, et d'autres. Plusieurs indicateurs peuvent être activés à la fois. Votre système doit savoir lesquels s'appliquent à chaque facture, et la plupart des ERP ne l'ont jamais stocké.
• Les identifiants du vendeur et de l'acheteur, avec un code de schéma : immatriculation commerciale, numéro d'identification fiscale, carte d'identité civile, passeport, identifiant douanier d'importateur ou numéro de licence de zone spéciale.
• La devise. La devise de facturation, la devise de comptabilisation de la TVA, le taux de change entre les deux et le total de TVA dans la devise de comptabilisation ont chacun leur propre champ.
• Des listes de codes pour l'exonération de TVA, les motifs de taux zéro, les types de services et les subdivisions du pays.

Attendez-vous à ce que les lignes de facture se mappent proprement et les données de référence beaucoup moins. Les fiches clients sans VATIN, les numéros d'immatriculation commerciale manquants, les motifs d'exonération en texte libre et les adresses sans code de région doivent tous être nettoyés avant la première facture en production.

Traiter chaque vente comme un document

C'est la règle qui change les systèmes de caisse : « Les factures récapitulatives ne sont pas autorisées pour les transactions B2C. Une facture électronique doit être émise séparément pour chaque facture. » Pas de récapitulatif de fin de journée. Une boutique qui enregistre 3 000 ventes par jour envoie 3 000 factures électroniques par jour.

La FAQ donne 24 heures pour les soumissions B2C et exige le temps réel pour le B2B. Pour une caisse, cela signifie :

• La caisse construit le XML (ou confie la vente à un service qui le fait) au moment de la vente, avec son UUID. Il existe un champ UUID de ticket distinct pour le B2C (BTOM-004).
• Une file de stockage et retransmission conserve les documents quand le réseau ou le prestataire est indisponible, et les écoule dans les 24 heures.
• Quelqu'un est alerté quand un document n'est toujours pas parti au bout de quelques heures, pas au bout de vingt-trois.

Confrontez la tarification des prestataires à votre volume avant de signer. La FAQ précise que chaque prestataire fixe son propre modèle, qui « peut comprendre des frais d'abonnement, des frais par transaction ou d'autres modalités tarifaires ». Aux volumes du commerce de détail, des frais par document représentent une ligne du budget.

Le B2B en temps réel

Pour les factures entre entreprises, la soumission se fait en temps réel. Votre ERP poste la facture, le prestataire la valide, et le résultat revient. Cela change le circuit de facturation de deux façons. Les erreurs de validation apparaissent désormais au moment de la comptabilisation : quelqu'un au service financier a donc besoin d'un écran qui affiche le rejet et permet de le corriger. Et la numérotation des factures, l'UUID et la logique de renvoi doivent être justes dès le premier jour, car un délai d'attente dépassé suivi d'un renvoi à l'aveugle, c'est ainsi que naissent les factures en double.

Le flux va aussi dans l'autre sens. Quand vous êtes l'acheteur, les factures électroniques des fournisseurs déjà sur Fawtara arrivent en XML par votre prestataire, et la comptabilité fournisseurs doit pouvoir les intégrer.

Les QR codes sur le ticket imprimé

Le QR code est généré par vous (coin 1), pas par le prestataire. Il est obligatoire pour toutes les transactions B2C, complètes ou simplifiées, et il figure sur la facture lisible par un humain, pas dans le XML. L'OTA prévoit de l'utiliser pour vérifier les factures au moyen d'une application mobile. Pour son contenu, la FAQ renvoie à l'annexe D du document d'architecture Peppol Oman (version 1.0.2) : procurez-vous cette annexe avant que quiconque ne redessine un ticket. Les modèles de tickets et les pilotes d'imprimantes font partie du projet.

Avoirs, retours et corrections

Une fois émise, une facture électronique se corrige par l'émission d'un avoir ou d'une note de débit électronique. La spécification prévoit des champs pour l'UUID de la facture d'origine et un code motif (BTOM-031 et BTOM-032) : un remboursement en caisse doit donc pouvoir retrouver la vente d'origine.

Importations et autofacturation

Les importations de biens et de services sont déclarées sous forme d'autofactures. Si votre circuit d'achats comptabilise les importations sans émettre aucun document, une nouvelle étape y apparaît.

L'archivage

Le stockage reste à votre charge. La FAQ précise que l'OTA ne restituera pas les informations de facturation aux contribuables, et Peppol ne stocke pas les documents. Conservez ensemble le XML validé, la réponse du prestataire et la version imprimée, selon les règles de conservation de la législation sur la TVA.

Un plan à rebours depuis l'échéance

La FAQ indique que l'OTA contacte les participants au déploiement au moins six mois avant leur intégration. Pour la cohorte d'avril, c'est maintenant.

Si vous démarrez le 1er avril 2027 :

1. Octobre 2026 : confirmez votre cohorte avec l'outil de vérification et le critère de la FAQ. Recensez tous les systèmes qui émettent une facture : ERP, chaque caisse, tunnel de paiement e-commerce, facturation de location ou d'abonnement, et tout carnet de factures manuel.
2. Novembre 2026 : choisissez un prestataire. Demandez la documentation de l'API et un environnement de test avant de signer, et interrogez-le sur les volumes B2C, le prix par document, la gestion hors ligne et la forme des réponses de validation. Demandez la liaison par le portail Fawtara.
3. De décembre 2026 à janvier 2027 : développement. Mapping des champs, génération des UUID, logique des types de transaction, file d'attente des caisses, QR codes, circuit des avoirs, factures entrantes. Faites tourner les règles Schematron omanaises issues des téléchargements PINT Oman dans votre propre chaîne de tests, pour que les échecs apparaissent en développement et non chez le prestataire.
4. Février 2027 : tests de bout en bout dans l'environnement de test du prestataire, avec de vrais échantillons de chaque type de transaction que vous émettez réellement, y compris les cas épineux (exportations, retours sans ticket, devises étrangères).
5. Mars 2027 : une répétition en production avec une agence ou une ligne d'activité, un plan de bascule et un planning d'assistance pour les premières semaines.

Si vous démarrez le 1er octobre 2027, la séquence est la même, décalée de six mois : prestataire choisi d'ici la fin du premier trimestre, développement au deuxième, tests terminés en août. Ne gaspillez pas la marge. Le nettoyage des données prend toujours plus de temps que prévu.

Ce qui reste incertain

Les dates ont bougé une fois et pourraient encore bouger. Planifiez selon le PDF daté du 31 août 2026, et consultez chaque mois les documents de l'OTA plutôt que de vous fier à la presse. La base juridique est la décision 189/2026, qui modifie le règlement d'application de la loi sur la TVA. La FAQ indique que des sanctions s'appliqueront en vertu de la législation sur la TVA dès l'entrée en vigueur de l'obligation, mais n'en précise pas les montants : nous ne le faisons donc pas non plus.

Les spécifications sont elles aussi versionnées. Le paquet PINT Oman actuellement publié sur le site de Peppol porte une date de publication au 29 juillet 2026. Figez la version sur laquelle vous développez, et suivez les notes de version.

Où trouver de l'aide

Nous construisons le connecteur entre le système que vous faites réellement tourner et le format qu'impose l'obligation : mapping des champs, logique des UUID et de la numérotation, files d'attente des caisses, validation dans votre chaîne de développement, et intégration avec le prestataire que vous choisissez. Notre service d'intégration de la facturation électronique couvre ce travail, et quand c'est l'ERP lui-même qui fait obstacle, la modernisation d'ERP est le point de départ.

Si vous faites partie de la cohorte d'avril et n'avez pas encore choisi de prestataire, écrivez à office@c9group.dev.