Invocie

Tech

UBL 2.1 expliqué simplement : la norme XML derrière la facturation électronique moderne

Quasi tous les grands mandats e-invoicing émettent du UBL 2.1 sous le capot. Voici un tour sans jargon des parties qu'il faut vraiment comprendre.

Invocie Team · 21 janvier 2026 · 5 min de lecture


UBL — Universal Business Language — est le standard OASIS qui sous-tend Peppol BIS, EN 16931, ZATCA Phase 2, le profil PINT des EAU, le schema IRP/e-invoice de l'Inde (avec extensions) et plusieurs régimes LATAM. Si votre stratégie e-invoicing ne fait pas la paix avec UBL 2.1, vous allez réimplémenter le même XML encore et encore.

La forme d'une facture UBL

Une facture UBL est un document XML avec trois namespaces principaux : cbc (Common Basic Components — types primitifs comme ID et Amount), cac (Common Aggregate Components — types complexes comme Party et TaxTotal), et le namespace du document lui-même. Chaque document UBL suit le même pattern :

<Invoice
    xmlns="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2"
    xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2"
    xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2">
  <cbc:CustomizationID>urn:cen.eu:en16931:2017</cbc:CustomizationID>
  <cbc:ID>INV-2026-0001</cbc:ID>
  <cbc:IssueDate>2026-01-15</cbc:IssueDate>
  <cbc:DocumentCurrencyCode>EUR</cbc:DocumentCurrencyCode>
  <cac:AccountingSupplierParty>...</cac:AccountingSupplierParty>
  <cac:AccountingCustomerParty>...</cac:AccountingCustomerParty>
  <cac:TaxTotal>...</cac:TaxTotal>
  <cac:LegalMonetaryTotal>...</cac:LegalMonetaryTotal>
  <cac:InvoiceLine>...</cac:InvoiceLine>
</Invoice>

Cinq concepts presque toujours mal compris

  1. TaxTotal vs. LegalMonetaryTotal. Le premier décompose la taxe par taux. Le second est le montant total à payer consolidé. Ne les confondez pas.
  2. AllowanceCharge peut être une remise ou une majoration — contrôlé par ChargeIndicator (false = remise, true = majoration). Mauvais indicateur → mauvais total.
  3. Les Endpoint IDs ont besoin d'un attribut scheme (schemeID="0088" etc.). Sans lui, les validateurs renvoient des erreurs cryptiques sur des identifiants manquants.
  4. Les quantités utilisent un code unité d'UN/CEFACT (EA = chaque, KGM = kilogramme, HUR = heure). "piece" n'est pas une valeur valide.
  5. Les codes TaxCategory sont UNCL5305 : S = taux standard, Z = taux zéro, E = exonéré, AE = autoliquidation. N'inventez pas de codes.

L'EUStrategy d'Invocie émet du UBL 2.1 conforme à BIS Billing 3.0 — le même XML fonctionne pour les APs Peppol, le profil UAE PINT et tout système qui consomme EN 16931.


Lectures liées

Chaînes de hash pour des pistes d'audit infalsifiables

ZATCA les impose, les auditeurs européens les adorent, et leur mise en œuvre est peu coûteuse. Voici comment SHA-256 chaîné transforme un registre de factures en un objet dont vous pouvez prouver l'intégrité.

Concevoir une API e-invoicing multi-régions : leçons du terrain

Si vous bâtissez une infrastructure qui dessert à la fois des pays clearance et post-audit, vous n'avez qu'une seule chance de réussir vos abstractions. Voici ce que nous avons appris à la dure.

Intégrer la facturation électronique des EAU à votre ERP : guide technique

Un parcours technique pour le Head of IT et le responsable de transformation ERP : comment UAE PINT se mappe sur SAP, Oracle, Microsoft Dynamics et les ERP sur mesure, les données à nettoyer d'abord, et les patterns d'intégration qui survivent en production.

Émettez des factures conformes sur tous les marchés

ZATCA, FTA, Peppol et post-audit mondial — une seule API.

Parler à notre équipe