Docs / Facturation électronique en Allemagne (XRechnung)

Facturation électronique en Allemagne (XRechnung)

Statut au 27/07/2026 : génération UBL disponible (Story 13.2) et lecture ZUGFeRD/XRechnung hybride déjà fonctionnelle (mesurée, pas modifiée). Aucun rule pack schematron XRechnung natif à ce jour — voir les limites ci-dessous.

Ce que dit la réglementation

L'Allemagne impose progressivement (mandat 2027-2028) la facturation électronique structurée, avec XRechnung comme spécialisation de l'EN 16931 — disponible en sérialisation CII ou UBL, et souvent distribuée sous forme hybride PDF+XML héritée de ZUGFeRD (le pendant allemand de Factur-X : les deux standards partagent la même implémentation technique CII depuis ZUGFeRD 2.x).

Ce que Heartwood couvre aujourd'hui

  • Génération UBL 2.1 dans la variante xrechnung (POST /v1/generate/ubl?variant=xrechnung) — même modèle pivot EN 16931 que les autres variantes UBL (fr-socle, peppol-bis). Le cbc:CustomizationID émis est l'identifiant réel publié par KoSIT : urn:cen.eu:en16931:2017#compliant#urn:xoev-de:kosit:standard:xrechnung_3.0.
  • Extraction d'un PDF hybride ZUGFeRD/XRechnung (POST /v1/extract) : déjà fonctionnelle sans aucune modification de code. Mesuré le 27/07/2026 en téléchargeant un PDF de test officiel (validXRechnung.pdf, projet mustangproject/ZUGFeRD, Apache License 2.0) et en le faisant passer tel quel dans pdf.ExtractCII puis codec.DecodeCII : les deux ont réussi du premier coup. Raison : depuis l'harmonisation ZUGFeRD 2.x/Factur-X 1.0, les deux standards embarquent leur CII sous le même nom de pièce jointe (factur-x.xml), et le décodage CII de Heartwood est générique — il ne filtre jamais sur le contenu de GuidelineSpecifiedDocumentContextParameter/ID (qui distingue Factur-X de ZUGFeRD/XRechnung). Un test de non-régression verrouille cette capacité (TestExtractHandlerFromZUGFeRDXRechnungHybridPDF).
  • Conversion CII↔UBL (POST /v1/convert) et extraction UBL autonome — mêmes chemins que pour Factur-X/Peppol BIS.

Limites connues

  • Aucun rule pack schematron XRechnung natif : POST /v1/validate peut vérifier un document xrechnung contre le schéma XSD OASIS UBL 2.1 et le schematron EN 16931 générique (ubl-en16931-1.4.0), mais pas contre les règles additionnelles propres à XRechnung (structuration des identifiants de destinataire du secteur public allemand "Leitweg-ID", restrictions de listes de codes spécifiques KoSIT). Ce n'est donc pas une certification XRechnung — même écart que celui documenté pour Peppol BIS avant Story 13.1.
  • ZUGFeRD n'est vérifié qu'à l'extraction, pas à la génération : Heartwood ne produit pas de PDF hybride portant un profil ZUGFeRD/ XRechnung propre (POST /v1/generate/facturx reste un profil Factur-X français) — seule la variante UBL xrechnung est générée. Un besoin de PDF hybride allemand natif resterait à modéliser séparément (core.Profile ne porte aujourd'hui que EN16931/EXTENDED-CTC-FR/ PEPPOL-BIS).
  • [ASSUMPTION] : les variantes fr-socle, peppol-bis et xrechnung partagent aujourd'hui exactement le même socle de champs modélisés (core.Invoice) — aucune règle spécifique à XRechnung n'est encore distinguée côté génération.
  • Le mesurage ZUGFeRD ci-dessus porte sur un seul fichier de test, pas sur un corpus KoSIT complet — cf. rulepacks/README.md (« Ce qui n'est PAS encore couvert ») pour le même constat appliqué aux rule packs français.