Formats de la Facture Électronique au Maroc : UBL 2.1, CII et PDF

La réponse courte. La facture électronique au Maroc doit être un fichier XML structuré, pas un PDF. Les sources concordent sur deux formats : UBL 2.1 (norme OASIS) et CII (norme UN/CEFACT). Le reste (notamment l'obligation ou non d'y joindre un PDF/A-3 lisible par un humain) fait l'objet d'affirmations contradictoires selon les prestataires, et aucune spécification officielle n'a été publiée au Bulletin Officiel à ce jour. Ce guide distingue ce qui fait consensus de ce qui ne repose sur aucune source vérifiable, et vous donne de quoi interroger sérieusement un éditeur.

Pourquoi un PDF ne suffit pas

C'est le malentendu le plus répandu, et il coûte cher parce qu'il donne l'illusion d'être déjà en conformité.

Une facture au format PDF (même envoyée par e-mail, même signée électroniquement) n'est pas une facture électronique au sens de la réforme. La raison est technique et non administrative : la plateforme de la DGI doit lire et contrôler automatiquement le contenu de chaque facture avant de la valider. Un PDF est conçu pour être lu par un humain ; les données y sont positionnées visuellement, pas structurées.

Un fichier XML structuré, à l'inverse, expose chaque donnée dans un champ identifié : identifiant du vendeur, identifiant de l'acheteur, ligne de facture, taux de TVA, montant. C'est ce qui permet un contrôle automatisé à l'échelle de millions de factures.

La conséquence pratique : si votre logiciel actuel « exporte en PDF », cela ne vous avance à rien pour la conformité. La question à poser à votre éditeur n'est pas « peut-on envoyer les factures par e-mail » mais « produisez-vous de l'UBL 2.1 ou du CII ».

UBL 2.1 : le format le plus cité

UBL (Universal Business Language) est une norme XML standardisée par l'OASIS. C'est le format le plus largement déployé à l'international, notamment dans l'Union européenne, et c'est celui que les sources marocaines citent en premier, plusieurs le présentent même comme le format de référence de la plateforme nationale.

La version attendue est UBL 2.1.

Concrètement, une facture UBL décrit dans un arbre XML : l'émetteur et le destinataire (avec leurs identifiants), les références du document, chaque ligne de facturation, les taxes appliquées et les totaux. Un éditeur qui maîtrise déjà UBL pour un autre marché a une bonne partie du chemin faite, mais pas la totalité, car les règles de gestion nationales (mentions obligatoires, identifiants marocains) restent à intégrer.

CII : l'alternative UN/CEFACT

CII (Cross-Industry Invoice) est l'autre format XML cité, standardisé par l'UN/CEFACT. Il remplit la même fonction qu'UBL avec une structure différente, et il est également répandu à l'international.

Sur ce point, les sources divergent, et c'est important de le noter :

• Plusieurs prestataires et cabinets indiquent que UBL 2.1 et CII sont tous deux acceptés ;
• Au moins un éditeur affirme qu'UBL 2.1 est le format unique retenu par la DGI.

Aucune des deux affirmations ne s'appuie sur un texte officiel publié. En pratique, cela ne change pas grand-chose à votre préparation : un système capable de produire de l'UBL 2.1 couvre le scénario le plus probable, et l'essentiel du travail (structurer les données, fiabiliser les identifiants) est commun aux deux formats.

Le point contesté : le PDF/A-3 est-il obligatoire ?

C'est ici que les contenus disponibles se contredisent le plus franchement, et il vaut la peine de s'y arrêter.

PDF/A-3 est un format PDF particulier : il permet d'embarquer un fichier (ici, le XML) à l'intérieur du document PDF. On obtient un document unique, lisible par un humain à l'écran, et contenant les données structurées exploitables par une machine. C'est le principe du format hybride Factur-X, utilisé en France.

Ce que l'on trouve publié à ce sujet :

Autrement dit : l'exigence la plus contraignante est aussi la moins sourcée. Nous n'affirmons pas qu'elle est fausse : elle peut très bien figurer dans les spécifications finales. Nous constatons simplement qu'elle n'est aujourd'hui étayée par aucun texte publié, et qu'un choix d'outil ne devrait pas se faire sur cette seule base.

La position raisonnable : privilégiez un éditeur capable de produire le XML structuré et de générer une représentation lisible du document. Vous couvrez alors les deux scénarios sans surpayer une fonctionnalité présentée comme obligatoire alors qu'elle n'est pas documentée.

Ce que le format implique réellement pour votre système

Le format n'est pas qu'une case à cocher : il impose des contraintes en amont, dans vos données.

Ce sont des exigences sur vos données, distinctes des obligations de transmission et d'archivage que couvre le guide principal :

Regardez cette liste avec votre organisation actuelle en tête. Si vos factures sortent d'un tableur, ou d'un logiciel où l'ICE client est un champ libre parfois vide, le format n'est pas votre premier problème : vos données le sont. C'est le point que la plupart des contenus disponibles passent sous silence, parce qu'il ne se règle pas en achetant un outil. Nous le traitons en détail dans ICE, archivage et intégrité : vos données sont-elles prêtes ?, avec un test que vous pouvez faire vous-même en une journée.

Comment vérifier qu'un logiciel est réellement prêt

Sept questions à poser à un éditeur, et ce qu'une bonne réponse ressemble :

1. « Produisez-vous de l'UBL 2.1 ? Pouvez-vous me montrer un fichier d'exemple ? » Un éditeur prêt sort un XML en trente secondes. Une réponse évasive est une réponse.
2. « Gérez-vous aussi le CII ? » Non n'est pas rédhibitoire, mais la réponse indique le niveau de maturité.
3. « Comment gérez-vous les rejets de la plateforme ? » Il faut un traitement des factures refusées : correction, réémission, traçabilité. C'est souvent le maillon faible.
4. « L'ICE du client est-il un champ obligatoire et contrôlé chez vous ? » S'il est optionnel, vous découvrirez le problème au premier rejet massif.
5. « Quel est votre plan de raccordement à l'API de la DGI ? » La bonne réponse décrit une architecture prête à se connecter, pas une connexion déjà en place : l'API officielle n'est pas publiée.
6. « Comment assurez-vous l'archivage sur 10 ans ? » Une sauvegarde n'est pas un archivage à valeur probante.
7. « Que se passe-t-il si les spécifications finales diffèrent de vos hypothèses ? » Une réponse honnête existe : « nous adapterons le connecteur ». Une promesse de conformité déjà acquise à une norme non publiée n'en est pas une.

Et la contre-question à garder en tête : aucun éditeur ne peut être « certifié conforme » tant que la DGI n'a pas publié l'API et les spécifications finales. Toute affirmation contraire est du marketing, pas de la conformité.

Et si tout partait déjà de votre ERP ?

La logique de cet article mène à une conclusion simple : le format XML n'est que la sortie d'un système. Si vos données de facturation, vos clients, vos produits et votre TVA vivent déjà dans un ERP correctement paramétré, produire de l'UBL 2.1 devient une question de connecteur. S'ils vivent dans trois outils et deux tableurs, le format sera le moindre de vos soucis.

C'est le sujet traité dans notre guide facturation électronique au Maroc : ce qui est officiel, qui replace ces exigences techniques dans le calendrier réglementaire, en distinguant là aussi les faits vérifiables des dates non sourcées.

Côté mise en œuvre, notre travail de localisation marocaine d'Odoo consiste précisément à faire vivre le PCGE, la CNSS, la CIMR, l'AMO et les exigences de la DGI dans le système de gestion lui-même, plutôt que dans des outils juxtaposés. Le guide complet Odoo Maroc détaille cette approche.

Questions Fréquentes

Quel format de facture électronique est obligatoire au Maroc ?

Les sources disponibles convergent sur deux formats XML structurés : UBL 2.1, norme OASIS, et CII, norme UN/CEFACT. UBL 2.1 est le plus fréquemment cité comme format de référence de la plateforme nationale. Aucune spécification technique définitive n'ayant été publiée au Bulletin Officiel à ce jour, ces éléments doivent être considérés comme l'état de la place et non comme un texte réglementaire.

Un PDF signé électroniquement est-il accepté ?

Non. Un PDF, même signé, n'est pas un format structuré : les données y sont positionnées pour l'œil humain et non exposées dans des champs exploitables par une machine. La plateforme de la DGI doit contrôler automatiquement chaque facture, ce qui suppose un fichier XML. C'est l'écart que la plupart des organisations sous-estiment.

Le PDF/A-3 est-il obligatoire en plus du XML ?

C'est contesté. Au moins un éditeur marocain présente le couple XML + PDF/A-3 comme un format hybride obligatoire, sur le modèle du Factur-X français. D'autres sources ne mentionnent que UBL 2.1 et CII, sans exigence de PDF/A-3. Aucune de ces affirmations ne cite de texte officiel. En pratique, choisir un outil capable de produire le XML et une représentation lisible du document couvre les deux scénarios.

Quelle est la différence entre UBL 2.1 et CII ?

Ce sont deux normes XML qui décrivent la même chose (une facture) avec des structures différentes. UBL (Universal Business Language) est standardisée par l'OASIS et très répandue en Europe. CII (Cross-Industry Invoice) est standardisée par l'UN/CEFACT. Pour une entreprise, le choix relève de l'éditeur : ce qui compte est que votre système sache produire au moins l'un des deux correctement, avec des données fiables.

Mon logiciel actuel exporte en XML : est-ce suffisant ?

Pas nécessairement. « Exporter en XML » ne veut rien dire en soi : c'est la conformité au schéma UBL 2.1 ou CII qui compte, avec les bons champs, les bons identifiants et les bonnes règles de gestion. Demandez un fichier d'exemple et faites-le valider contre le schéma. Un export XML maison ne passera pas un contrôle automatisé.

Par quoi commencer si je ne sais pas où j'en suis ?

Par vos données, pas par votre logiciel. Vérifiez que l'ICE de vos clients est présent, unique et exact ; que vos référentiels produits et vos taux de TVA sont propres ; que votre numérotation est séquentielle et sans trou. Ces chantiers gardent leur valeur quel que soit le format finalement retenu et quelle que soit la date d'entrée en vigueur.