UBL 2.1 n’est ni un logiciel ni un PDF avec une extension différente. C’est un vocabulaire XML public qui range les données commerciales dans des cases nommées et prévisibles. Un programme peut ainsi trouver le numéro, le vendeur, l’acheteur, la TVA et le total sans lire visuellement une page. BelloPOS l’utilise comme format structuré d’export. Au 29 août 2026, nous ne le présentons pas comme le schéma national imposé par une spécification technique DGI publiée.
UBL 2.1 en six réponses
- UBL signifie Universal Business Language et la version 2.1 est un standard OASIS public.
- Une facture commence par l’élément Invoice ; un avoir utilise CreditNote.
- Les préfixes cbc et cac séparent les valeurs simples des ensembles de données.
- Le XML transporte les données ; le PDF reste la vue lisible remise à une personne.
- Un XML bien formé ou valide XSD n’est pas automatiquement fiscalement juste ni accepté par une administration.
- BelloPOS Go exporte UBL 2.1, mais ne transmet pas directement le fichier à la DGI.
1. Lire l’arbre UBL comme une facture
Imaginez une chemise principale nommée Invoice. À l’intérieur, certaines étiquettes contiennent une valeur unique : ID pour le numéro, IssueDate pour la date ou DocumentCurrencyCode pour MAD. D’autres ouvrent une sous-chemise : AccountingSupplierParty pour le vendeur, AccountingCustomerParty pour le client et InvoiceLine pour chaque ligne. Cette organisation est ce qui distingue une facture structurée d’un simple PDF.
| Élément UBL | Ce qu’il représente | Exemple lisible |
|---|---|---|
| Invoice / CreditNote | Type et racine du document | Facture ou avoir |
| cbc:ID | Numéro du document | FAC-2026-00418 |
| cbc:IssueDate | Date d’émission | 2026-08-29 |
| cbc:DocumentCurrencyCode | Devise | MAD |
| cac:AccountingSupplierParty | Identité du vendeur | Raison sociale, adresse, ICE |
| cac:AccountingCustomerParty | Identité de l’acheteur | Société cliente et ICE |
| cac:InvoiceLine | Une ligne facturée | Quantité, article, prix, taxe |
| cac:TaxTotal | TVA regroupée | Base, taux et montant |
| cac:LegalMonetaryTotal | Totaux légaux | HT, TVA, TTC, payable |
Les noms complets sont longs parce qu’ils évitent les ambiguïtés entre deux logiciels. Les préfixes ne sont pas des décorations : cbc regroupe généralement les composants de base, comme un identifiant ou une date, et cac les composants agrégés, comme une partie ou une ligne. Il n’est pas nécessaire de les mémoriser pour facturer, mais les reconnaître aide à contrôler un export.
2. Relier la page visible aux données XML
Prenons une vente de deux chaises à 500 DH HT l’unité, avec 20 % de TVA. La page A4 affiche le client, deux unités, 1 000 DH HT, 200 DH de TVA et 1 200 DH TTC. Le XML doit raconter exactement la même opération : quantité 2, prix unitaire 500, montant de ligne 1 000, catégorie de taxe, taux 20, taxe 200 et total payable 1 200. Les mentions de la facture marocaine restent à contrôler dans le document et dans l’export.
- Le vendeur : Nom légal, adresse et identifiants sont regroupés dans la partie fournisseur.
- Le client : La partie acheteur porte l’identité applicable, au lieu d’une note libre difficile à traiter.
- Les lignes : Chaque quantité, unité, libellé, prix et montant garde sa relation avec l’article vendu.
- La TVA : Les sous-totaux par catégorie ou taux permettent de recomposer le montant fiscal.
- Les totaux : Les bases, taxes, arrondis et montant payable doivent se rapprocher des lignes.
- Le paiement : Le moyen, l’échéance ou la référence peuvent être structurés sans changer le total facturé.
Une facture peut être lisible mais mal structurée, ou structurée mais fiscalement fausse. Par exemple, un XML valide accepte un nom de client correctement encodé ; il ne sait pas si cet ICE appartient réellement à ce client. La qualité dépend donc des données saisies, des règles du logiciel et du contrôle humain.
3. Quatre niveaux de contrôle à ne pas confondre
Le mot valide est trop souvent utilisé seul. Demandez toujours : valide contre quoi ?
- Bien formé XML : les balises s’ouvrent, se ferment et les caractères spéciaux sont échappés.
- Valide contre le XSD UBL 2.1 : les éléments et types respectent le schéma générique publié par OASIS.
- Conforme aux règles métier : numérotation, identité, calculs, références et taxes répondent au profil demandé.
- Accepté par le destinataire : son portail ou son système reçoit le fichier et rend un accusé ou un statut.
| Contrôle | Ce qu’il détecte | Ce qu’il ne prouve pas |
|---|---|---|
| Parseur XML | Balise cassée, caractère invalide | Justesse du taux de TVA |
| Schéma XSD | Structure ou type interdit | Application d’un profil marocain |
| Règles métier | Total incohérent ou champ requis absent | Dépôt effectivement réalisé |
| Accusé du portail | Réception ou rejet par ce canal | Authenticité de toutes les données saisies |
Une future spécification marocaine peut restreindre UBL, choisir un autre format ou ajouter des règles, codes et signatures. C’est pourquoi le guide sur l’obligation de facturation électronique sépare le CGI en vigueur des détails techniques encore à publier ou à confirmer.
Un standard international n’est pas une homologation nationale
OASIS publie UBL 2.1 et ses schémas. Cette existence ne suffit pas à affirmer que la DGI marocaine impose ce format, certifie le logiciel qui l’émet ou accepte aujourd’hui n’importe quel fichier UBL. Il faut une source administrative distincte pour chacune de ces affirmations.
4. Ce que BelloPOS met dans son UBL 2.1
BelloPOS sérialise une facture sous la racine Invoice et un avoir sous CreditNote. L’export porte le numéro émis, la date, MAD, les parties vendeur et client avec les ICE disponibles, les lignes, quantités, prix, TVA regroupée par taux, totaux et données de paiement. Les caractères comme & ou < sont échappés par une bibliothèque XML plutôt que concaténés comme du texte.
À l’émission, l’application conserve le XML exact et calcule son empreinte SHA-256. Elle exporte ensuite ces mêmes octets, au lieu de reconstruire la facture avec des coordonnées qui auraient changé. Cette mécanique est détaillée dans le guide sur le scellement SHA-256.
La fonction est incluse dans BelloPOS Go et Pro. Elle prépare et exporte les fichiers localement. Elle ne signe pas avec un certificat qualifié et n’effectue pas de transmission directe à la DGI. Le commerçant ou sa fiduciaire doit vérifier le canal officiel et les exigences applicables au moment du dépôt.
5. Checklist pour ouvrir un fichier sans être développeur
Travaillez sur une copie et utilisez un éditeur qui n’exécute pas de contenu externe. Le contrôle initial prend quelques minutes.
- Le fichier se termine par .xml et s’ouvre sans erreur de syntaxe.
- La racine correspond au document : Invoice ou CreditNote.
- Le numéro, la date et MAD correspondent à la facture visible.
- Le nom, l’adresse et l’ICE du vendeur sont exacts.
- Le client professionnel et son ICE correspondent à la fiche validée.
- Chaque ligne retrouve quantité, libellé, prix et montant.
- Les bases et montants de TVA se recomposent par taux.
- Le total payable égale le document remis au client.
- L’empreinte du fichier correspond à celle du manifeste quand elle est fournie.
- Le canal destinataire confirme le format et le profil qu’il attend.
Conservez le PDF, le XML, le manifeste et l’éventuel accusé ensemble, avec une convention de nommage stable. Cette paire lisible et structurée simplifie la restitution, le contrôle et la migration future.
Les erreurs à éviter
- Renommer un PDF en .xml.
- Croire que toutes les balises sont obligatoires dans tous les profils.
- Valider seulement la syntaxe sans rapprocher les montants.
- Confondre CreditNote et facture négative improvisée.
- Présenter UBL comme une preuve de dépôt DGI.
- Modifier le XML scellé pour corriger l’affichage.
- Envoyer un fichier client réel à un validateur web inconnu.
- Oublier de conserver la version lisible et l’accusé.
Questions fréquentes
UBL 2.1 est-il un format de facture électronique ?
Oui. OASIS publie UBL comme une bibliothèque de documents commerciaux structurés, dont Invoice et CreditNote. Un profil destinataire peut toutefois ajouter ses propres contraintes.
UBL 2.1 est-il officiellement imposé par la DGI marocaine ?
Nous n’avons pas trouvé, dans les sources officielles vérifiées au 29 août 2026, une spécification nationale publiée qui permette cette affirmation générale. BelloPOS l’utilise comme format d’export.
Le client doit-il lire le XML ?
Pas normalement. Le PDF ou l’impression reste utile à la personne ; le XML sert au traitement par les logiciels. Les deux doivent décrire la même facture.
Quelle différence entre Invoice et CreditNote ?
Invoice représente la facture. CreditNote représente l’avoir et peut référencer la facture corrigée. Ce sont deux racines UBL distinctes.
Un fichier valide XSD est-il fiscalement correct ?
Pas nécessairement. Le XSD contrôle la structure générique. L’identité réelle, la TVA, la numérotation, les règles métier et l’acceptation du canal demandent d’autres contrôles.
BelloPOS envoie-t-il l’UBL à la DGI ?
Non. Go et Pro préparent, scellent et exportent le fichier. Le dépôt reste effectué par le commerçant ou sa fiduciaire via le canal officiel disponible.
À retenir
UBL 2.1 devient simple quand on le lit comme un classeur : racine du document, parties, lignes, taxes et totaux. Sa valeur est la donnée prévisible, pas un badge de conformité. Contrôlez la facture visible, le XML, le profil demandé et l’accusé comme quatre preuves séparées.
Sources
Les chiffres et les règles cités ci-dessus viennent de ces pages, consultées à la date indiquée dans l’article.
- Spécification officielle Universal Business Language 2.1, OASIS
- Code général des impôts 2026, DGI, consulté le 29 août 2026
- BelloPOS, facturation électronique et export UBL, consulté le 29 août 2026
Testez un vrai export UBL, pas une capture
Émettez une facture d’essai dans BelloPOS Go, retrouvez chaque valeur dans le XML, vérifiez l’empreinte et remettez le fichier à votre fiduciaire avant la bascule.
Pour aller plus loin
D’autres guides pratiques sur le même sujet :