Aller au contenu
XRechnung & ZUGFeRDRetour à tous les articles

Exemple de XRechnung : à quoi ressemble le XML

Exemple de XRechnung : à quoi ressemble le XML

Une XRechnung n’est pas une page mise en forme, mais un fichier XML : chaque information de la facture figure dans un élément propre, précisément nommé, par exemple le numéro de facture dans cbc:ID et le montant à payer dans cbc:PayableAmount. Si vous l’ouvrez dans un éditeur de texte, vous voyez des balises imbriquées au lieu d’un papier à en-tête. L’exemple de XRechnung ci-dessous présente une facture complète, volontairement réduite, en syntaxe UBL et explique chacun de ses blocs.

À quoi ressemble une XRechnung ?

La XRechnung repose sur la norme européenne EN 16931. Cette norme définit les informations que contient une facture et attribue un numéro à chacune d’elles, par exemple BT-1 pour le numéro de facture. Sur le plan technique, la XRechnung peut être rédigée dans deux syntaxes XML :

  • UBL (Universal Business Language, OASIS UBL 2.1) : élément racine Invoice ou CreditNote. Répandue sur le réseau Peppol.
  • CII (UN/CEFACT Cross Industry Invoice) : élément racine CrossIndustryInvoice. ZUGFeRD utilise la même syntaxe.

Les deux variantes transportent les mêmes contenus ; seuls les noms des éléments et leur imbrication diffèrent. La version actuellement en vigueur est XRechnung 3.0, dans sa version 3.0.2.

Exemple de XRechnung en XML (UBL)

L’exemple présente une facture entre deux entreprises portant sur dix heures de conseil à 100 euros chacune, plus 19 % de TVA. Les noms, adresses et numéros sont fictifs.

<?xml version="1.0" encoding="UTF-8"?>
<ubl:Invoice xmlns:ubl="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#compliant#urn:xeinkauf.de:kosit:xrechnung_3.0</cbc:CustomizationID>
  <cbc:ProfileID>urn:fdc:peppol.eu:2017:poacc:billing:01:1.0</cbc:ProfileID>
  <cbc:ID>RE-2026-0042</cbc:ID>
  <cbc:IssueDate>2026-09-28</cbc:IssueDate>
  <cbc:DueDate>2026-10-12</cbc:DueDate>
  <cbc:InvoiceTypeCode>380</cbc:InvoiceTypeCode>
  <cbc:DocumentCurrencyCode>EUR</cbc:DocumentCurrencyCode>
  <cbc:BuyerReference>PO-4711</cbc:BuyerReference>
  <cac:AccountingSupplierParty>
    <cac:Party>
      <cbc:EndpointID schemeID="EM">rechnung@muster-gmbh.de</cbc:EndpointID>
      <cac:PostalAddress>
        <cbc:StreetName>Musterstraße 1</cbc:StreetName>
        <cbc:CityName>Mannheim</cbc:CityName>
        <cbc:PostalZone>68159</cbc:PostalZone>
        <cac:Country><cbc:IdentificationCode>DE</cbc:IdentificationCode></cac:Country>
      </cac:PostalAddress>
      <cac:PartyTaxScheme>
        <cbc:CompanyID>DE123456789</cbc:CompanyID>
        <cac:TaxScheme><cbc:ID>VAT</cbc:ID></cac:TaxScheme>
      </cac:PartyTaxScheme>
      <cac:PartyLegalEntity>
        <cbc:RegistrationName>Muster GmbH</cbc:RegistrationName>
      </cac:PartyLegalEntity>
      <cac:Contact>
        <cbc:Name>Erika Muster</cbc:Name>
        <cbc:Telephone>+49 621 1234567</cbc:Telephone>
        <cbc:ElectronicMail>buchhaltung@muster-gmbh.de</cbc:ElectronicMail>
      </cac:Contact>
    </cac:Party>
  </cac:AccountingSupplierParty>
  <cac:AccountingCustomerParty>
    <cac:Party>
      <cbc:EndpointID schemeID="EM">rechnungseingang@kunde-ag.de</cbc:EndpointID>
      <cac:PostalAddress>
        <cbc:StreetName>Am Platz 2</cbc:StreetName>
        <cbc:CityName>Köln</cbc:CityName>
        <cbc:PostalZone>50667</cbc:PostalZone>
        <cac:Country><cbc:IdentificationCode>DE</cbc:IdentificationCode></cac:Country>
      </cac:PostalAddress>
      <cac:PartyLegalEntity>
        <cbc:RegistrationName>Kunde AG</cbc:RegistrationName>
      </cac:PartyLegalEntity>
    </cac:Party>
  </cac:AccountingCustomerParty>
  <cac:PaymentMeans>
    <cbc:PaymentMeansCode>58</cbc:PaymentMeansCode>
    <cac:PayeeFinancialAccount>
      <cbc:ID>DE02120300000000202051</cbc:ID>
    </cac:PayeeFinancialAccount>
  </cac:PaymentMeans>
  <cac:PaymentTerms>
    <cbc:Note>Zahlbar innerhalb von 14 Tagen ohne Abzug.</cbc:Note>
  </cac:PaymentTerms>
  <cac:TaxTotal>
    <cbc:TaxAmount currencyID="EUR">190.00</cbc:TaxAmount>
    <cac:TaxSubtotal>
      <cbc:TaxableAmount currencyID="EUR">1000.00</cbc:TaxableAmount>
      <cbc:TaxAmount currencyID="EUR">190.00</cbc:TaxAmount>
      <cac:TaxCategory>
        <cbc:ID>S</cbc:ID>
        <cbc:Percent>19</cbc:Percent>
        <cac:TaxScheme><cbc:ID>VAT</cbc:ID></cac:TaxScheme>
      </cac:TaxCategory>
    </cac:TaxSubtotal>
  </cac:TaxTotal>
  <cac:LegalMonetaryTotal>
    <cbc:LineExtensionAmount currencyID="EUR">1000.00</cbc:LineExtensionAmount>
    <cbc:TaxExclusiveAmount currencyID="EUR">1000.00</cbc:TaxExclusiveAmount>
    <cbc:TaxInclusiveAmount currencyID="EUR">1190.00</cbc:TaxInclusiveAmount>
    <cbc:PayableAmount currencyID="EUR">1190.00</cbc:PayableAmount>
  </cac:LegalMonetaryTotal>
  <cac:InvoiceLine>
    <cbc:ID>1</cbc:ID>
    <cbc:InvoicedQuantity unitCode="HUR">10</cbc:InvoicedQuantity>
    <cbc:LineExtensionAmount currencyID="EUR">1000.00</cbc:LineExtensionAmount>
    <cac:Item>
      <cbc:Name>Beratungsleistung</cbc:Name>
      <cac:ClassifiedTaxCategory>
        <cbc:ID>S</cbc:ID>
        <cbc:Percent>19</cbc:Percent>
        <cac:TaxScheme><cbc:ID>VAT</cbc:ID></cac:TaxScheme>
      </cac:ClassifiedTaxCategory>
    </cac:Item>
    <cac:Price>
      <cbc:PriceAmount currencyID="EUR">100.00</cbc:PriceAmount>
    </cac:Price>
  </cac:InvoiceLine>
</ubl:Invoice>

Les blocs de l’exemple expliqués

Identifiant et en-tête de facture

CustomizationID (BT-24) indique au destinataire selon quel ensemble de règles le fichier doit être contrôlé. La valeur contenant xrechnung_3.0 identifie le fichier comme une XRechnung 3.0. Si une valeur erronée figure ici, la validation échoue, même si le contenu est correct. ProfileID (BT-23) décrit le processus métier, ici la valeur habituelle de Peppol. Suivent le numéro de facture (BT-1), la date de facture (BT-2), l’échéance (BT-9), le type de facture (BT-3, 380 correspond à une facture normale) et la devise (BT-5).

Référence acheteur

BuyerReference (BT-10) est obligatoire dans la XRechnung. Pour les administrations, c’est ici que figure la Leitweg-ID ; pour les entreprises, une référence convenue comme le numéro de commande.

Vendeur et acheteur

AccountingSupplierParty est le vendeur, avec son adresse électronique (BT-34), son adresse postale, son numéro de TVA intracommunautaire (BT-31), sa raison sociale (BT-27) et son contact (BG-6). Pour le vendeur, la XRechnung exige le nom, le téléphone et l’e-mail de l’interlocuteur. AccountingCustomerParty est l’acheteur, avec son adresse électronique (BT-49), son adresse postale et son nom. L’attribut schemeID="EM" identifie l’adresse comme une adresse e-mail.

Paiement

PaymentMeans contient le mode de paiement (BT-81, code 58 pour le virement SEPA) et l’IBAN (BT-84). PaymentTerms reprend les conditions de paiement sous forme de texte (BT-20).

Taxe et totaux

TaxTotal regroupe la TVA par catégorie : la catégorie S correspond au taux normal. LegalMonetaryTotal contient les totaux : total HT des lignes, montant HT de la facture, montant TTC de la facture et montant à payer. Ces valeurs doivent concorder exactement entre elles et avec les lignes, sans quoi la validation signale une erreur.

Lignes

Chaque InvoiceLine comporte un numéro (BT-126), une quantité avec un code d’unité (BT-129 et BT-130, HUR signifie heures), le montant HT de la ligne (BT-131), la désignation (BT-153), la catégorie de taxe et le prix unitaire (BT-146). La signification de tous les numéros est expliquée dans l’article Champs de la XRechnung : tous les numéros BT expliqués.

La même facture en CII

Dans la syntaxe CII, les éléments portent d’autres noms et sont organisés en contexte, document et transaction commerciale. Le début de la même facture se présente ainsi :

<rsm:CrossIndustryInvoice
    xmlns:rsm="urn:un:unece:uncefact:data:standard:CrossIndustryInvoice:100"
    xmlns:ram="urn:un:unece:uncefact:data:standard:ReusableAggregateBusinessInformationEntity:100"
    xmlns:udt="urn:un:unece:uncefact:data:standard:UnqualifiedDataType:100">
  <rsm:ExchangedDocumentContext>
    <ram:GuidelineSpecifiedDocumentContextParameter>
      <ram:ID>urn:cen.eu:en16931:2017#compliant#urn:xeinkauf.de:kosit:xrechnung_3.0</ram:ID>
    </ram:GuidelineSpecifiedDocumentContextParameter>
  </rsm:ExchangedDocumentContext>
  <rsm:ExchangedDocument>
    <ram:ID>RE-2026-0042</ram:ID>
    <ram:TypeCode>380</ram:TypeCode>
    <ram:IssueDateTime>
      <udt:DateTimeString format="102">20260928</udt:DateTimeString>
    </ram:IssueDateTime>
  </rsm:ExchangedDocument>
  <rsm:SupplyChainTradeTransaction>
    <!-- Positionen, Vereinbarungen, Lieferung, Abrechnung -->
  </rsm:SupplyChainTradeTransaction>
</rsm:CrossIndustryInvoice>

Le bloc SupplyChainTradeTransaction contient ensuite les lignes (IncludedSupplyChainTradeLineItem), les informations sur le vendeur, l’acheteur et les références (ApplicableHeaderTradeAgreement), la livraison (ApplicableHeaderTradeDelivery) ainsi que les taxes, le paiement et les totaux (ApplicableHeaderTradeSettlement). À noter : en CII, la date est au format AAAAMMJJ, en UBL au format AAAA-MM-JJ.

Schéma XML et validation

Une XRechnung est contrôlée en deux étapes :

  1. Schéma XML (XSD) : les noms des éléments, leur ordre et les types de données sont-ils corrects ? Pour UBL, il s’agit du schéma OASIS UBL 2.1 ; pour CII, du schéma de l’UN/CEFACT.
  2. Règles métier (Schematron) : les contenus sont-ils corrects ? C’est ici que s’appliquent les règles de la norme EN 16931 (par exemple BR-CO-15 : montant TTC égal au montant HT plus la taxe) et les règles complémentaires allemandes de la XRechnung (BR-DE, par exemple l’obligation d’indiquer la référence acheteur).

La KoSIT (Koordinierungsstelle für IT-Standards, l’organisme allemand de coordination des normes informatiques) met à disposition à cet effet un validateur librement accessible, avec la configuration adaptée à la XRechnung. L’exemple ci-dessus est réduit à la structure. Avant d’envoyer votre propre fichier, contrôlez-le toujours par rapport à la configuration actuelle.

Créer et recevoir des XRechnungen

Personne n’écrit des XRechnungen à la main. En pratique, un logiciel ou une API génère le fichier à partir de vos données de facturation et le contrôle avant l’envoi. Côté destinataire, faktoora importe les XRechnungen reçues, les valide et les affiche sous forme de PDF lisible ; pour en savoir plus, consultez Recevoir des factures électroniques. L’article Ouvrir et afficher une XRechnung explique comment ouvrir une XRechnung sans logiciel.

Questions fréquentes

Quelle est l’extension de fichier d’une XRechnung ?

En règle générale .xml. Le fichier s’ouvre dans n’importe quel éditeur de texte, mais il ne devient lisible qu’avec une visionneuse ou une visualisation.

La XRechnung est-elle en UBL ou en CII ?

Les deux sont autorisés. La XRechnung définit les contenus ; UBL et CII en sont deux écritures équivalentes. Si vous recevez des factures électroniques, vous devriez donc pouvoir traiter les deux variantes.

Puis-je utiliser cet exemple de XRechnung comme modèle ?

Comme repère, oui ; comme modèle prêt à l’emploi, non. Selon le cas, les vraies factures nécessitent d’autres informations, comme la date de prestation, des remises ou plusieurs taux de taxe, et doivent être validées avant l’envoi.

Où trouver des exemples officiels de XRechnung ?

La KoSIT publie avec la spécification des fichiers de test en UBL et en CII. Les paquets en vigueur sont disponibles sur xeinkauf.de.