E-Rechnung obligatoire en Allemagne : émettre des factures structurées depuis vos propres systèmes au 1er janvier 2027

À partir du 1er janvier 2027, une entreprise allemande dont le chiffre d'affaires 2026 a dépassé 800 000 € ne peut plus envoyer de facture papier ou PDF à une autre entreprise allemande. La facture doit être une facture électronique structurée : un fichier de données conforme à la norme européenne EN 16931. À partir du 1er janvier 2028, le seuil disparaît et la règle s'applique à toutes les entreprises, à quelques exceptions étroites près.

Pour une petite structure, cela arrive sous forme de mise à jour logicielle. Pour une entreprise dont les factures sortent de son propre système de facturation, d'un progiciel métier ou d'un ERP personnalisé depuis quinze ans, c'est un projet logiciel, et il reste environ treize semaines. Cet article s'adresse à ce second groupe.

Ce que dit la loi

La définition figure au § 14 UStG : une facture « die in einem strukturierten elektronischen Format ausgestellt, übermittelt und empfangen wird und eine elektronische Verarbeitung ermöglicht ». Le format doit être conforme à la norme européenne prévue par la directive 2014/55/UE (en pratique, l'EN 16931), ou convenu entre les parties, à condition que les données requises puissent être extraites correctement et intégralement sous une forme compatible avec cette norme. Un PDF ne remplit pas ces conditions, aussi propre soit-il.

L'obligation vise les livraisons et prestations à une autre entreprise lorsque les deux parties sont établies en Allemagne. La transition est prévue au § 27 Abs. 38 UStG :

• Les opérations réalisées en 2025 et 2026 peuvent encore être facturées sur papier, ou dans un autre format électronique avec l'accord du client, tant que la facture part au plus tard le 31 décembre 2026.
• Les opérations réalisées en 2027 bénéficient de la même tolérance jusqu'au 31 décembre 2027, mais uniquement si le chiffre d'affaires total de l'émetteur l'année civile précédente n'a pas dépassé 800 000 €.
• L'EDI non conforme à la norme peut se poursuivre pour les opérations réalisées en 2027, avec l'accord du client, quelle que soit votre taille.

Trois détails comptent plus qu'il n'y paraît.

Le seuil se mesure sur le chiffre d'affaires de l'année précédente. Votre situation en 2027 dépend de votre chiffre 2026, que personne ne connaîtra précisément avant la clôture des comptes. Si vous êtes proche de 800 000 €, construisez comme si vous étiez au-dessus.

La tolérance s'arrête à une date d'envoi. À la lettre, la première règle transitoire cesse de couvrir le papier et le PDF le 31 décembre 2026, même pour des prestations réalisées en 2026. Si vous êtes au-dessus du seuil et facturez à terme échu, la facture envoyée la première semaine de janvier pour le travail de décembre doit déjà être structurée. Faites-le confirmer par votre conseiller fiscal, mais ne prévoyez pas de démarrage à la mi-janvier.

Certaines factures restent hors champ : les factures aux consommateurs, les factures transfrontalières, les factures de faible montant jusqu'à 250 € TTC, les titres de transport valant facture, les factures des Kleinunternehmer (petites entreprises en franchise de TVA), et les opérations exonérées au titre du § 4 Nr. 8 à 29 UStG.

Nous n'avons connaissance d'aucun projet de loi visant à décaler ces dates. Planifiez comme si elles tenaient.

La réception s'applique depuis 2025. L'émission est la nouveauté.

Depuis le 1er janvier 2025, toute entreprise allemande doit être en mesure de recevoir des factures électroniques. La FAQ du ministère fédéral des Finances sur la facture électronique est très directe sur ce que cela demande : « Für den Empfang einer elektronischen Rechnung genügt bereits ein E-Mail-Postfach. » Une boîte e-mail suffit.

Notez une ligne du § 14 lui-même : là où l'obligation de facture électronique s'applique, le consentement du destinataire n'est pas requis. Un client professionnel allemand ne peut pas refuser votre facture structurée.

L'émission est un autre problème. Quand vous recevez, un outil lit le fichier de quelqu'un d'autre. Quand vous émettez, votre système en est l'auteur : si les données sont fausses à la source, personne plus loin dans la chaîne ne peut les réparer, et une facture qui échoue à la validation de votre client reste impayée.

Qui reçoit cela par une simple mise à jour

Pour être clair : si vous êtes une petite structure qui facture depuis DATEV, lexoffice, sevDesk ou un logiciel comparable, votre éditeur livre le format. Vérifiez vos données de référence (numéro de TVA intracommunautaire, adresses clients, coordonnées bancaires), activez la fonction et envoyez une facture de test. Vous n'avez pas besoin d'un projet, ni d'une société de développement.

Il en va à peu près de même pour un ERP du marché resté proche du standard : l'éditeur ou votre intégrateur fournit la sortie, et le travail consiste à paramétrer et tester.

La suite de cet article s'adresse aux entreprises dont les factures sortent d'un code qui leur appartient, ou d'un code que plus personne ne maintient :

• les moteurs de facturation des plateformes d'abonnement, des places de marché et des fournisseurs d'énergie ou d'eau, qui émettent des factures par programme et en volume ;
• les logiciels métier du négoce, du BTP, de la logistique ou des interventions sur site, dont l'éditeur est petit, lent ou a disparu ;
• les ERP dont la sortie des factures a été réécrite il y a des années sous forme de programmes d'impression spécifiques, de modèles d'états ou d'un publipostage de fin de mois.

Les formats : EN 16931, XRechnung et ZUGFeRD

L'EN 16931 est la norme européenne. Elle définit le modèle sémantique d'une facture (les champs, leur signification, ceux qui sont obligatoires et les règles de gestion qui les relient) et le décline en deux syntaxes XML, UBL 2.1 et UN/CEFACT CII.

XRechnung est la spécification allemande construite sur l'EN 16931, maintenue par la KoSIT : du XML pur dans l'une ou l'autre syntaxe, exigé par les administrations et tout aussi valable entre entreprises. Selon la page XRechnung de la KoSIT, la version 3.0 est en vigueur depuis le 1er février 2024 et le reste au moins jusqu'au 31 juillet 2027. Une version préliminaire de la 4.0 a été publiée en septembre 2026, la version définitive étant attendue au printemps 2027. Vous démarrerez en 3.0 et migrerez dans votre première année.

ZUGFeRD est un format hybride : un fichier PDF/A-3 dans lequel est embarqué un XML CII. Les humains lisent le PDF, les machines lisent le XML. C'est techniquement le même format que Factur-X en France. Le FeRD a publié la version 2.5.2 le 4 août 2026. ZUGFeRD existe en plusieurs profils (MINIMUM, BASIC WL, BASIC, EN 16931, EXTENDED), et la FAQ du ministère accepte ZUGFeRD à partir de la version 2.0.1 « mit Ausnahme der Profile MINIMUM und BASIC-WL ».

Dans une facture hybride, c'est le XML qui fait foi. La FAQ appelle la partie structurée le « führender Teil », la partie qui prime. Si votre PDF et votre XML divergent, c'est le PDF qui a tort.

Pour la plupart des émetteurs B2B allemands, le choix raisonnable par défaut est ZUGFeRD au profil EN 16931, pour que les clients qui lisent encore leurs factures à l'œil puissent continuer, plus XRechnung pour les administrations et pour quiconque le demande. Les deux doivent sortir d'un seul objet facture interne, pas de deux chaînes de code distinctes.

Ce qui doit changer dans votre système

La facture devient une donnée, plus une mise en page

Beaucoup de systèmes anciens construisent la facture au moment de l'impression : du texte concaténé dans un modèle, des totaux calculés dans l'état, la mention de TVA en paragraphe codé en dur. Rien de tout cela ne survit à l'EN 16931. Il vous faut un objet facture stocké qui contient chaque champ, et à partir duquel le XML et le PDF sont tous deux générés.

Les champs généralement absents ou faux :

• Les données des parties. Des adresses structurées avec codes pays ISO, et un numéro de TVA intracommunautaire ou un numéro fiscal. Les blocs d'adresse en texte libre doivent être découpés.
• La date de livraison ou la période de prestation, conservée comme donnée et non comme phrase dans l'en-tête.
• Les unités. Chaque quantité a besoin d'un code de la recommandation n° 20 de la CEE-ONU (H87 pour la pièce, KGM pour le kilogramme, DAY pour le jour). « Stk. » et « pauschal » doivent être mis en correspondance.
• La TVA. Chaque ligne porte une catégorie et un taux de TVA. La facture porte une ventilation de TVA par combinaison de catégorie et de taux, et les totaux doivent tomber juste à deux décimales. Les systèmes qui arrondissent la TVA ligne par ligne échouent ici.
• Les mentions d'exonération et d'autoliquidation. La phrase en bas du PDF devient un code de catégorie de TVA plus un motif d'exonération.
• Le paiement. Moyen de paiement, IBAN et conditions sous forme structurée.
• Les références. Le numéro de commande ou la référence acheteur sur lequel le service comptabilité fournisseurs de votre client fait son rapprochement. Si vous ne l'avez jamais stocké, commencez à le saisir dès maintenant.

Les lignes de texte seul (« livraison comme convenu ») sont un écueil fréquent. Dans une facture structurée, une ligne est une ligne facturable : ce texte relève d'une note.

Corrections, avoirs et autofacturation

La FAQ est explicite : là où l'obligation de facture électronique s'applique, une correction doit elle aussi être une facture électronique, avec le type de facture prévu pour une correction. Dans l'EN 16931, elle renvoie à la facture précédente par son numéro et sa date d'émission : votre système doit donc conserver ce lien sous forme de donnée.

Attention au vocabulaire. En droit allemand de la TVA, une « Gutschrift » est une autofacture, émise par le client en vertu d'un accord préalable (§ 14 Abs. 2 UStG). Ce qu'on appelle un avoir en français (une réduction de prix ou une annulation) est, en Allemagne, une correction. Beaucoup de systèmes utilisent un seul type de document pour les deux. Séparez-les avant de les mapper, et si vous pratiquez l'autofacturation avec vos fournisseurs, traitez ces documents comme des factures émises par votre système.

Une facture finale peut énumérer les paiements partiels antérieurs dans une pièce jointe, à condition que la partie structurée y fasse référence ; la FAQ confirme que cela reste possible après 2027.

La validation avant tout envoi

La KoSIT publie un validateur open source qui contrôle le XML par rapport aux schémas et aux règles Schematron, avec une configuration publique pour XRechnung. Il s'exécute en ligne de commande, comme démon HTTP ou comme bibliothèque. Placez-le dans le circuit d'envoi : chaque facture est validée avant de partir, et un échec atterrit dans une file dont une personne nommée est responsable, en indiquant quel champ a enfreint quelle règle.

Pour ZUGFeRD, validez le XML embarqué selon les règles de votre profil, contrôlez séparément le conteneur PDF/A-3, et vérifiez que le PDF affiche les mêmes totaux que le XML.

La transmission

La loi, dit la FAQ, « sieht keinen bestimmten Weg vor » : elle n'impose aucun canal. Un e-mail avec le fichier en pièce jointe convient. Une API aussi, un portail de téléchargement, un stockage partagé au sein d'un groupe, ou encore (c'est l'exemple du ministère lui-même) une clé USB. Peppol n'est pas obligatoire pour le B2B domestique en Allemagne.

Le travail d'ingénierie se fait client par client : une adresse de facturation, un format préféré, et une trace de ce qui a été envoyé où. Un renvoi après un échec d'envoi transporte le même document avec le même numéro de facture. Deux numéros pour une même opération, c'est un problème fiscal, pas un problème logiciel.

L'archivage

Au minimum la partie structurée doit être conservée « unversehrt in seiner ursprünglichen Form », intacte dans sa forme d'origine, et le § 14b UStG fixe la durée de conservation à huit ans à compter de la fin de l'année d'émission. Stockez les octets exacts que vous avez envoyés, avec une empreinte. Ne comptez pas régénérer les factures depuis la base plus tard : d'ici là, les données et le code auront évolué. Il en va de même pour les factures électroniques que vous recevez.

Un plan d'octobre à décembre 2026

Treize semaines suffisent pour un développement ciblé si les données sources sont en état correct. Ce n'est pas assez pour remplacer le système de facturation.

Semaines 1 et 2 : inventaire et décisions. Recensez tous les endroits où une facture est produite, y compris les avoirs manuels, les factures finales de projet et le tableur d'un gros client. Comparez le chiffre d'affaires 2026 au seuil. Choisissez le format par défaut, et décidez si vous construisez le générateur ou si vous envoyez les données de facture à l'API d'un prestataire de facturation électronique.

Semaines 2 à 4 : analyse des écarts de données. Mettez en correspondance, champ par champ, trois mois de factures réelles avec l'EN 16931. Notez ce qui manque, ce qui doit devenir un code, et ce qui est calculé autrement. C'est là que la vraie taille du projet apparaît.

Semaines 4 à 9 : développement. L'objet facture, le mapping, la génération XML et PDF/A-3, le validateur dans le circuit d'envoi, la file d'échecs et l'archive. En parallèle, quelqu'un nettoie les données de référence et collecte les adresses de facturation auprès des clients.

Semaines 9 à 11 : rejeu et pilote. Faites passer les trois derniers mois de factures dans le nouveau générateur et validez chacune d'elles. Puis lancez un pilote avec quelques clients volontaires et demandez-leur si leurs systèmes lisent les fichiers.

Semaines 11 à 13 : gel et procédure d'exploitation. Gelez les modifications en décembre. Consignez qui est responsable de la file d'échecs, comment une correction est émise, et ce qui se passe quand un client rejette une facture. Les factures de janvier pour le travail de décembre sont déjà dans le champ.

Janvier 2027. Démarrez, et surveillez la file chaque jour jusqu'à la première clôture mensuelle et la première déclaration de TVA.

Tout au long de 2027. Planifiez le passage à XRechnung 4.0 avant que la 3.0 ne cesse d'être valable, et faites basculer les sociétés du groupe situées sous le seuil avant le 1er janvier 2028.

Si vous commencez tard, réduisez l'automatisation, pas la validité de ce qui sort : automatisez d'abord les types de factures à fort volume et faites passer les documents rares à la main par un outil de facturation électronique pendant quelques semaines.

Où trouver de l'aide

Nous construisons la liaison entre le système qui produit vos factures et le format exigé par la loi : modifications du modèle de données, mapping, validation, transmission et archivage, dans votre code et aux côtés de votre équipe. Notre service d'intégration de la facturation électronique décrit le déroulement de ces projets ; si l'obligation tombe en plein changement d'ERP, voyez la modernisation d'ERP. Le calendrier d'ensemble figure dans notre guide de la conformité numérique européenne 2026.

Nous sommes ingénieurs, pas conseillers fiscaux : les questions de périmètre relèvent de votre Steuerberater, et nous construisons selon sa réponse. Dites-nous ce qui produit vos factures aujourd'hui et combien il en part à peu près chaque mois : écrivez à office@c9group.dev.