ediverse Explorer la plateforme

À la une PEPPOL BIS Billing 3.0 L’obligation européenne d’e-invoicing arrive : France sept 2026, Belgique janv 2026, Allemagne 2025.

OIOUBL 3.0 — le format danois pour NemHandel

OIOUBL est le CIUS (Core Invoice Usage Specification) danois bâti sur OASIS UBL 2.1. Lancé en 2008 pour remplacer OIOXML, la version 3.0 publiée fin 2024 par Erhvervsstyrelsen est l'évolution la plus importante depuis 16 ans — alignement EN 16931 strict, retrait de la sémantique pré-UBL héritée, ouverture aux mécanismes d'extension PEPPOL.

Historique — d'OIOXML à OIOUBL 3.0

L'évolution du format danois suit cinq jalons :

  • 2003-2007 — OIOXML : schéma XML propriétaire développé par Statens IT et IT- og Telestyrelsen. Très spécifique au contexte danois, peu interopérable internationalement.
  • 2008 — OIOUBL 2.01 : migration vers OASIS UBL 2.0, conservant la sémantique mais en passant aux schémas standards OASIS.
  • 2010 — OIOUBL 2.02 : alignement UBL 2.1, ajout des profils OrdSim et CatSim pour les marchés publics.
  • 2018 — Annex OIOUBL-PEPPOL : tableau de correspondance pour permettre la traduction automatique OIOUBL ↔ PEPPOL-BIS 3.0.
  • 2024 — OIOUBL 3.0 : refonte majeure, alignement EN 16931 strict, suppression des champs hérités OIOXML, mécanismes d'extension XBRL pour le reporting comptable.

Positionnement vis-à-vis de UBL et EN 16931

OIOUBL 3.0 est techniquement un superset restrictif de la norme EN 16931 :

  • Restrictif (Core) : implémente les 192 termes du modèle sémantique EN 16931, avec règles BR-* obligatoires.
  • Superset (Extensions DK) : ajoute ~40 champs danois pour la facturation publique (références FIK, ContractDocumentReference avec format spécifique « Konteringsstreng »).

Pour les flux purement DK ↔ DK, OIOUBL est recommandé. Pour les flux DK ↔ UE (cross-border B2G), PEPPOL-BIS 3.0 reste préférable car les extensions OIOUBL ne sont pas garanties d'être préservées par les points d'accès étrangers.

Les profils OIOUBL 3.0

OIOUBL distingue plusieurs profils (ProfileID) selon le cas d'usage métier :

  • Procurement-BilSim-1.0 — facture simple (le cas le plus fréquent)
  • Procurement-BilAdv-1.0 — facture avancée avec OrderResponse en amont
  • Procurement-OrdSim-1.0 — bon de commande simple
  • Procurement-OrdAdv-1.0 — bon de commande avancé avec réponse négociée
  • Procurement-CatSim-1.0 — catalogue simple
  • Procurement-CatAdv-1.0 — catalogue avancé avec mises à jour différentielles
  • Procurement-ReminderSim-1.0 — rappel de paiement

Règles BR-DK-* spécifiques

OIOUBL 3.0 enrichit les règles métier EN 16931 (BR-01 à BR-65, BR-S-01 à BR-AE-10) avec environ 140 règles propres au contexte danois, nommées BR-DK-01 à BR-DK-140 :

  • BR-DK-01 : Le scheme ID de PartyIdentification doit être « 0184 » (DK:CVR).
  • BR-DK-02 : Le CompanyID dans PartyTaxScheme doit commencer par « DK » suivi de 8 chiffres.
  • BR-DK-15 : Pour InvoiceTypeCode 380, 381 et 384, la mention « Faktura » / « Kreditnota » / « Korrigeret faktura » est attendue dans Note.
  • BR-DK-22 : Les codes paiement FIK 04/15/71/73 doivent être déclarés dans PaymentMeans/InstructionID avec un identifiant Kreditor (8 chiffres).
  • BR-DK-40 : Le TaxCategory ID doit appartenir à la liste DK : S, Z, E, AE, K, G, O.
  • BR-DK-65 : Pour les factures > 100 000 DKK, un ContractDocumentReference doit être présent (référence dossier marché public).

Exemple — facture OIOUBL 3.0 minimale

xml invoice-oioubl-3-minimal.xml
<?xml version="1.0" encoding="UTF-8"?>
<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>OIOUBL-3.0</cbc:CustomizationID>
  <cbc:ProfileID>Procurement-BilSim-1.0</cbc:ProfileID>
  <cbc:ID>2026-DK-00042</cbc:ID>
  <cbc:IssueDate>2026-05-20</cbc:IssueDate>
  <cbc:InvoiceTypeCode>380</cbc:InvoiceTypeCode>
  <cbc:DocumentCurrencyCode>DKK</cbc:DocumentCurrencyCode>

  <cac:AccountingSupplierParty>
    <cac:Party>
      <cbc:EndpointID schemeID="0184">12345678</cbc:EndpointID>
      <cac:PartyIdentification>
        <cbc:ID schemeID="0184">12345678</cbc:ID>
      </cac:PartyIdentification>
      <cac:PartyName><cbc:Name>Eksempel A/S</cbc:Name></cac:PartyName>
      <cac:PostalAddress>
        <cbc:StreetName>Vesterbrogade 1</cbc:StreetName>
        <cbc:CityName>København</cbc:CityName>
        <cbc:PostalZone>1620</cbc:PostalZone>
        <cac:Country><cbc:IdentificationCode>DK</cbc:IdentificationCode></cac:Country>
      </cac:PostalAddress>
      <cac:PartyTaxScheme>
        <cbc:CompanyID schemeID="DK:CVR">DK12345678</cbc:CompanyID>
        <cac:TaxScheme><cbc:ID>VAT</cbc:ID></cac:TaxScheme>
      </cac:PartyTaxScheme>
    </cac:Party>
  </cac:AccountingSupplierParty>

  <cac:AccountingCustomerParty>
    <cac:Party>
      <cbc:EndpointID schemeID="0184">87654321</cbc:EndpointID>
      <cac:PartyIdentification>
        <cbc:ID schemeID="0184">87654321</cbc:ID>
      </cac:PartyIdentification>
    </cac:Party>
  </cac:AccountingCustomerParty>

  <cac:TaxTotal>
    <cbc:TaxAmount currencyID="DKK">250.00</cbc:TaxAmount>
    <cac:TaxSubtotal>
      <cbc:TaxableAmount currencyID="DKK">1000.00</cbc:TaxableAmount>
      <cbc:TaxAmount currencyID="DKK">250.00</cbc:TaxAmount>
      <cac:TaxCategory>
        <cbc:ID>S</cbc:ID>
        <cbc:Percent>25</cbc:Percent>
        <cac:TaxScheme><cbc:ID>VAT</cbc:ID></cac:TaxScheme>
      </cac:TaxCategory>
    </cac:TaxSubtotal>
  </cac:TaxTotal>

  <cac:LegalMonetaryTotal>
    <cbc:LineExtensionAmount currencyID="DKK">1000.00</cbc:LineExtensionAmount>
    <cbc:TaxExclusiveAmount currencyID="DKK">1000.00</cbc:TaxExclusiveAmount>
    <cbc:TaxInclusiveAmount currencyID="DKK">1250.00</cbc:TaxInclusiveAmount>
    <cbc:PayableAmount currencyID="DKK">1250.00</cbc:PayableAmount>
  </cac:LegalMonetaryTotal>
</Invoice>

Migration depuis OIOUBL 2.02

ERST publie un guide officiel de migration (Migration Guide v3.0, novembre 2024) qui détaille les ruptures à anticiper :

  • CustomizationID modifié : de OIOUBL-2.02 à OIOUBL-3.0.
  • Suppression de PartyLegalEntity/CompanyID : tous les champs identité légale doivent désormais utiliser PartyTaxScheme.
  • Suppression de DeliveryTerms hérité : remplacé par Delivery/DeliveryLocation avec Incoterms EN 16931 standards.
  • Réécriture des règles Schematron : intégrées au moteur de validation NemHandel et SBR Service.
  • Période de coexistence : NemHandel accepte OIOUBL 2.02 et 3.0 jusqu'au 31 décembre 2026, après quoi seul 3.0 sera reçu.

Coexistence avec PEPPOL-BIS 3.0

Depuis 2018, le Danemark accepte les deux formats côte à côte :

  • OIOUBL 3.0 recommandé pour les flux internes B2G et la comptabilité Bogføringsloven (préservation des extensions danoises).
  • PEPPOL-BIS 3.0 recommandé pour les flux cross-border UE et les fournisseurs européens non danois.
  • Les points d'accès PEPPOL DK (Visma, Pagero, etc.) effectuent la traduction automatique OIOUBL ↔ PEPPOL-BIS en fonction de l'origine et de la destination.
  • OIOUBL conserve l'identifiant 0184 (DK:CVR) — le même que celui utilisé dans PEPPOL pour le Danemark, garantissant la réversibilité.

Liens transverses