Format UBL 2.1 pour la facture électronique au Maroc : guide technique DGI

UBL 2.1 (Universal Business Language) est l'un des formats structurés les plus répandus pour l'échange de factures électroniques à l'international. Au Maroc, la DGI s'inscrit dans cette logique d'interopérabilité en prévoyant l'UBL 2.1 comme format XML de référence dans la charte de facturation électronique. Pour les éditeurs de logiciels, intégrateurs ERP et responsables conformité, maîtriser ce standard conditionne la capacité à produire des factures acceptées par la plateforme nationale. Ce guide présente la structure UBL, le mapping des champs obligatoires marocains et les pièges d'implémentation les plus courants.

Pourquoi la DGI retient UBL 2.1 pour le Maroc

Le choix d'UBL 2.1 répond à un double objectif : standardisation internationale et richesse sémantique. UBL est maintenu par OASIS, adopté dans de nombreuses réformes européennes et compatible avec les outils de validation XSD largement disponibles. Pour la DGI, un format normalisé facilite l'agrément des éditeurs, réduit les coûts d'intégration pour les groupes multi-pays et accélère les contrôles automatiques sur la plateforme nationale. La charte DGI définit un profil d'application marocain : sous-ensemble de champs UBL obligatoires, règles de cardinalité, codifications spécifiques (ICE, IF, taux TVA) et extensions éventuelles pour les besoins locaux.

UBL coexiste généralement avec d'autres formats comme le CII (Cross Industry Invoice) et Factur-X. Votre logiciel n'a pas besoin de tous les produire : il doit supporter au minimum le format prescrit par la charte ou offrir une conversion fiable. Comparez les options dans nos articles dédiés au format CII et à Factur-X pour arbitrer selon votre stack technique.

Structure d'une facture UBL 2.1 conforme

Une facture UBL 2.1 est un document XML dont la racine est typiquement `Invoice` pour une facture standard ou `CreditNote` pour un avoir. Les blocs principaux sont : `cbc:ID` (numéro de facture), `cbc:IssueDate` (date d'émission), `cac:AccountingSupplierParty` et `cac:AccountingCustomerParty` (émetteur et destinataire), `cac:TaxTotal` et `cac:LegalMonetaryTotal` (montants et TVA), `cac:InvoiceLine` (lignes de détail). Chaque bloc porte des identifiants normalisés que la plateforme DGI contrôle automatiquement. Les mentions obligatoires marocaines se traduisent par un mapping précis de ces éléments UBL vers les référentiels fiscaux locaux.

• En-tête : numéro, date, devise (MAD), type de document
• Parties : raison sociale, adresse, IF, ICE émetteur et client
• Lignes : description, quantité, prix unitaire HT, taux et montant TVA
• Totaux : montant HT, TVA par taux, montant TTC
• Références : commande, bon de livraison, facture d'origine pour les avoirs
• Extensions : éléments spécifiques charte DGI si définis

Mapping ICE et identifiants fiscaux en UBL

L'ICE marocain à 15 chiffres et l'identifiant fiscal doivent être positionnés dans les schémas d'identification des parties (`cac:PartyIdentification` / `cbc:ID` avec schemeID approprié). Une erreur de schemeID ou un ICE tronqué provoque un rejet immédiat en clearance. Les éditeurs doivent documenter ce mapping pour leurs clients et le tester sur des jeux de données réels avant la mise en production. Croisez vos règles avec le guide d'émission conforme et les contrôles listés dans l'article sur les erreurs fréquentes.

Validation XSD, tests et intégration connecteur

Avant toute transmission à la plateforme DGI, le fichier UBL doit passer une validation XSD contre le schéma officiel du profil marocain. Cette validation structurelle est nécessaire mais pas suffisante : des factures XSD-valides peuvent être rejetées pour incohérence métier (total TTC incorrect, TVA mal ventilée). Mettez en place une recette automatisée : jeux de tests couvrant facture simple, multi-taux, remise, acompte, avoir et facture rectificative. Chaque scénario doit produire un XML UBL, obtenir l'accusé plateforme et vérifier la présence du QR code et de l'UUID en sortie.

L'intégration avec la signature électronique intervient après génération du XML et avant envoi. Selon la charte, la signature peut porter sur le document UBL ou sur un conteneur englobant. Votre connecteur doit respecter l'ordre des opérations prescrit par la DGI : génération, signature, transmission, réception de l'accusé, enrichissement PDF. Toute inversion compromet la chaîne probatoire.

Bonnes pratiques pour entreprises et éditeurs

Côté entreprise utilisatrice, exigez de votre éditeur une visibilité sur le XML UBL généré en cas de litige ou de rejet. Formez les équipes comptables à lire les codes d'erreur plateforme et à ne jamais modifier manuellement un XML validé. Côté éditeur, versionnez vos mappings UBL à chaque évolution de la charte DGI et communiquez clairement les release notes. Participez aux programmes d'agrément et de certification pour figurer parmi les solutions reconnues. Le guide facturation électronique Maroc centralise les ressources pour structurer votre feuille de route technique.

Questions fréquentes sur UBL 2.1 au Maroc